Android CLI de Google : testé avec Claude Code

Android CLI de Google : testé avec Claude Code

La première chose que j'ai essayée après avoir installé le nouveau Android CLI de Google était la commande la plus ennuyeuse du manuel. android create. Modèle d'activité vide. Pas de drapeaux intelligents, pas d'invite créative - juste la chose la plus ordinaire à laquelle un cerveau formé à Java pourrait penser après quinze ans passés à cliquer sur l'assistant "Nouveau projet" de Android Studio.

Cela s'est terminé en onze secondes. Un projet Kotlin fonctionnel. Gradle câblé. Composez les dépendances épinglées. Manifestement sain d’esprit. J'ai ouvert le répertoire dans mon éditeur et je l'ai regardé comme s'il m'avait insulté.

J'ai passé tellement d'heures de ma vie à l'intérieur de ce sorcier. Choisir les versions minimales du SDK. Activer « Inclure la prise en charge de Hilt ». Je me demande si je veux réellement un graphique de navigation cette fois. Le sorcier va bien. C'est aussi une taxe que je paie chaque fois que je veux démarrer quelque chose de nouveau sur Android — et la taxe est payée en attention, pas en minutes. Onze secondes dans un terminal venaient de le supprimer.

Ce fut la première surprise. La deuxième surprise – celle qui comptait vraiment – ​​est survenue environ une heure plus tard, lorsque j'ai pointé Claude Code vers le Android CLI et que j'ai vu un agent faire quelque chose que j'aurais juré que ce serait dans un an.

Voilà à quoi ressemble une sortie discrète et importante. Google a présenté en avant-première le Android CLI le 16 avril 2026, niché dans un article de blog de développeur qui n'a même pas fait la une de Hacker News cette semaine-là. Pas de discours d'ouverture. Pas de vidéo de lancement avec des plans cinématiques de drone. Juste un lien de téléchargement sur d.android.com/tools/agents, une balise d'aperçu v0.7 et une promesse discrète que cette chose a été conçue pour les agents d'abord et ensuite pour les humains.

Je souhaite vous expliquer ce que j'ai testé, ce qui a fonctionné, ce qui a échoué et pourquoi je pense que cette CLI va remodeler la façon dont je crée des applications Android pour les deux prochaines années. Restez avec moi tout au long de l'installation - la partie intéressante apparaît autour de la troisième commande.

Pourquoi une CLI pour Android Studio existe même en 2026

Pour comprendre pourquoi Google a construit cela, vous devez comprendre le problème qu'il résout. Et le problème n'est pas "Android Studio est ennuyeux". Android Studio fonctionne bien. Le problème est que les agents AI ne peuvent pas utiliser Android Studio.

Pensez au fonctionnement réel de Claude Code, Codex ou Gemini CLI. L'agent lit les fichiers. L'agent écrit des fichiers. L'agent exécute des commandes shell et lit leur sortie. C'est toute la superficie. Il s'agit d'un système d'entrée et de sortie de texte qui réside dans votre terminal. Lorsque vous demandez à l'un de ces agents de « me créer un nouvel écran pour la page des paramètres », il peut modifier vos fichiers Kotlin à longueur de journée. Ce qu'il ne peut pas faire, c'est ouvrir Android Studio, cliquer sur Fichier → Nouveau → Activité, remplir la boîte de dialogue et cliquer sur OK.

Ainsi, au cours des deux dernières années, tous les agents qui ont touché au développement de Android ont fait cette danse maladroite : générer à la main des fichiers que Android Studio aurait générés correctement via des modèles, tâtonner avec la configuration de Gradle qu'il ne comprenait pas entièrement et demander constamment à l'humain de "simplement ouvrir Studio et de cliquer dessus pour moi". L'agent était un brillant collaborateur avec une main attachée en permanence derrière le dos.

Le Android CLI coupe ce nœud. Il expose les parties de Android Studio dont les agents ont réellement besoin (création de projet, contrôle de l'émulateur, inspection de la mise en page, recherche de documentation, capture d'écran) sous forme de commandes simples que n'importe quel agent peut exécuter à partir d'un shell. Soudain, l’agent a les deux mains.

