Android CLI van Google: getest met Claude Code

Android CLI van Google: getest met Claude Code

Het eerste dat ik probeerde na het installeren van Google's nieuwe Android CLI was het saaiste commando in de handleiding. android create. Lege activiteitensjabloon. Geen slimme vlaggen, geen creatieve prompt - gewoon het meest gewone dat een Java-getraind brein zou kunnen bedenken na vijftien jaar klikken door de "Nieuw Project"-wizard van Android Studio.

Het eindigde in elf seconden. Een werkend Kotlin-project. Gradle is aangesloten. Compose afhankelijkheden vastgezet. Duidelijk gezond. Ik opende de directory in mijn editor en staarde ernaar alsof het mij had beledigd.

Ik heb zoveel uren van mijn leven in die tovenaar doorgebracht. Minimale SDK-versies kiezen. Schakel 'Inclusief Hilt-ondersteuning' in of uit. Ik vraag me af of ik deze keer eigenlijk wel een navigatiegrafiek wil. Het gaat goed met de tovenaar. Het is ook een belasting die ik betaal elke keer dat ik iets nieuws wil beginnen op Android — en de belasting wordt betaald in aandacht, niet in minuten. Elf seconden in een terminal hadden het zojuist verwijderd.

Dat was de eerste verrassing. De tweede verrassing – degene die er echt toe deed – kwam ongeveer een uur later, toen ik Claude Code op de Android CLI richtte en een agent iets zag doen waarvan ik zou hebben gezworen dat het over een jaar zou duren.

Zo ziet een rustige, belangrijke release eruit. Google gaf een preview van Android CLI op 16 april 2026, verscholen in een ontwikkelaarsblogpost die die week niet eens bovenaan Hacker News stond. Geen keynote. Geen lanceringsvideo met filmische drone-opnamen. Just a download link at d.android.com/tools/agents, a v0.7 preview tag, and a quiet promise that this thing was built for agents first and humans second.

Ik wil je laten zien wat ik heb getest, wat werkte, wat kapot ging en waarom ik denk dat deze CLI de manier waarop ik Android-apps de komende twee jaar bouw, opnieuw zal vormgeven. Blijf bij mij tijdens de installatie - het interessante deel verschijnt rond de derde opdracht.

Waarom er in 2026 zelfs een CLI voor Android Studio bestaat

Om te begrijpen waarom Google dit heeft gebouwd, moet je begrijpen welk probleem het oplost. En het probleem is niet "Android Studio is vervelend." Android Studio is prima. Het probleem is dat AI-agenten Android Studio niet kunnen gebruiken.

Bedenk hoe Claude Code of Codex of Gemini CLI eigenlijk werkt. De agent leest bestanden. De agent schrijft bestanden. De agent voert shell-opdrachten uit en leest de uitvoer ervan. Dat is de gehele oppervlakte. Het is een tekst-in, tekst-uit-systeem dat in uw terminal leeft. Wanneer u een van deze agenten vraagt ​​om "een nieuw scherm voor de instellingenpagina te bouwen", kan deze uw Kotlin-bestanden de hele dag bewerken. Wat het niet kan doen, is Android Studio openen, op Bestand → Nieuw → Activiteit klikken, het dialoogvenster invullen en op OK klikken.

Dus de afgelopen twee jaar heeft elke agent die betrokken was bij de ontwikkeling van Android dit lastige dansje gedaan: met de hand bestanden genereren die Android Studio correct zou hebben gegenereerd via sjablonen, rommelen met de Gradle-configuratie die hij niet helemaal begreep, en de mens voortdurend vragen om "Studio gewoon te openen en hierop voor mij te klikken." De agent was een briljante medewerker met één hand permanent op zijn rug gebonden.

The Android CLI cuts that knot. Het legt de onderdelen van Android Studio bloot die agenten daadwerkelijk nodig hebben – projectcreatie, emulatorcontrole, lay-outinspectie, opzoeken van documentatie, screenshot maken – als eenvoudige opdrachten die elke agent vanuit een shell kan uitvoeren. Suddenly the agent has both hands.

