Android CLI : développer des applications Android avec un agent IA

Google publie depuis avril 2026 une ligne de commande, l'Android CLI, pensée pour que des agents IA (Claude Code, Codex, Gemini, Antigravity) développent des applications Android sans passer par l'interface d'Android Studio¹. Passée en version stable 1.0 lors de Google I/O, le 19 mai 2026⁵, elle s'accompagne de compétences prêtes à l'emploi (Android Skills), de tests en langage naturel (Journeys) et d'une passerelle vers Android Studio.

Concrètement, l'agent ne devine plus comment installer un SDK, lancer un émulateur ou lire l'arborescence d'un écran : il appelle des commandes documentées, au résultat prévisible. Voici ce que contient la boîte à outils, comment la mettre en place et ce qu'il faut surveiller.

Qu'est-ce que l'Android CLI ?

C'est un exécutable unique, android, qui donne aux agents et aux scripts un point d'entrée vers les outils, les compétences et la documentation officiels. Il automatise l'installation du SDK, crée des projets à partir de modèles, gère les appareils virtuels, installe des APK et inspecte les écrans². Les principales familles de commandes :

La version de septembre 2026 a divisé par deux le temps de démarrage, ajouté un émulateur sans interface graphique (option --headless), utile en intégration continue, et corrigé les codes de sortie : une commande en échec renvoie désormais un code non nul, ce qui compte dès qu'un script ou un agent enchaîne les étapes⁶.

Comment l'installer et la brancher à votre agent ?

Depuis la 1.0, l'Android CLI s'installe avec les gestionnaires de paquets habituels : Homebrew, apt-get et winget⁶. Sous Windows, par exemple⁵ :

winget install -e --id Google.AndroidCLI

Ensuite, deux commandes suffisent² :

android update   # passer à la dernière version
android init     # installer la compétence android-cli pour votre agent

android init installe la compétence qui apprend à votre agent à se servir de l'outil. Un fichier ~/.androidrc (%USERPROFILE%\.androidrc sous Windows) fixe des options par défaut, comme le chemin du SDK avec --sdk=<chemin>².

Côté agents, Google cite Gemini dans Android Studio, Antigravity 2.0, Claude Code et Codex d'OpenAI⁵. macOS et Linux sont pleinement pris en charge ; sous Windows, la commande android emulator est pour l'instant désactivée et le téléchargement depuis PowerShell n'est pas pris en charge².

Données d'usage : l'outil transmet à Google les commandes appelées et le nom des options, mais ni les réponses ni les valeurs saisies (noms de projets, chemins de fichiers). L'option --no-metrics désactive cette collecte².

À quoi servent les Android Skills ?

Une skill est un fichier SKILL.md : un en-tête YAML (nom, description) suivi d'instructions en Markdown, éventuellement accompagnées de scripts et de documents de référence³. Les Android Skills suivent le format ouvert Agent Skills : elles fonctionnent avec tout agent qui le prend en charge, Claude Code compris⁸. L'agent charge de lui-même celles qui correspondent à la tâche demandée.

Google en publie sur un dépôt GitHub pour des chantiers précis³ :

• migrer des écrans XML vers Jetpack Compose ;
• passer à AGP 9 ou à Navigation 3 ;
• afficher l'application bord à bord (edge-to-edge) ;
• auditer la configuration R8 pour gagner en performance ;
• depuis la 1.0 : migrer vers CameraX, rendre l'interface adaptative, mettre en place AppFunctions ou les tests⁵.

android skills list               # voir les skills disponibles
android skills add <nom-de-skill>  # installer ou mettre à jour une skill

Elles se rangent dans .skills/ ou .agent/skills/ à la racine du projet. Piège à connaître : si vous modifiez une skill officielle sans la renommer, la prochaine mise à jour écrase vos changements³.

Que permet la commande android studio ?

Ajoutée avec la 1.0, elle donne à un agent qui tourne dans le terminal l'analyse de code d'une instance Android Studio ouverte⁵ :

• analyze-file : erreurs et avertissements d'un fichier ;
• find-declaration et find-usages : où un symbole est défini et utilisé ;
• render-compose-preview : rendu d'un aperçu Compose en image, que l'agent peut examiner ;
• version-lookup : versions disponibles des dépendances ;
• open-file : ouvrir un fichier dans l'IDE, pour que le développeur reprenne la main.

C'est la vraie différence avec un agent qui se contente de lire des fichiers texte : il voit le projet comme l'IDE le comprend, rendu de l'interface compris.

Peut-on tester une application en langage naturel ?

C'est le rôle des Journeys. Vous décrivez un parcours (ouvrir l'application, se connecter, ajouter un article au panier, vérifier le total) ; l'agent le traduit en interactions et juge les vérifications d'après ce qu'il voit à l'écran⁴. Les parcours sont enregistrés dans le projet et peuvent tourner dans votre CI/CD, puisque l'agent s'exécute dans le terminal⁵.

Notre conseil : réservez-les aux parcours critiques (inscription, paiement). Un test qui repose sur la lecture d'écran par un modèle est plus lent et moins reproductible qu'un test instrumenté classique, et chaque exécution consomme des appels au modèle. La documentation ne détaille pas encore le format des fichiers ni de limites chiffrées⁴.

Lightbuild, une configuration de build en YAML ?

Google teste aussi Lightbuild : une configuration de compilation déclarative en YAML, convertie en Gradle en arrière-plan, plus simple à lire et à modifier pour un agent. Elle est réservée pour l'instant à un groupe restreint de testeurs, sans date de sortie publique⁷. À suivre, pas encore à planifier.

Faut-il l'adopter maintenant ?

Pour une équipe qui travaille déjà avec un agent de code, oui, pour les tâches répétitives : mise en place d'un poste ou d'une CI, migrations encadrées par une skill, captures d'écran et vérification de parcours. Trois précautions :

• laissez l'agent demander confirmation avant les commandes qui installent ou suppriment (SDK, émulateurs, appareils distants) ;
• versionnez les skills que vous adaptez, sous un nom à vous, avec le reste du projet ;
• relisez les migrations proposées : une skill guide le modèle, elle ne garantit pas le résultat.

Pour comprendre comment un agent se connecte à des outils externes, voir notre guide pratique MCP et Claude ; pour les risques liés aux outils confiés à une IA, notre article sur la sécurité MCP en entreprise. Pour intégrer des agents à votre chaîne de développement mobile, notre équipe IA Engineering vous accompagne.