Les chiffres rapportés par Google le confirment d'une manière à laquelle je ne m'attendais pas. Dans leurs tests internes, les agents utilisant Android CLI ont effectué des tâches 3 fois plus rapidement et ont consommé 70 % de jetons en moins que les agents essayant de piloter directement l'ancienne chaîne d'outils. Je suis généralement sceptique quant au nombre de fournisseurs : chaque lancement d'outil prétend qu'il est 10 fois plus rapide que ce qu'il remplace, et ce n'est presque jamais le cas. Mais la réduction symbolique de 70 % passe pour moi le test de l’odorat. J'expliquerai pourquoi dans une minute, lorsque nous arriverons à la commande layout.

Mais avant tout cela, installons le système. Parce que Google a pris ici une décision qui va dérouter la première vague de développeurs qui essaient cela.

Installation du Android CLI : ce n'est pas là où vous pensez

Si Android Studio est déjà installé et que vous supposez que la nouvelle CLI est livrée avec – comme adb, sdkmanager et le reste des outils de la plate-forme – vous passerez dix minutes frustrées à rechercher dans votre répertoire Android/sdk un binaire qui n'y existe pas.

Le Android CLI est expédié séparément. Exprès. Vous l'installez à partir de d.android.com/tools/agents, qui vous donne un seul binaire pour macOS, Linux ou Windows. Aucun indicateur du gestionnaire de SDK. Pas de plugin Gradle. Téléchargez-le simplement, déplacez-le dans votre PATH et vous avez terminé.

Je l'ai installé sur mon Mac comme ceci :

curl -L -o android https://d.android.com/tools/agents/macos/android

# Make it executable and move it into PATH
chmod +x android
sudo mv android /usr/local/bin/

# Verify
android -h

La sortie -h est la première chose qui mérite d'être lue. Il répertorie toutes les commandes prises en charge par la CLI – create, docs, emulator, screen, layout, resolve, skills, init – et une description sur une ligne pour chacune. Je l'ai lu deux fois avant d'exécuter quoi que ce soit d'autre, car la surface de commande est suffisamment petite pour que vous puissiez tout garder en tête, ce qui compte plus qu'il n'y paraît.

Après l'installation, l'étape suivante est android init. C’est là que la magie – et un léger piège – se produit.

android init

Ce que fait init : il analyse votre répertoire personnel à la recherche d'agents de codage installés, trouve tous ceux qu'il reconnaît et dépose une copie des compétences officielles Android dans le répertoire de compétences de chaque agent. Sur ma machine, il a trouvé Claude Code sous ~/.claude/, y a déposé la compétence et m'a demandé si je voulais également l'installer pour Gemini CLI et Antigravity. J'ai dit oui aux deux, car pourquoi pas.

Le piège léger : si aucun agent de codage n'est installé et que vous exécutez init sans arguments, il installe par défaut les compétences pour Gemini et Antigravity sur ~/.gemini/antigravity/skills. Si vous souhaitez étendre l'installation, transmettez --agent=claude-code ou --agent=gemini ou la cible que vous utilisez réellement. J'ai appris cela à mes dépens après m'être demandé pendant dix minutes pourquoi mon installation de Cursor ne captait pas les compétences - il s'est avéré que j'ai dû réexécuter explicitement android init --agent=cursor.