De cijfers die Google rapporteert ondersteunen dit op een manier die ik niet had verwacht. In hun interne benchmarks voltooiden agenten die de Android CLI gebruikten taken 3x sneller en verbruikten ze 70% minder tokens dan agenten die probeerden de oude toolchain rechtstreeks aan te sturen. Normaal gesproken sta ik sceptisch tegenover leveranciersnummers: bij elke lancering van een tool wordt beweerd dat het 10x sneller is dan het product dat het vervangt, en dat is bijna nooit het geval. Maar de symbolische reductie van 70% doorstaat voor mij de geurtest. Ik zal zo meteen uitleggen waarom, als we bij het lay-outcommando komen.

Maar voordat we dat allemaal doen, laten we het ding installeren. Omdat Google hier één beslissing heeft genomen die de eerste golf ontwikkelaars die dit proberen in verwarring zal brengen.

De Android CLI installeren: het is niet waar u denkt

Als je Android Studio al hebt geïnstalleerd en je gaat ervan uit dat de nieuwe CLI erbij wordt geleverd (hetzelfde als adb, sdkmanager en de rest van de platformtools), zul je tien gefrustreerde minuten besteden aan het doorzoeken van je Android/sdk-directory naar een binair bestand dat daar niet bestaat.

De Android CLI wordt afzonderlijk verzonden. Met opzet. Je installeert het vanuit d.android.com/tools/agents, waardoor je één binair bestand krijgt voor macOS, Linux of Windows. Geen SDK-managervlaggen. Geen Gradle-plug-in. Gewoon downloaden, verplaatsen naar uw PATH en u bent klaar.

Ik heb het als volgt op mijn Mac geïnstalleerd:

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

The -h output is the first thing worth reading. Het bevat elke opdracht die de CLI ondersteunt — create, docs, emulator, screen, layout, resolve, skills, init — en een beschrijving van één regel voor elk commando. Ik heb het twee keer doorgelezen voordat ik iets anders uitvoerde, omdat het commandooppervlak klein genoeg is om alles in je hoofd te kunnen houden, wat er meer toe doet dan het klinkt.

Na de installatie is de volgende zet android init. This is where the magic — and one mild gotcha — happens.

android init

Wat init doet: het scant uw thuismap op geïnstalleerde codeeragents, vindt alle programma's die het herkent en plaatst een kopie van de officiële Android-vaardigheden in de vaardighedenmap van elke agent. On my machine it found Claude Code under ~/.claude/, dropped the skill there, and asked me whether I wanted it installed for Gemini CLI and Antigravity too. Ik zei ja tegen beide, want waarom niet.

Het milde probleem: als je geen codeeragenten hebt geïnstalleerd en je init zonder argumenten uitvoert, wordt standaard de vaardigheden voor Gemini en Antigravity geïnstalleerd op ~/.gemini/antigravity/skills. Als u de installatie wilt beperken, geeft u --agent=claude-code of --agent=gemini door, of welk doel u ook daadwerkelijk gebruikt. Ik heb dit op de harde manier geleerd nadat ik me tien minuten had afgevraagd waarom mijn Cursor-installatie de vaardigheden niet oppikte - het bleek dat ik android init --agent=cursor expliciet opnieuw moest uitvoeren.