La sous-commande officielle skills add répertorie à ce stade [37 cibles d'agent prises en charge] (https://www.devclass.com/development/2026/04/21/google-previews-android-cli-for-new-world-of-agentic-development/5218263) : claude-code, gemini, codex, curseur, opencode, windsurf, cline, aider, github-copilot et une longue queue du plus petit écosystème d'agents de codage. Quoi que vous utilisiez, il figure presque certainement sur la liste.

Une fois init terminé, vous avez terminé la configuration. La CLI est installée, les compétences sont chargées dans vos agents et vous pouvez commencer à utiliser simultanément les commandes destinées aux humains et les compétences destinées aux agents. À partir de là, tout ce que j'ai testé ci-dessous fonctionne de la même manière, que j'exécute les commandes directement ou que je laisse Claude Code les piloter.

Les six commandes qui comptent vraiment

La CLI expose environ une douzaine de sous-commandes, mais six d'entre elles sont celles que je continue de rechercher. Permettez-moi de parcourir chacun d’entre eux avec ce que j’ai testé et ce que j’ai appris.

android create — Un échafaudage de projet qui ne vous fait plus perdre de temps

C’est le médicament d’introduction. android create génère un projet Android Studio complet à partir d'un modèle, avec des valeurs par défaut sensibles intégrées. Le modèle par défaut est empty-activity, qui vous offre un démarreur basé sur Compose avec Kotlin, AGP 9 et un thème de base déjà connecté.

android create --name MyApp --package com.mejba.myapp

Onze secondes. Fait. Vous pouvez transmettre --template pour choisir autre chose que l'activité vide : l'aperçu v0.7 est livré avec des modèles pour Compose Material 3, la navigation et quelques autres points de départ courants. Je m'attends à ce que cette liste s'allonge.

Ce qui m'a surpris ici, ce n'est pas la vitesse. C'était la cohérence. Lorsque vous échafaudez un projet de cette façon, vous obtenez les valeurs par défaut actuelles recommandées par Google – celles que l'équipe Android maintient activement. Fini de démarrer un projet en 2026 avec des schémas qui étaient idiomatiques en 2023. La CLI est, en effet, une pompe de fraîcheur opiniâtre pour les nouveaux projets.

android docs — La commande qui rend votre agent moins erroné

Celui-ci paraît petit et est énorme. android docs search <query> accède à l'index de documentation officiel Android et renvoie une liste d'URL de documents pertinentes. android docs fetch <url> extrait le contenu d'une page de document spécifique sous forme de texte brut.

android docs search "navigation 3 setup"
android docs fetch https://developer.android.com/guide/navigation/navigation-3

Pourquoi est-ce énorme ? Parce que tous les développeurs Android qui ont utilisé un agent AI ont vu l'agent inventer en toute confiance une API qui n'existe pas, ou générer du code basé sur un modèle obsolète de 2022, ou halluciner un modificateur Compose qui a été renommé il y a dix-huit mois. La raison pour laquelle cela se produit est que les données de formation de l'agent sont gelées à un moment donné dans le passé et que Android se déplace rapidement.

Lorsque l'agent a accès à android docs, il peut ancrer sa réponse dans la documentation actuelle au moment de la requête. J'ai vu Claude Code utiliser ce modèle exact lorsque je lui ai demandé de migrer un graphique de navigation basé sur des fragments vers Navigation 3 : la première commande était android docs search "navigation 3 migration", puis android docs fetch sur le premier résultat, puis il a écrit du code qui a été compilé avec l'API actuelle.

Soit dit en passant, il s’agit de la réduction symbolique de 70 % dont vous continuez à lire. Pas de magie. L'agent arrête de poser des questions de clarification, arrête de générer du code défectueux qui doit être corrigé, arrête de parcourir cinq tentatives pour trouver le bon nom de modificateur. Une recherche de documents, puis une modification correcte. Le coût symbolique de docs fetch est réel mais faible ; le coût symbolique de trois séries de code cassé et de correction est énorme.

android emulator — Enfin, contrôle de l'émulateur à partir d'un shell

Lancer un émulateur depuis Android Studio est très bien. Lancer un émulateur à partir d'un pipeline CI ou à partir d'une boucle d'agent nécessitait auparavant une pile de commandes avdmanager, sdkmanager et emulator que je devais rechercher à chaque fois. La nouvelle CLI la remplace par android emulator list, android emulator create, android emulator start et android emulator stop.

android emulator list
android emulator start --device pixel_8_pro --api 34

J'ai testé cela sur une machine propre - nouvelle installation du SDK, pas d'AVD préconfigurés. La CLI gérait le provisionnement du profil de périphérique, le téléchargement de l'image système si elle manquait et le lancement de l'émulateur avec des paramètres de fenêtre sains. Environ quatre-vingt-dix secondes de bout en bout sur une connexion filaire. Rien que je n'aurais pu faire moi-même avec cinq commandes de terminal ; tout ce que je n'avais pas besoin de me rappeler comment faire.

android layout — JSON au lieu de captures d'écran et pourquoi c'est important

C’est ici que la CLI commence à donner l’impression qu’elle a été conçue par quelqu’un qui a réellement expédié des flux de travail AI de production. android layout interroge l'émulateur ou l'appareil connecté en cours d'exécution et renvoie un document JSON décrivant l'intégralité de la hiérarchie de l'interface utilisateur : chaque élément, sa position, son contenu textuel, ses enfants.

android layout --pretty --output current-screen.json

Le résultat est un arbre structuré. Boutons, champs de texte, éléments de vue du recycleur, modaux — le tout représenté sous forme de nœuds JSON avec des limites, des identifiants et du contenu. Un agent AI peut lire cela en quelques centaines de jetons et savoir exactement ce qui est à l'écran, quels boutons existent, quel texte ils affichent, où ils se trouvent dans la mise en page.

Comparez cela avec l'alternative, qui demande à l'agent de regarder une capture d'écran et de comprendre l'interface utilisateur à partir de pixels. Les modèles de vision fonctionnent. Ils brûlent également des jetons comme un poêle à bois. Une capture d'écran 1080p représente des milliers de jetons une fois que le modèle l'encode ; une mise en page JSON pour le même écran est généralement inférieure à cinq cents. Pour les boucles d'agent qui doivent comprendre l'état de l'interface utilisateur à chaque tour, c'est la différence entre un flux de travail abordable et un autre qui vous coûte dix dollars par tâche.

Il existe également android layout --automator, qui revient au format XML classique d'UI Automator avec les métadonnées focalisables /enabled que les ingénieurs en automatisation des tests analysent depuis des années. Même idée, forme légèrement différente, utile lorsque vous avez besoin des conventions du framework de test.

android screen capture — Captures d'écran avec annotations intégrées

La commande screen capture fait ce à quoi vous vous attendez : prend une capture d'écran PNG du périphérique actuel. L'indicateur intéressant est --annotate, qui dessine des cadres de délimitation étiquetés autour de chaque élément d'interface utilisateur détecté et donne à chacun un numéro.

android screen capture --output screenshot.png
android screen capture --annotate --output annotated.png

Lorsque l'agent dispose d'une capture d'écran annotée, il peut faire référence aux éléments par leur étiquette numérique. "Appuyez sur l'élément 4" au lieu de "appuyez sur le bouton qui dit "Continuer" dans le coin inférieur droit." Moins d’ambiguïté, moins de faux tapotements, beaucoup moins d’allers-retours entre l’agent et l’appareil.

Il s’agit d’une petite amélioration ergonomique qui s’aggrave énormément sur une longue session d’agent. J'ai regardé une session Claude Code exécuter trente interactions d'interface utilisateur d'affilée sans un seul mauvais appui, car chaque référence était numérique. Avec des captures d’écran brutes, vous vous attendez à au moins trois ou quatre ratés sur autant d’actions.

android screen resolve — Le pont entre l'agent et l'ADB

Une fois que l'agent a décidé avec quel élément il souhaite interagir, android screen resolve convertit l'identifiant numérique d'une capture d'écran annotée en coordonnées de pixels réelles sur l'appareil actuel.

android screen resolve --element 4
# returns something like: { "x": 540, "y": 1820 }

Vous pouvez diriger ces coordonnées directement vers adb shell input tap 540 1820 et vous disposez d'un pipeline d'automatisation de l'interface utilisateur fonctionnel. C’est le moment où la CLI cesse d’être une aide à l’échafaudage de projet et commence à être une chaîne d’outils de test complète pilotée par agent. Un agent peut : lancer un émulateur, installer votre APK, capturer une capture d'écran annotée, décider sur quoi appuyer, résoudre les coordonnées, déclencher l'appui via ADB, capturer une autre capture d'écran et vérifier le nouvel état - le tout dans une boucle continue, le tout dans des commandes simples.

C'est, autant que je sache, la première fois que quelqu'un intègre cette boucle dans l'outil officiel Android. Il ne s'agit pas d'un framework tiers. Pas un projet de recherche. Le véritable propriétaire de la plateforme l’a expédié.

Si vous voulez voir à quoi ressemble un écosystème d'agents lorsqu'il est construit autour de compétences comme celle-ci, mon guide des compétences d'agent pour Claude Code parcourt le même modèle dans un domaine différent – ​​et les parallèles sont frappants.

Ce que j'ai construit en un week-end (et ce qui s'est cassé)

La théorie, c'est bien. Laissez-moi vous raconter ce qui s'est réellement passé lorsque j'ai essayé de l'utiliser pour un vrai travail.

Le projet : une petite application de suivi des habitudes, basée sur Compose, trois écrans, base de données Room, Hilt for DI. Rien d'exotique. Quelque chose dont j'ai construit des variantes une demi-douzaine de fois pour essayer de nouveaux outils.

Le plan : demander à Claude Code de piloter l'intégralité de la version via Android CLI. J'écrirais la spécification dans un fichier markdown, la remettrais à Claude et le laisserais faire la création de projet, la configuration des dépendances, l'échafaudage d'écran, les tests d'émulateur et l'itération par lui-même. Je n'intervenais que lorsque quelque chose se brisait.

Le résultat, après un samedi après-midi : une application fonctionnelle sur l'émulateur. Trois écrans. CRUD sur les habitudes. La persévérance fonctionne. Une interface utilisateur Compose déjantée mais fonctionnelle. Temps total dirigé par l'agent : environ trois heures, avec peut-être quarante-cinq minutes d'intervention humaine.

Ce qui a fonctionné à merveille :

L’étape d’échafaudage du projet a été instantanée. Claude a exécuté android create --name HabitTracker --package me.mejba.habits, puis a immédiatement demandé à l'index de la documentation les meilleures pratiques actuelles en matière de configuration de Hilt avec Compose. Il a récupéré la documentation canonique, extrait les extraits pertinents et ajouté les dépendances et les modules sans se tromper. L'ensemble du démarrage du projet, du "répertoire vide" aux "compilations et exécutions", a pris huit minutes. J'étais terrassé.