Het officiële skills add-subcommando vermeldt op dit punt [37 ondersteunde agentdoelen] (https://www.devclass.com/development/2026/04/21/google-previews-android-cli-for-new-world-of-agentic-development/5218263): claude-code, gemini, codex, cursor, opencode, windsurf, cline, aider, github-copilot en een lange staart van het kleinere ecosysteem van coderingsagenten. Whatever you are using, it is almost certainly on the list.

Zodra init klaar is, bent u klaar met instellen. De CLI is geïnstalleerd, de vaardigheden worden in uw agenten geladen en u kunt zowel de mensgerichte opdrachten als de agentgerichte vaardigheden samen gaan gebruiken. From here on, everything I tested below works the same whether I run the commands directly or whether I let Claude Code drive them.

De zes commando's die er echt toe doen

The CLI exposes about a dozen subcommands, but six of them are the ones I keep reaching for. Let me walk through each one with what I tested and what I learned.

android create — Projectsteigers waarmee u geen tijd meer verspilt

Dit is het gateway-medicijn. android create genereert een volledig Android Studio-project op basis van een sjabloon, met verstandige standaardinstellingen. De standaardsjabloon is empty-activity, waarmee u een op Compose gebaseerde starter krijgt met Kotlin, AGP 9 en een al aangesloten basisthema.

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

Eleven seconds. Klaar. U kunt --template doorgeven om iets anders te kiezen dan de lege activiteit; de preview van v0.7 wordt geleverd met sjablonen voor Compose Material 3, navigatie en een paar andere algemene uitgangspunten. Ik verwacht dat deze lijst nog zal groeien.

Wat mij hier verraste, was niet de snelheid. Het was de consistentie. Wanneer u een project op deze manier inricht, krijgt u de huidige door Google aanbevolen standaardwaarden: de standaardwaarden die het Android-team actief onderhoudt. Je hoeft in 2026 niet meer een project te starten met patronen die in 2023 idiomatisch waren. De CLI is in feite een eigenwijze frisheidspomp voor nieuwe projecten.

android docs — The Command That Makes Your Agent Less Wrong

Deze ziet er klein uit en is enorm. android docs search <query> hits the official Android documentation index and returns a list of relevant doc URLs. android docs fetch <url> pulls the content of a specific doc page as plain text.

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

Waarom is dit enorm? Omdat elke Android-ontwikkelaar die een AI-agent heeft gebruikt, heeft gezien hoe de agent vol vertrouwen een API uitvond die niet bestaat, of code genereert op basis van een verouderd patroon uit 2022, of een Compose-modifier hallucineert die achttien maanden geleden werd hernoemd. De reden dat dit gebeurt is dat de trainingsgegevens van de agent op een bepaald moment in het verleden zijn bevroren en dat Android snel beweegt.

Wanneer de agent toegang heeft tot android docs, kan hij zijn antwoord tijdens de query baseren op de huidige documentatie. Ik zag hoe Claude Code dit exacte patroon gebruikte toen ik hem vroeg een op fragmenten gebaseerde navigatiegrafiek naar Navigatie 3 te migreren. Het eerste commando was android docs search "navigation 3 migration", daarna android docs fetch in het bovenste resultaat, en vervolgens schreef het code die feitelijk werd gecompileerd op basis van de huidige API.

Dat is trouwens de tokenreductie van 70% waar je steeds over leest. Geen magie. De agent stopt met het stellen van verduidelijkende vragen, stopt met het genereren van kapotte code die moet worden gerepareerd, stopt met het doorlopen van vijf pogingen om de juiste modifier-naam te vinden. One docs lookup, then one correct edit. The token cost of docs fetch is real but small; the token cost of three rounds of broken-code-and-correction is enormous.

android emulator — Eindelijk emulatorbesturing vanuit een shell

Spinning up an emulator from inside Android Studio is fine. Voor het opstarten van een emulator vanuit een CI-pijplijn of vanuit een agentlus was vroeger een stapel avdmanager-, sdkmanager- en emulator-opdrachten nodig die ik elke keer moest opzoeken. De nieuwe CLI vervangt die door android emulator list, android emulator create, android emulator start en android emulator stop.

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

Ik heb dit getest op een schone machine: nieuwe SDK-installatie, geen vooraf geconfigureerde AVD's. De CLI zorgde voor het inrichten van het apparaatprofiel, het downloaden van de systeemimage als deze ontbrak, en het starten van de emulator met redelijke vensterinstellingen. Ongeveer negentig seconden van begin tot eind bij een bekabelde verbinding. Niets dat ik zelf niet had kunnen doen met vijf terminalopdrachten; alles hoefde ik niet te onthouden hoe ik het moest doen.

android layout — JSON in plaats van screenshots, en waarom dit ertoe doet

Hier begint de CLI het gevoel te krijgen dat deze is ontworpen door iemand die daadwerkelijk productie-AI-workflows heeft verzonden. android layout vraagt ​​de momenteel actieve emulator of het aangesloten apparaat op en retourneert een JSON-document dat de volledige UI-hiërarchie beschrijft: elk element, zijn positie, zijn tekstinhoud, zijn onderliggende elementen.

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

De uitvoer is een gestructureerde boom. Knoppen, tekstvelden, recycler-weergave-items, modals: alles wordt weergegeven als JSON-knooppunten met grenzen, ID's en inhoud. Een AI-agent kan dit in een paar honderd tokens uitlezen en weet precies wat er op het scherm staat, welke knoppen er zijn, welke tekst ze tonen, waar ze zich in de lay-out bevinden.

Vergelijk dat eens met het alternatief, waarbij de agent wordt gevraagd naar een screenshot te kijken en de gebruikersinterface uit pixels te achterhalen. Visiemodellen werken. Ze verbranden ook tokens zoals een houtkachel. Een 1080p-screenshot bestaat uit duizenden tokens zodra het model het codeert; een JSON-indeling voor hetzelfde scherm is meestal minder dan vijfhonderd. Voor agentloops die bij elke beurt de status van de gebruikersinterface moeten begrijpen, is dit het verschil tussen een betaalbare workflow en een workflow die u tien dollar per taak kost.

Er is ook android layout --automator, dat terugvalt op het klassieke UI Automator XML-formaat met de focusbare /enabled-metadata die testautomatiseringsingenieurs al jaren parseren. Hetzelfde idee, iets andere vorm, handig als je de conventies van het testframework nodig hebt.

android screen capture — Schermafbeeldingen met ingebouwde annotaties

De opdracht screen capture doet wat u zou verwachten: maakt een PNG-screenshot van het huidige apparaat. De interessante vlag is --annotate, die gelabelde kaders rond elk gedetecteerd UI-element tekent en elk een nummer geeft.

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

Wanneer de agent een geannoteerde schermafbeelding heeft, kan deze naar elementen verwijzen met hun numerieke label. "Tik op element 4" in plaats van "tik op de knop met de tekst 'Doorgaan' in de rechter benedenhoek." Minder dubbelzinnigheid, minder verkeerde tikken, veel minder heen en weer tussen de agent en het apparaat.

Dit is een kleine ergonomische verbetering die enorm toeneemt tijdens een lange agentsessie. Ik zag hoe een Claude Code-sessie dertig UI-interacties achter elkaar uitvoerde zonder een enkele verkeerde tik, omdat elke verwijzing numeriek was. Met onbewerkte schermafbeeldingen zou je bij zoveel acties minstens drie of vier mislukkingen verwachten.

android screen resolve — De brug tussen agent en ADB

Zodra de agent heeft besloten met welk element hij wil communiceren, converteert android screen resolve de numerieke identificatie van een geannoteerde schermafbeelding naar daadwerkelijke pixelcoördinaten op het huidige apparaat.

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

U kunt deze coördinaten rechtstreeks naar adb shell input tap 540 1820 doorsturen en u beschikt over een werkende UI-automatiseringspijplijn. Dit is het moment waarop de CLI niet langer een project-steigerhelper is, maar een complete agentgestuurde testtoolketen begint te worden. Een agent kan: een emulator starten, uw APK installeren, een geannoteerde schermafbeelding maken, beslissen waar hij op moet tikken, coördinaten oplossen, de tik via ADB activeren, nog een schermafdruk maken en de nieuwe status verifiëren - alles in één doorlopende lus, allemaal met eenvoudige opdrachten.

Dat is, voor zover ik weet, de eerste keer dat iemand die lus in de officiële Android-tooling heeft ingebouwd. Geen raamwerk van derden. Geen onderzoeksproject. De daadwerkelijke platformeigenaar heeft het verzonden.

Als je wilt zien hoe een agent-ecosysteem eruit ziet als het van de grond af aan rond dit soort vaardigheden is opgebouwd: mijn gids voor agentenvaardigheden voor Claude Code doorloopt hetzelfde patroon in een ander domein – en de parallellen zijn opvallend.

Wat ik in een weekend heb gebouwd (en wat kapot ging)

Theorie is prima. Laat me je vertellen wat er feitelijk gebeurde toen ik dit voor echt werk probeerde te gebruiken.

Het project: een kleine app voor het bijhouden van gewoontes, op Compose gebaseerd, drie schermen, Room database, Hilt voor DI. Niets exotisch. Iets waar ik al een zestal keer varianten van heb gebouwd om nieuwe tooling uit te proberen.

Het plan: laat Claude Code de volledige build via de Android CLI aansturen. Ik zou de specificatie in een afwaarderingsbestand schrijven, het aan Claude overhandigen en het zelf projecten laten maken, afhankelijkheidsinstellingen, schermsteigers, emulatortesten en iteratie laten doen. Ik zou pas ingrijpen als er iets kapot ging.

Het resultaat, na een zaterdagmiddag: een werkende app op de emulator. Drie schermen. CRUD op gewoonten. Volharding werken. Een janky maar functionele Compose UI. Totale door agenten geleide tijd: ongeveer drie uur, met misschien vijfenveertig minuten menselijke tussenkomst.

Wat prachtig werkte:

De stap van het steigeren naar het project was onmiddellijk. Claude voerde android create --name HabitTracker --package me.mejba.habits uit en vroeg vervolgens onmiddellijk aan de docs-index naar de huidige best practices voor de Hilt-installatie met Compose. Het kreeg het canonieke document terug, haalde de relevante fragmenten eruit en voegde de afhankelijkheden en modules toe zonder een verkeerde afslag te nemen. Het hele project opstarten van "lege map" naar "compileren en uitvoeren" duurde acht minuten. Ik was gevloerd.

In de emulatorlus voelde ik de echte verschuiving. Claude schreef een scherm, voerde android emulator start uit, bouwde en installeerde de APK en vervolgens android screen capture --annotate om te zien hoe het scherm er werkelijk uitzag. Als de lay-out verkeerd was, werd de schermafbeelding vergeleken met mijn specificaties, werd het Compose-bestand bewerkt, opnieuw opgebouwd en opnieuw vastgelegd. Er was geen mens betrokken bij de visuele feedback; de agent kon zijn eigen werk zien en daarop voortbouwen. Ik wilde dit al twee jaar.

Wat is er kapot gegaan:

De eerste harde muur was Hilt. Claude genereerde een perfect correcte Hilt-module die niet werkte omdat de plug-in kapt niet was ingeschakeld in het Gradle-projectbestand. De foutmelding was duidelijk; de oplossing was één regel. Claude vond het bij de tweede poging, maar pas nadat ik een hint had laten vallen dat het probleem aan de Gradle-configuratie lag en niet aan de Hilt-code. De CLI heeft nog geen gradle-subopdracht, en dat is een gat dat ik voelde.

De tweede harde muur was de stabiliteit van de emulator. Ongeveer twee uur later raakte mijn emulator een toestand waarin hij niet reageerde op aanraakinvoer. android screen capture retourneert een bevroren afbeelding. adb shell input tap deed niets. Ik moest android emulator stop handmatig opnieuw opstarten, en de app opnieuw installeren. Claude had dit niet op eigen kracht kunnen herstellen; de fout lag onder de abstractielaag van de CLI. Dit zal in de loop van de tijd soepeler worden, maar het is nog niet soepel.

Het derde onderwerp was interessanter. Ongeveer 80% van de bouw werd Claude lui. De Compose-previews die het genereerde, gebruikten niet meer de @PreviewParameter-providers die het eerder had ingesteld; de teststeigers die het in scherm één schreef, werden niet meegenomen naar schermen twee en drie. De CLI kan dit niet oplossen; het is een gedragsprobleem van agenten, geen toolingprobleem. Maar het herinnert ons eraan dat de CLI de wrijving uit de bouwlus wegneemt, zonder de verantwoordelijkheid weg te nemen om het werk van de agent daadwerkelijk te sturen.

Als je mijn stuk hebt gelezen over waarom [context het wint van configuratie in agentontwerp] (https://www.mejba.me/ai-agent-context-beats-configuration), weet je dat ik op dit punt een gebroken record heb. Betere instrumenten kunnen een betere leiding niet vervangen. Ze lieten slechte regie gewoon sneller mislukken.

Het vaardighedensysteem: dit is het echte verhaal

Ik heb het al tweeduizend woorden over commando's. Ik wil even teruggaan en u vertellen over het deel waarvan ik denk dat het er het komende jaar het meest toe gaat doen – en waar bijna niemand het nog over heeft.

De Android CLI wordt geleverd met een systeem van [agentvaardigheden] (https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html) - markdown-bestanden die een agent leren hoe hij de CLI voor een specifieke taak moet gebruiken. De v0.7 preview wordt geleverd met vaardigheden voor het instellen van Navigatie 3, edge-to-edge migratie, AGP 9-upgrade, XML-naar-Compose-migratie, R8 keep-rule-analyse en de Google Play Billing Library-upgrade.

Wanneer u android init uitvoert, worden deze vaardigheden geïnstalleerd in de vaardighedenmap van uw agent. Wanneer u Claude Code vraagt ​​om "deze XML-lay-out naar Compose te migreren", wordt de relevante vaardigheid geladen, volgt de instructies die Google schreef en gebruikt de CLI-opdrachten die de vaardigheid aanbeveelt. De agent raadt niet langer hoe hij een Compose-migratie moet uitvoeren op basis van zijn trainingsgegevens; hij volgt het officiële Android-team's draaiboek voor die specifieke taak.

Dit is het patroon waar ik al twee jaar op wacht totdat iemand het verzendt. De platformeigenaar – het team dat daadwerkelijk weet hoe iets moet worden gedaan – schrijft het draaiboek één keer, in een formaat dat de agent kan lezen, en elke ontwikkelaar die een agent gebruikt, profiteert ervan. Geen tutorial begraven op developer.android.com die niemand leest. Geen Stack Overflow-antwoord dat correct was in 2022. Een live, uitvoerbare, door agenten leesbare instructieset, onderhouden door het team dat eigenaar is van het platform.

Als Google dit goed doet – en ‘dit goed doen’ betekent een gestage stroom nieuwe vaardigheden, snelle updates wanneer API’s veranderen, diepe integratie met de rest van het platform – wordt dit de meest ondergewaardeerde ontwikkelaarstool van 2026. De CLI is het oppervlak. De vaardigheden zijn de inhoud.

En dit is wat niemand in de lanceringsverslaggeving vermeldt: je kunt je eigen vaardigheden schrijven. Het formaat is geopend. Als uw team architectonische standaarden hanteert ('gebruik altijd dit DI-patroon, nooit dit') – kunt u een vaardigheid schrijven die elke agent in uw team leert deze te volgen. Je kunt die vaardigheid verzenden als onderdeel van je repository. Er komt een nieuwe ontwikkelaar bij, voert android init uit en plotseling dwingt hun agent de normen van uw team af. Het institutionele geheugen van uw codebase wordt uitvoerbaar.

Dat is een rustige, vreemde, belangrijke zaak. Ik ga er nog meer over schrijven.

Wat dit betekent voor de ontwikkeling van Android in 2026

Laat me zeggen wat ik denk dat hier gebeurt, omdat ik het nergens anders duidelijk zie staan.

Google heeft de ontwikkelaarsgemeenschap van Android zojuist verteld dat de toekomst van de ontwikkeling van Android door agenten wordt aangestuurd, en zij hebben de officiële tooling rond die veronderstelling gebouwd. Niet als nevenweddenschap. Niet als experimenteel laboratoriumproject. Als de volgende generatie van hoe het platform van je verwacht dat je werkt.

Het signaal is onmiskenbaar als je kijkt naar wat ze wel en niet deden. Ze hebben geen "Gemini CLI voor Android" gebouwd. Ze bouwden een CLI die 37 agenten op gelijke voorwaarden ondersteunt, waaronder Claude Code en Codex – directe concurrenten van hun eigen Gemini. Dat is een strategische beslissing van Google om de productiviteit van ontwikkelaars te optimaliseren ten opzichte van agent lock-in. Het vertelt je dat ze hebben besloten dat het platform wint als ontwikkelaars meer apps sneller leveren, ongeacht welke agent ze daarvoor gebruiken.

Die beslissing zal druk uitoefenen op elke andere eigenaar van een mobiel platform. Apple's verhaal over ontwikkelaarstools voor AI-agents bestaat op het moment van schrijven feitelijk niet: Xcode is op geen enkele manier scriptbaar op de manieren die een agent nodig heeft, en er is geen door Apple gezegende CLI voor het maken van projecten, simulatorcontrole of UI-inspectie. Als de productiviteitskloof tussen agentgestuurde Android-ontwikkeling en click-through-Xcode iOS-ontwikkeling 3x wordt, zoals de cijfers van Google suggereren, zal die kloof zich gaan manifesteren in de verzendsnelheid. Cross-platform teams zullen het merken.

Voor individuele ontwikkelaars is de praktische implicatie eenvoudiger. Als u voor Android bouwt en nog geen AI-agent in uw workflow gebruikt, is de oprit een stuk korter geworden. De CLI verwerkt de delen van de workflow waarvoor voorheen de IDE nodig was. Claude Code of Gemini CLI of Codex verzorgt de onderdelen waarvoor u vroeger nodig was. Jij wordt de architect, de recensent en de persoon die weet hoe goed eruit ziet – en de agent typt.

Als je wilt zien hoe ditzelfde patroon zich aan de desktopkant ontvouwt: mijn walkthrough van [Antigravity, Google's IDE voor AI-agents] (https://www.mejba.me/anti-gravity-ide-ai-agents), behandelt dezelfde verschuiving in IDE-vormige workflows. Hetzelfde draaiboek, ander oppervlak.

Waar de Android CLI nog steeds ruw is

Ik ben positief geweest in dit bericht omdat ik denk dat de lancering echt belangrijk is. Maar de preview-tag van v0.7 is eerlijk. Er zitten echte ruwe kantjes aan.

Er is nog geen subopdracht gradle. Wanneer de agent een plug-in moet toevoegen, een afhankelijkheid moet wijzigen of een build-versie moet wijzigen, moet hij build.gradle.kts-bestanden rechtstreeks bewerken. De agent kan dit doen; daar is het niet altijd even goed in. Een gradle add-plugin- of gradle add-dependency-opdracht zou een van de grootste resterende gaten dichten.

De vaardighedenbibliotheek is klein. Zes vaardigheden bij de lancering zijn een startpunt, geen voltooid systeem. De migratievaardigheid van XML naar Compose is uitstekend; de Google Play Billing-vaardigheid is prima; de anderen heb ik nog niet in de productie gebruikt. De bibliotheek moet groeien tot misschien veertig of vijftig vaardigheden voordat deze de werkelijke oppervlakte van algemene Android-taken kan bestrijken.

De emulatorintegratie is goed, maar niet kogelvrij. Ik raakte één harde bevriezing in drie uur gebruik. Dat is geen ramp, maar de betrouwbaarheid is nog niet zo hoog dat ik erop zou vertrouwen dat het van de ene op de andere dag onbeheerd op een CI-pijplijn zou draaien.

De documentatie-index omvat developer.android.com, Firebase-documenten en Kotlin-documenten. Het behandelt nog niet de Material Design-specificaties, AndroidX-releaseopmerkingen of de Jetpack-composables-referentie op een diepgaande manier. Die zullen komen. Voorlopig zal de agent soms een documentquery tegenkomen die niets nuttigs oplevert en moet hij terugvallen op zijn trainingsgegevens.

Geen van deze zijn blokkers. Het zijn allemaal problemen die in de komende drie tot zes releasecycli worden opgelost. Ik gok erop dat Google v1.0 door Google I/O 2026 zal leveren, waarbij de meeste van deze gaten zijn gedicht.

Wat te doen deze week

Als je Android-apps bouwt en je leest dit, dan is dit wat ik deze week zou doen.

Installeer de CLI. Het duurt vijf minuten. Voer android init uit en laat het vaardigheden installeren in de agent die u al gebruikt. Probeer android create voor een wegwerpproject – ervaar hoe snel het opstarten van een project kan zijn als de wizard verdwenen is.

Kies vervolgens een echte taak die u hebt vermeden. A Compose-migratie. Een navigatie 3-upgrade. Een R8-opruiming. Alles waarbij het werk grotendeels mechanisch maar vervelend is. Geef het aan uw agent met de CLI geïnstalleerd en kijk wat er gebeurt. De eerste keer dat een agent met succes een echte Android-taak van begin tot eind uitvoert, klikt er iets in de manier waarop u denkt over de rest van het werk dat op uw bord ligt.

Begin dan met schrijfvaardigheid voor je eigen team. Kies één architectonisch patroon dat uw team afdwingt (uw DI-conventies, uw testopstelling, uw foutafhandelingsaanpak) en schrijf een vaardigheid die een agent leert om het te volgen. Plaats het in uw repository. Laat je teamgenoten android init er tegenaan. Je hebt je team een ​​institutionele geheugenupgrade gegeven die elke keer groter wordt als iemand een agent op de codebase gebruikt.

Veelgestelde vragen

Is de Android CLI gratis?

Ja. De Android CLI kan gratis worden gedownload van d.android.com/tools/agents en wordt geleverd onder dezelfde open licentie als de rest van de Android-platformtools. Er is op dit moment geen betaalde niveau- of ondernemingslicentie.

Werkt de Android CLI met Claude Code?

Ja. Claude Code is een van de 37 ondersteunde agentdoelen. Nadat u de CLI hebt geïnstalleerd, voert u android init --agent=claude-code uit om de officiële vaardigheden in uw Claude Code-vaardighedenmap te installeren.

Heb ik Android Studio nog steeds nodig als ik de CLI heb?

Voor de meeste agentgestuurde workflows is dat niet het geval. U zult nog steeds Android Studio nodig hebben voor visuele foutopsporing, profileringswerk en complexe lay-outinspectie. Maar de dagelijkse projectcreatie, afhankelijkheidsbeheer, emulatorcontrole en UI-testen kunnen nu volledig vanaf de terminal plaatsvinden.

Waarin verschilt de Android CLI van adb?

adb is een debugging-bridge op laag niveau. De Android CLI is een workflowtool op een hoger niveau die adb, sdkmanager, avdmanager, delen van Gradle en de documentatie-index in één agentvriendelijke interface verpakt. De CLI gebruikt voor sommige bewerkingen adb onder de motorkap.

Wat doet android init eigenlijk?

Het scant uw thuismap op geïnstalleerde codeeragenten en plaatst vervolgens de officiële Android-vaardigheden in de vaardighedenmap van elke agent. Hierdoor leert elke agent op uw machine hoe hij de CLI moet gebruiken. Geef --agent=<name> door om de installatie op één agent te richten.

Het saaie commando dat van gedachten veranderde

Terug naar waar ik begon. android create. Lege activiteitensjabloon. Elf seconden.

Het zou gemakkelijk zijn om naar dat bevel te kijken en de schouders op te halen. Projectsteigers zijn niet het moeilijkste deel van de ontwikkeling van Android. Iedereen kan een project in de steigers zetten. Het moeilijkste is alles wat daarna komt.

Maar de reden dat dat commando mij is bijgebleven (de reden dat ik hier op dinsdag drieduizend woorden zit te schrijven over een ontwikkelaarstool) is dat het mij vertelde wat Google heeft besloten. Ze hebben besloten dat de wrijving bij het starten van dingen ertoe doet. Ze hebben besloten dat het ecosysteem van agenten belangrijker is dan de lock-in van agenten. Ze hebben besloten dat de volgende generatie Android-ontwikkelaars hun aandacht zullen besteden aan wat ze moeten bouwen, en niet aan hoe ze het bouwen ervan moeten opstarten.

Dat is een gok op een ander soort ontwikkelaar dan waarvoor Android Studio is gebouwd. Het is een weddenschap die ik graag aanneem.

De vraag voor jou is aan welke kant van die weddenschap je wilt staan. Besteed de vijf minuten. Installeer de CLI. Voer een echte taak uit via uw agent naar keuze. Kijk hoe elf seconden voelen als de tovenaar weg is. Vraag uzelf dan af: wat is er nog meer in uw workflow geweest dat u vergeten was te betalen?

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io