C’est dans la boucle de l’émulateur que j’ai ressenti le véritable changement. Claude écrivait un écran, exécutait android emulator start, créait et installait l'APK, puis android screen capture --annotate pour voir à quoi ressemblait réellement l'écran. Lorsque la mise en page était erronée, il comparait la capture d'écran à mes spécifications, modifiait le fichier Compose, reconstruisait et capturait à nouveau. Aucun humain n'est impliqué dans le retour visuel : l'agent peut voir son propre travail et effectuer une itération dessus. Je voulais ça depuis deux ans.

Ce qui s'est cassé :

Le premier mur dur était Hilt. Claude a généré un module Hilt parfaitement correct qui n'a pas fonctionné car le plugin kapt n'était pas activé dans le fichier Gradle du projet. Le message d'erreur était clair ; le correctif était une ligne. Claude l'a trouvé au deuxième essai, mais seulement après avoir laissé entendre que le problème était la configuration de Gradle plutôt que le code Hilt. La CLI n'a pas encore de sous-commande gradle, et c'est une lacune que j'ai ressentie.

Le deuxième obstacle majeur était la stabilité de l’émulateur. Environ deux heures plus tard, mon émulateur a atteint un état dans lequel il ne répondait plus à la saisie tactile. android screen capture a renvoyé une image figée. adb shell input tap n'a rien fait. J'ai dû manuellement android emulator stop, le redémarrer et réinstaller l'application. Claude n'aurait pas pu s'en remettre tout seul : le mode de défaillance était en dessous de la couche d'abstraction de la CLI. Cela deviendra plus fluide avec le temps, mais ce n’est pas encore le cas.

Le troisième problème était plus intéressant. À environ 80 % de la construction, Claude est devenu paresseux. Les aperçus Compose générés ont cessé d'utiliser les fournisseurs @PreviewParameter qu'ils avaient configurés précédemment ; l'échafaudage de test écrit sur l'écran un n'a pas été reporté sur les écrans deux et trois. La CLI ne peut pas résoudre ce problème : il s'agit d'un problème de comportement de l'agent, pas d'un problème d'outillage. Mais cela rappelle que la CLI supprime les frictions de la boucle de construction sans supprimer la responsabilité de diriger réellement le travail de l'agent.

Si vous avez lu mon article expliquant pourquoi [le contexte bat la configuration dans la conception d'agents] (https://www.mejba.me/ai-agent-context-beats-configuration), vous savez que je suis un disque rayé sur ce point. Better tools do not replace better direction. Ils laissent simplement les mauvaises directions échouer plus rapidement.

Le système de compétences : voici la vraie histoire

Je parle de commandes depuis deux mille mots. Permettez-moi de revenir en arrière et de vous parler de la partie qui, à mon avis, comptera le plus au cours de la prochaine année – et dont presque personne ne parle encore.

Le Android CLI est livré avec un système de [compétences d'agent] (https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html) — des fichiers de démarque qui apprennent à un agent comment utiliser la CLI pour une tâche spécifique. L'aperçu v0.7 est livré avec des compétences pour la configuration de Navigation 3, la migration bord à bord, la mise à niveau AGP 9, la migration XML vers Compose, l'analyse des règles de conservation R8 et la mise à niveau de la bibliothèque de facturation Google Play.

Lorsque vous exécutez android init, ces compétences sont installées dans le répertoire de compétences de votre agent. Lorsque vous demandez à Claude Code de « migrer cette mise en page XML vers Compose », il charge la compétence appropriée, suit les instructions écrites par Google et utilise les commandes CLI recommandées par la compétence. The agent is no longer guessing how to do a Compose migration based on its training data — it is following the official Android team's playbook for that specific task.

C’est le modèle que j’attends depuis deux ans que quelqu’un expédie. Le propriétaire de la plate-forme – l'équipe qui connaît réellement la bonne façon de faire une chose – écrit le playbook une seule fois, dans un format que l'agent peut lire, et chaque développeur utilisant n'importe quel agent en bénéficie. Pas un tutoriel enterré sur Developer.android.com que personne ne lit. Ce n'est pas une réponse Stack Overflow qui était correcte en 2022. Un jeu d'instructions en direct, exécutable et lisible par un agent, maintenu par l'équipe propriétaire de la plate-forme.

Si Google fait cela bien – et « bien faire cela » signifie un flux constant de nouvelles compétences, des mises à jour rapides lorsque les API changent, une intégration profonde avec le reste de la plate-forme – ce sera l'outil de développement le plus sous-estimé de 2026. La CLI est la surface. Les compétences sont la substance.

Et voici ce que personne dans la couverture du lancement ne mentionne : vous pouvez écrire vos propres compétences. Le format est ouvert. Si votre équipe a des normes architecturales – « utilisez toujours ce modèle DI, jamais celui-ci » – vous pouvez rédiger une compétence qui apprend à chaque agent de votre équipe à les suivre. Vous pouvez expédier cette compétence dans le cadre de votre dépôt. Un nouveau développeur rejoint, exécute android init, et soudain, son agent applique les normes de votre équipe. La mémoire institutionnelle de votre base de code devient exécutable.

C’est une chose discrète, étrange et importante. I am going to be writing about it more.

Ce que cela signifie pour le développement de Android en 2026

Permettez-moi de dire ce que je pense qui se passe ici, car je ne vois cela clairement exprimé nulle part ailleurs.

Google vient de dire à la communauté des développeurs Android que l'avenir du développement de Android est piloté par les agents, et ils ont construit l'outil officiel autour de cette hypothèse. Pas comme un pari secondaire. Pas comme un projet de laboratoire expérimental. En tant que nouvelle génération de la façon dont la plateforme attend de vous que vous travailliez.

Le signal est sans équivoque quand on regarde ce qu’ils ont fait et ce qu’ils n’ont pas fait. Ils n'ont pas créé de « CLI Gemini pour Android ». Ils ont construit une CLI qui prend en charge 37 agents sur un pied d'égalité, dont Claude Code et Codex, des concurrents directs de leur propre Gemini. Il s'agit d'une décision stratégique de Google visant à optimiser la productivité des développeurs plutôt que le verrouillage des agents. Cela vous indique qu'ils ont décidé que la plate-forme gagne lorsque les développeurs livrent plus d'applications plus rapidement, quel que soit l'agent qu'ils utilisent pour le faire.

Cette décision va mettre la pression sur tous les autres propriétaires de plateformes mobiles. L'histoire des outils de développement d'Apple pour les agents AI est, au moment de la rédaction, pratiquement inexistante : Xcode n'est scriptable d'aucune des manières dont un agent a besoin, et il n'existe pas de CLI bénie par Apple pour la création de projet, le contrôle du simulateur ou l'inspection de l'interface utilisateur. Si l'écart de productivité entre le développement Android piloté par agent et le développement iOS Xcode par clic devient 3x, comme le suggèrent les chiffres de Google, cet écart commencera à apparaître dans la vitesse d'expédition. Les équipes multiplateformes le remarqueront.

Pour les développeurs individuels, les implications pratiques sont plus simples. Si vous créez pour Android et que vous n'utilisez pas encore d'agent AI dans votre flux de travail, la rampe d'accès est devenue beaucoup plus courte. La CLI gère les parties du flux de travail qui nécessitaient auparavant l’EDI. Claude Code ou Gemini CLI ou Codex gère les pièces qui vous nécessitaient auparavant. Vous devenez l’architecte, le critique et la personne qui sait à quoi ressemble le bien – et l’agent tape.

Si vous voulez voir comment ce même modèle se déroule du côté du bureau, ma présentation de [Antigravity, l'IDE de Google pour les agents AI] (https://www.mejba.me/anti-gravity-ide-ai-agents), couvre le même changement dans les flux de travail en forme d'IDE. Même playbook, surface différente.

Là où le Android CLI est encore approximatif

J'ai été positif dans cet article car je pense que le lancement est vraiment important. Mais la balise d'aperçu v0.7 est honnête. Il y a de vraies aspérités.

Il n’existe pas encore de sous-commande gradle. Lorsque l'agent doit ajouter un plug-in, modifier une dépendance ou changer une version de build, il doit modifier directement les fichiers build.gradle.kts. L'agent peut le faire ; ce n'est pas toujours génial dans ce domaine. Une commande gradle add-plugin ou gradle add-dependency comblerait l’une des plus grandes lacunes restantes.

La bibliothèque de compétences est petite. Six compétences au lancement constituent un point de départ et non un système fini. La compétence de migration XML vers Compose est excellente ; la compétence Google Play Billing convient ; les autres que je n'ai pas encore utilisés en production. La bibliothèque doit atteindre peut-être quarante ou cinquante compétences avant de couvrir la surface réelle des tâches Android courantes.

L'intégration de l'émulateur est bonne mais pas à l'épreuve des balles. J'ai frappé un gel dur en trois heures d'utilisation. Ce n'est pas un désastre, mais il n'a pas encore atteint le niveau de fiabilité auquel je lui ferais confiance pour fonctionner sans surveillance pendant la nuit sur un pipeline CI.

L'index de la documentation couvre Developer.android.com, les documents Firebase et Kotlin. Il ne couvre pas encore les spécifications Material Design, les notes de version AndroidX ou la référence des composables Jetpack de manière approfondie. Ceux-là viendront. Pour l'instant, l'agent répondra parfois à une requête de documentation qui ne renvoie rien d'utile et devra s'appuyer sur ses données de formation.

Aucun de ceux-ci n’est un bloqueur. Ce sont tous des types de problèmes qui seront résolus au cours des trois à six prochains cycles de publication. Je parie que Google sera livré v1.0 par Google I/O 2026 avec la plupart de ces lacunes comblées.

Que faire cette semaine

Si vous créez des applications Android et que vous lisez ceci, voici ce que je ferais cette semaine.

Installez la CLI. Cela prend cinq minutes. Exécutez android init et laissez-le installer des compétences dans l'agent que vous utilisez déjà. Essayez android create sur un projet jetable - obtenez une idée de la rapidité avec laquelle le démarrage du projet peut être lorsque l'assistant a disparu.

Choisissez ensuite une vraie tâche que vous avez évitée. Une migration Compose. Une mise à niveau de Navigation 3. Un nettoyage R8. Tout ce où le travail est majoritairement mécanique mais fastidieux. Remettez-le à votre agent avec la CLI installée et regardez ce qui se passe. La première fois qu'un agent mène avec succès une véritable tâche Android de bout en bout, quelque chose se déclenche dans votre façon de penser au reste du travail qui vous attend.

Commencez ensuite à rédiger des compétences pour votre propre équipe. Choisissez un modèle architectural que votre équipe applique (vos conventions DI, votre configuration de test, votre approche de gestion des erreurs) et rédigez une compétence qui apprend à un agent à le suivre. Déposez-le dans votre dépôt. Laissez vos coéquipiers android init s'y opposer. Vous aurez donné à votre équipe une mise à niveau de la mémoire institutionnelle qui s'aggrave chaque fois que quelqu'un utilise un agent sur la base de code.

Questions fréquemment posées

Le Android CLI est-il gratuit ?

Oui. Le Android CLI est téléchargeable gratuitement à partir de d.android.com/tools/agents et est livré sous la même licence ouverte que le reste des outils de la plateforme Android. Il n’existe pas de niveau payant ni de licence d’entreprise à ce stade.

Le Android CLI fonctionne-t-il avec le Claude Code ?

Oui. Claude Code est l'une des 37 cibles d'agent prises en charge. Après avoir installé la CLI, exécutez android init --agent=claude-code pour installer les compétences officielles dans votre répertoire de compétences Claude Code.

Ai-je toujours besoin de Android Studio si j'ai la CLI ?

Pour la plupart des workflows pilotés par agents, non. Vous aurez toujours besoin de Android Studio pour le débogage visuel, le travail de profileur et l'inspection de mise en page complexe. Mais la création quotidienne de projets, la gestion des dépendances, le contrôle de l'émulateur et les tests de l'interface utilisateur peuvent désormais se faire entièrement à partir du terminal.

En quoi le Android CLI est-il différent du adb ?

adb est un pont de débogage de périphérique de bas niveau. Android CLI est un outil de flux de travail de niveau supérieur qui regroupe adb, sdkmanager, avdmanager, des parties de Gradle et l'index de documentation dans une seule interface conviviale pour les agents. La CLI utilise adb sous le capot pour certaines opérations.

Que fait réellement android init ?

Il analyse votre répertoire personnel à la recherche d'agents de codage installés, puis dépose les compétences officielles Android dans le répertoire de compétences de chaque agent. Cela apprend à chaque agent sur votre machine comment utiliser la CLI. Transmettez --agent=<name> pour étendre l’installation à un seul agent.

La commande ennuyeuse qui m'a fait changer d'avis

Retour à mon point de départ. android create. Modèle d'activité vide. Onze secondes.

Il serait facile de regarder cet ordre et de hausser les épaules. L'échafaudage de projet n'est pas la partie la plus difficile du développement de Android. N’importe qui peut échafauder un projet. The hard part is everything that comes after.

Mais la raison pour laquelle cette commande m'a marqué – la raison pour laquelle je suis assis ici à écrire trois mille mots sur un outil de développement un mardi – est qu'elle m'a dit ce que Google a décidé. Ils ont décidé que la difficulté de démarrer les choses était importante. Ils ont décidé que l’écosystème des agents comptait plus que le verrouillage des agents. Ils ont décidé que la prochaine génération de développeurs Android consacrerait son attention sur ce qu'il faut construire, et non sur la façon d'amorcer sa construction.

C'est un pari sur un type de développeur différent de celui pour lequel Android Studio a été conçu. C’est un pari que je suis heureux de prendre.

La question qui se pose est de savoir de quel côté de ce pari vous souhaitez vous situer. Passez les cinq minutes. Installez la CLI. Exécutez une véritable tâche via l’agent de votre choix. Voyez à quoi ressemblent onze secondes lorsque le sorcier est parti. Ensuite, demandez-vous : quelle autre taxe dans votre flux de travail a été une taxe que vous avez oublié de payer ?

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io