Android CLI do Google: testei com Claude Code

Android CLI do Google: testei com Claude Code

A primeira coisa que tentei depois de instalar o novo Google do Android CLI foi o comando mais chato do manual. android create. Modelo de atividade vazio. Sem bandeiras inteligentes, sem prompt criativo - apenas a coisa mais comum que um cérebro treinado em Java poderia pensar depois de quinze anos clicando no assistente "Novo Projeto" do Android Studio.

Terminou em onze segundos. Um projeto Kotlin funcional. Gradle conectado. Componha dependências fixadas. Manifeste-se são. Abri o diretório no meu editor e olhei para ele como se tivesse me insultado.

Passei tantas horas da minha vida dentro daquele mago. Escolhendo versões mínimas do SDK. Alternando "Incluir suporte Hilt". Estou me perguntando se realmente quero um gráfico de navegação desta vez. O assistente está bem. É também um imposto que pago sempre que quero começar algo novo no Android – e o imposto é pago com atenção, não com minutos. Onze segundos em um terminal acabaram de removê-lo.

Essa foi a primeira surpresa. A segunda surpresa – a que realmente importou – veio cerca de uma hora depois, quando apontei Claude Code para Android CLI e observei um agente fazer algo que eu teria jurado que ainda faltava um ano.

É assim que se parece um lançamento silencioso e importante. Google apresentou uma prévia do Android CLI em 16 de abril de 2026, inserido em uma postagem do blog do desenvolvedor que nem chegou ao topo do Hacker News naquela semana. Nenhuma palestra. Nenhum vídeo de lançamento com tomadas cinematográficas de drones. Apenas um link para download em d.android.com/tools/agents, uma tag de visualização v0.7 e uma promessa silenciosa de que essa coisa foi construída primeiro para os agentes e depois para os humanos.

Quero explicar o que testei, o que funcionou, o que quebrou e por que acho que esta CLI irá remodelar a forma como construo aplicativos Android pelos próximos dois anos. Acompanhe-me durante a instalação - a parte interessante aparece no terceiro comando.

Por que uma CLI para Android Studio existe em 2026

Para entender por que o Google construiu isso, você precisa entender o problema que ele resolve. E o problema não é "Android Studio é irritante". Android Studio está bem. O problema é que os agentes AI não podem usar o Android Studio.

Pense em como Claude Code ou Codex ou Gemini CLI realmente funcionam. O agente lê arquivos. O agente grava arquivos. O agente executa comandos shell e lê sua saída. Essa é toda a área da superfície. É um sistema de entrada e saída de texto que fica em seu terminal. Quando você pede a um desses agentes para “criar uma nova tela para a página de configurações”, ele pode editar seus arquivos Kotlin o dia todo. O que ele não pode fazer é abrir o Android Studio, clicar em Arquivo → Novo → Atividade, preencher a caixa de diálogo e clicar em OK.

Portanto, nos últimos dois anos, todos os agentes que tocaram no desenvolvimento do Android têm feito essa dança estranha - gerando arquivos manualmente que o Android Studio teria gerado corretamente por meio de modelos, atrapalhando-se com a configuração do Gradle que ele não entendia totalmente e pedindo constantemente ao humano para "basta abrir o Studio e clicar aqui para mim". O agente era um colaborador brilhante com uma das mãos permanentemente amarrada nas costas.

O Android CLI corta esse nó. Ele expõe as partes do Android Studio que os agentes realmente precisam — criação de projetos, controle de emulador, inspeção de layout, pesquisa de documentação, captura de tela — como comandos simples que qualquer agente pode executar a partir de um shell. De repente, o agente tem as duas mãos.

Os números que Google relata confirmam isso de uma forma que eu não esperava. Em seus benchmarks internos, os agentes que usam o Android CLI concluíram tarefas 3x mais rápido e consumiram 70% menos tokens do que os agentes que tentaram conduzir diretamente o conjunto de ferramentas antigo. Geralmente sou cético em relação ao número de fornecedores – cada lançamento de ferramenta afirma que é 10 vezes mais rápido do que aquilo que substitui, e quase nunca é. Mas a redução simbólica de 70% passa no teste do cheiro para mim. Explicarei o porquê em um minuto, quando chegarmos ao comando de layout.

Antes de tudo isso, porém, vamos instalar a coisa. Porque Google tomou uma decisão aqui que vai confundir a primeira leva de desenvolvedores que tentarem isso.

Instalando o Android CLI: não é onde você pensa

Se você já tem o Android Studio instalado e assume que a nova CLI vem com ele - o mesmo que adb, sdkmanager e o restante das ferramentas da plataforma - você gastará dez minutos frustrados pesquisando em seu diretório Android/sdk por um binário que não existe lá.

O Android CLI é enviado separadamente. De propósito. Você o instala a partir do d.android.com/tools/agents, que fornece um único binário para macOS, Linux ou Windows. Nenhum sinalizador de gerenciador do SDK. Nenhum plug-in Gradle. Basta fazer o download, movê-lo para o seu PATH e pronto.

Eu instalei no meu Mac assim:

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

A saída -h é a primeira coisa que vale a pena ler. Ele lista todos os comandos suportados pela CLI — create, docs, emulator, screen, layout, resolve, skills, init — e uma descrição de uma linha para cada um. Eu li tudo duas vezes antes de executar qualquer outra coisa, porque a superfície de comando é pequena o suficiente para que você possa manter tudo em sua cabeça, o que é mais importante do que parece.

Após a instalação, o próximo passo é android init. É aqui que a mágica - e uma pequena pegadinha - acontece.

android init

O que o init faz: ele verifica seu diretório inicial em busca de agentes de codificação instalados, encontra cada um que reconhece e coloca uma cópia das habilidades oficiais do Android no diretório de habilidades de cada agente. Na minha máquina, ele encontrou Claude Code em ~/.claude/, largou a habilidade lá e me perguntou se eu queria que ela fosse instalada para Gemini CLI e Antigravity também. Eu disse sim para ambos, porque não.

A pequena pegadinha: se você não tiver nenhum agente de codificação instalado e executar init sem argumentos, o padrão é instalar habilidades para Gemini e Antigravity em ~/.gemini/antigravity/skills. Se você deseja definir o escopo da instalação, passe --agent=claude-code ou --agent=gemini ou qualquer destino que você realmente use. Aprendi isso da maneira mais difícil, depois de me perguntar por dez minutos por que a instalação do Cursor não estava adquirindo as habilidades - descobri que tive que executar novamente o android init --agent=cursor explicitamente.

O subcomando oficial skills add lista [37 alvos de agentes suportados] (https://www.devclass.com/development/2026/04/21/google-previews-android-cli-for-new-world-of-agentic-development/5218263) neste ponto - claude-code, gemini, codex, cursor, opencode, windsurf, cline, aider, github-copilot e uma longa cauda do ecossistema de agente de codificação menor. O que quer que você esteja usando, é quase certo que está na lista.

Assim que init terminar, a configuração estará concluída. A CLI é instalada, as habilidades são carregadas em seus agentes e você pode começar a usar os comandos humanos e as habilidades voltadas para o agente juntos. De agora em diante, tudo que testei abaixo funciona da mesma forma, quer eu execute os comandos diretamente ou deixe Claude Code conduzi-los.

Os seis comandos que realmente importam

A CLI expõe cerca de uma dúzia de subcomandos, mas seis deles são os que procuro sempre. Deixe-me examinar cada um deles com o que testei e o que aprendi.

android create — Andaime de projeto que evita perda de tempo

Esta é a droga de entrada. android create gera um projeto Android Studio completo a partir de um modelo, com padrões sensatos incorporados. O modelo padrão é empty-activity, que fornece um iniciador baseado em Compose com Kotlin, AGP 9 e um tema básico já instalado.

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

Onze segundos. Feito. Você pode passar --template para escolher algo diferente da atividade vazia – a visualização v0.7 vem com modelos para Compose Material 3, navegação e alguns outros pontos de partida comuns. Espero que esta lista cresça.

O que me surpreendeu aqui não foi a velocidade. Foi a consistência. Ao estruturar um projeto dessa maneira, você obtém os atual padrões recomendados pelo Google - aqueles que a equipe Android está mantendo ativamente. Chega de iniciar um projeto em 2026 com padrões que eram idiomáticos em 2023. A CLI é, na verdade, uma bomba de frescor opinativo para novos projetos.

android docs — O comando que torna seu agente menos errado

Este parece pequeno e é enorme. android docs search <query> atinge o índice de documentação oficial Android e retorna uma lista de URLs de documentos relevantes. android docs fetch <url> extrai o conteúdo de uma página de documento específica como texto simples.

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

Por que isso é enorme? Porque todo desenvolvedor Android que usou um agente AI viu o agente inventar com confiança uma API que não existe, ou gerar código com base em um padrão obsoleto de 2022, ou alucinar um modificador Compose que foi renomeado há dezoito meses. A razão pela qual isso acontece é que os dados de treinamento do agente foram congelados em algum momento no passado e o Android se move rapidamente.

Quando o agente tem acesso a android docs, ele pode fundamentar sua resposta na documentação atual no momento da consulta. Observei Claude Code usar esse padrão exato quando pedi para migrar um gráfico de navegação baseado em fragmentos para a Navegação 3 - o primeiro comando foi android docs search "navigation 3 migration", depois android docs fetch no resultado principal e, em seguida, ele escreveu o código que realmente compilou na API atual.

A propósito, essa é a redução de token de 70% sobre a qual você continua lendo. Não é mágica. O agente para de fazer perguntas esclarecedoras, para de gerar código quebrado que precisa ser consertado, para de fazer cinco tentativas para encontrar o nome do modificador correto. Uma pesquisa de documentos e, em seguida, uma edição correta. O custo do token docs fetch é real, mas pequeno; o custo simbólico de três rodadas de código quebrado e correção é enorme.

android emulator — Finalmente, controle do emulador a partir de um shell

Criar um emulador de dentro do Android Studio é bom. A ativação de um emulador a partir de um pipeline de CI ou de dentro de um loop de agente costumava exigir uma pilha de comandos avdmanager, sdkmanager e emulator que eu precisava consultar sempre. A nova CLI substitui isso por android emulator list, android emulator create, android emulator start e android emulator stop.

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

Testei isso em uma máquina limpa – nova instalação do SDK, sem AVDs pré-configurados. A CLI cuidou do provisionamento do perfil do dispositivo, do download da imagem do sistema, caso ela estivesse faltando, e do lançamento do emulador com configurações de janela sensatas. Cerca de noventa segundos de ponta a ponta em uma conexão com fio. Nada que eu não pudesse ter feito com cinco comandos de terminal; tudo que eu não precisava lembrar como fazer.

android layout — JSON em vez de capturas de tela e por que isso é importante

É aqui que a CLI começa a parecer que foi projetada por alguém que realmente enviou fluxos de trabalho de produção AI. android layout consulta o emulador ou dispositivo conectado atualmente em execução e retorna um documento JSON que descreve toda a hierarquia da UI – cada elemento, sua posição, seu conteúdo de texto, seus filhos.

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

A saída é uma árvore estruturada. Botões, campos de texto, itens de visualização do reciclador, modais — tudo isso representado como nós JSON com limites, identificadores e conteúdo. Um agente AI pode ler isso em algumas centenas de tokens e saber exatamente o que está na tela, quais botões existem, que texto eles mostram, onde estão no layout.

Compare isso com a alternativa, que pede ao agente para olhar uma captura de tela e descobrir a IU a partir de pixels. Os modelos de visão funcionam. Eles também queimam fichas como um fogão a lenha. Uma captura de tela de 1080p equivale a milhares de tokens, uma vez que o modelo a codifica; um layout JSON para a mesma tela geralmente custa menos de quinhentos. Para loops de agentes que precisam entender o estado da UI em cada turno, essa é a diferença entre um fluxo de trabalho acessível e um que custa dez dólares por tarefa.

Há também o android layout --automator, que recorre ao formato UI Automator XML clássico com os metadados focusable/enabled que os engenheiros de automação de teste vêm analisando há anos. A mesma ideia, formato ligeiramente diferente, útil quando você precisa das convenções da estrutura de teste.

android screen capture — Capturas de tela com anotações integradas

O comando screen capture faz o que você esperaria: tira uma captura de tela PNG do dispositivo atual. O sinalizador interessante é --annotate, que desenha caixas delimitadoras rotuladas ao redor de cada elemento da interface do usuário detectado e atribui um número a cada um.

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

Quando o agente possui uma captura de tela anotada, ele pode referir-se aos elementos por seu rótulo numérico. “Toque no elemento 4” em vez de “toque no botão que diz ‘Continuar’ no canto inferior direito”. Menos ambiguidade, menos toques errados, muito menos idas e vindas entre o agente e o dispositivo.

Esta é uma pequena melhoria ergonômica que aumenta enormemente durante uma longa sessão com o agente. Assisti a uma sessão Claude Code executar trinta interações de UI seguidas sem um único toque errado porque cada referência era numérica. Com capturas de tela brutas, você esperaria pelo menos três ou quatro falhas de ignição em tantas ações.

android screen resolve — A ponte entre o agente e o ADB

Depois que o agente decidir com qual elemento deseja interagir, android screen resolve converte o identificador numérico de uma captura de tela anotada em coordenadas reais de pixel no dispositivo atual.

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

Você pode canalizar essas coordenadas diretamente para adb shell input tap 540 1820 e terá um pipeline de automação de UI funcional. Este é o momento em que a CLI deixa de ser um auxiliar de estrutura de projeto e passa a ser uma cadeia completa de ferramentas de teste orientada por agente. Um agente pode: iniciar um emulador, instalar seu APK, capturar uma captura de tela anotada, decidir no que tocar, resolver coordenadas, disparar a torneira por meio do ADB, capturar outra captura de tela e verificar o novo estado – tudo em um loop contínuo, tudo em comandos simples.

Pelo que sei, é a primeira vez que alguém incorpora esse loop nas ferramentas oficiais Android. Não é uma estrutura de terceiros. Não é um projeto de pesquisa. O verdadeiro proprietário da plataforma o enviou.

Se você quiser ver como é um ecossistema de agentes quando ele é construído em torno de habilidades como essa desde o início, meu guia de habilidades de agentes para Claude Code percorre o mesmo padrão em um domínio diferente – e os paralelos são impressionantes.

O que construí em um fim de semana (e o que quebrou)

A teoria está bem. Deixe-me contar o que realmente aconteceu quando tentei usar isso para um trabalho real.

O projeto: um pequeno aplicativo rastreador de hábitos, baseado em Compose, três telas, banco de dados Room, Hilt for DI. Nada exótico. Algo que construí variantes meia dúzia de vezes para testar novas ferramentas.

O plano: fazer com que o Claude Code conduza toda a construção por meio do Android CLI. Eu escreveria a especificação em um arquivo markdown, entregaria-o a Claude e deixaria que ele criasse o projeto, configurasse as dependências, criasse a tela, testasse o emulador e iterasse por conta própria. Eu só interviria quando algo quebrasse.

O resultado, depois de uma tarde de sábado: um app funcionando no emulador. Três telas. CRUD sobre hábitos. Persistência trabalhando. Uma IU do Compose desajeitada, mas funcional. Tempo total conduzido pelo agente: cerca de três horas, com talvez quarenta e cinco minutos de intervenção humana.

O que funcionou lindamente:

A etapa de andaime do projeto foi instantânea. Claude executou android create --name HabitTracker --package me.mejba.habits e imediatamente solicitou ao índice de documentos as práticas recomendadas atuais na configuração do Hilt com o Compose. Ele recuperou o documento canônico, extraiu os trechos relevantes e adicionou as dependências e módulos sem errar. Todo o processo de inicialização do "diretório vazio" para "compilar e executar" levou oito minutos. Fiquei chocado.

O loop do emulador foi onde senti a verdadeira mudança. Claude escreveria uma tela, executaria android emulator start, construiria e instalaria o APK e, em seguida, android screen capture --annotate para ver como realmente era a tela. Quando o layout estava errado, ele comparava a captura de tela com minhas especificações, editava o arquivo Compose, reconstruía e capturava novamente. Nenhum humano envolvido no feedback visual – o agente poderia ver seu próprio trabalho e iterá-lo. Eu queria isso há dois anos.

O que quebrou:

A primeira parede dura foi Hilt. Claude gerou um módulo Hilt perfeitamente correto que não funcionou porque o plugin kapt não estava habilitado no arquivo Gradle do projeto. A mensagem de erro era clara; a correção foi uma linha. Claude descobriu na segunda tentativa, mas só depois que eu dei uma dica de que o problema era a configuração do Gradle e não o código Hilt. A CLI ainda não possui um subcomando gradle, e essa é uma lacuna que senti.

A segunda barreira difícil foi a estabilidade do emulador. Cerca de duas horas depois, meu emulador atingiu um estado em que não respondia ao toque. android screen capture retornou uma imagem congelada. adb shell input tap não fez nada. Tive que android emulator stop manualmente, reiniciá-lo e reinstalar o aplicativo. Claude não poderia ter se recuperado disso sozinho – o modo de falha estava abaixo da camada de abstração da CLI. Isso ficará mais suave com o tempo, mas ainda não é suave.

A terceira questão foi mais interessante. Cerca de 80% da construção, Claude ficou com preguiça. As visualizações do Compose geradas pararam de usar os provedores @PreviewParameter configurados anteriormente; o andaime de teste escrito na tela um não foi transportado para as telas dois e três. A CLI não pode resolver isso — é um problema de comportamento do agente, não um problema de ferramentas. Mas é um lembrete de que a CLI elimina o atrito do ciclo de construção sem remover a responsabilidade de realmente direcionar o trabalho do agente.

Se você leu meu artigo sobre por que [o contexto supera a configuração no design do agente] (https://www.mejba.me/ai-agent-context-beats-configuration), você sabe que sou um recorde quebrado neste ponto. Ferramentas melhores não substituem uma direção melhor. Eles apenas permitem que a má direção falhe mais rápido.

O sistema de habilidades: esta é a verdadeira história

Tenho falado sobre comandos por duas mil palavras. Deixe-me voltar e falar sobre a parte que acho que será mais importante no próximo ano - e sobre a qual quase ninguém está falando ainda.

O Android CLI vem com um sistema de habilidades do agente — arquivos markdown que ensinam um agente como usar a CLI para uma tarefa específica. A visualização v0.7 vem com habilidades para configuração do Navigation 3, migração de ponta a ponta, atualização de AGP 9, migração de XML para Compose, análise de regra de manutenção R8 e atualização da biblioteca Google Play Billing.

Ao executar android init, essas habilidades são instaladas no diretório de habilidades do seu agente. Quando você solicita que Claude Code "migre este layout XML para o Compose", ele carrega a habilidade relevante, segue as instruções escritas por Google e usa os comandos CLI recomendados pela habilidade. O agente não está mais adivinhando como fazer uma migração do Compose com base em seus dados de treinamento – ele está seguindo o manual oficial da equipe Android para essa tarefa específica.

Este é o padrão que estou esperando há dois anos que alguém envie. O proprietário da plataforma – a equipe que realmente conhece a maneira certa de fazer algo – escreve o manual uma vez, em um formato que o agente possa ler, e cada desenvolvedor que usa qualquer agente obtém o benefício. Não é um tutorial enterrado em developer.android.com que ninguém lê. Não é uma resposta Stack Overflow correta em 2022. Um conjunto de instruções ao vivo, executável e legível pelo agente, mantido pela equipe proprietária da plataforma.

Se Google fizer isso bem - e "fazer isso bem" significa um fluxo constante de novas habilidades, atualizações rápidas quando as APIs mudam, integração profunda com o resto da plataforma - esta será a ferramenta de desenvolvedor mais subestimada de 2026. A CLI é a superfície. As habilidades são a substância.

E aqui está algo que ninguém na cobertura do lançamento mencionou: você pode escrever suas próprias habilidades. O formato está aberto. Se sua equipe tiver padrões de arquitetura — “sempre use este padrão de DI, nunca este” — você pode escrever uma habilidade que ensine todos os agentes de sua equipe a segui-los. Você pode enviar essa habilidade como parte do seu repo. Um novo desenvolvedor entra, executa android init e, de repente, seu agente impõe os padrões de sua equipe. A memória institucional da sua base de código torna-se executável.

Isso é uma coisa silenciosa, estranha e importante. Vou escrever mais sobre isso.

O que isso significa para o desenvolvimento do Android em 2026

Deixem-me dizer o que penso que está a acontecer aqui, porque não vejo isso claramente expresso em mais lado nenhum.

Google acabou de dizer à comunidade de desenvolvedores Android que o futuro do desenvolvimento do Android é orientado por agentes, e eles construíram as ferramentas oficiais em torno dessa suposição. Não como uma aposta paralela. Não como um projeto de laboratório experimental. Como a próxima geração de como a plataforma espera que você trabalhe.

O sinal é inconfundível quando você olha o que eles fizeram e o que não fizeram. Eles não criaram uma "CLI Gemini para Android". Eles construíram uma CLI que oferece suporte a 37 agentes em igualdade de condições, incluindo Claude Code e Codex – concorrentes diretos de seu próprio Gemini. Essa é uma decisão estratégica do Google para otimizar a produtividade do desenvolvedor em vez da dependência do agente. Isso indica que eles decidiram que a plataforma vence quando os desenvolvedores lançam mais aplicativos com mais rapidez, independentemente do agente que usam para fazer isso.

Essa decisão pressionará todos os outros proprietários de plataformas móveis. A história de ferramentas de desenvolvedor da Apple para agentes AI é, no momento em que este artigo foi escrito, basicamente inexistente - o Xcode não é programável em nenhuma das maneiras que um agente precisa e não há CLI abençoado pela Apple para criação de projetos, controle de simulador ou inspeção de UI. Se a lacuna de produtividade entre o desenvolvimento Android orientado por agente e o desenvolvimento click-through do Xcode iOS se tornar 3x, como sugerem os números do Google, essa lacuna começará a aparecer na velocidade de envio. As equipes multiplataforma perceberão.

Para desenvolvedores individuais, a implicação prática é mais simples. Se você construir para Android e ainda não estiver usando um agente AI em seu fluxo de trabalho, a rampa de acesso ficou muito mais curta. A CLI lida com as partes do fluxo de trabalho que exigiam o IDE. Claude Code ou Gemini CLI ou Codex lida com as partes que costumavam exigir de você. Você se torna o arquiteto, o revisor e a pessoa que sabe o que é bom - e o agente digita.

Se você quiser ver como esse mesmo padrão está se desdobrando no lado da área de trabalho, meu passo a passo de Antigravity, IDE do Google para agentes AI, cobre a mesma mudança nos fluxos de trabalho em formato de IDE. Mesmo manual, área de superfície diferente.

Onde o Android CLI ainda é difícil

Fui positivo neste post porque acho que o lançamento é genuinamente importante. Mas a tag de visualização v0.7 é honesta. Existem verdadeiras arestas.

Ainda não há subcomando gradle. Quando o agente precisa adicionar um plug-in, modificar uma dependência ou alterar um tipo de construção, ele precisa editar os arquivos build.gradle.kts diretamente. O agente pode fazer isso; nem sempre é bom nisso. Um comando gradle add-plugin ou gradle add-dependency fecharia uma das maiores lacunas restantes.

A biblioteca de habilidades é pequena. Seis habilidades no lançamento são um ponto de partida, não um sistema acabado. A habilidade de migração de XML para Compose é excelente; a habilidade Google Play Billing é adequada; os outros ainda não usei em produção. A biblioteca precisa crescer para talvez quarenta ou cinquenta habilidades antes de cobrir a área de superfície real das tarefas comuns do Android.

A integração do emulador é boa, mas não à prova de balas. Atingi um congelamento forte em três horas de uso. Isso não é um desastre, mas ainda não atingiu o nível de confiabilidade onde eu confiaria que funcionaria sem supervisão durante a noite em um pipeline de CI.

O índice de documentação abrange developer.android.com, documentos do Firebase e documentos do Kotlin. Ele ainda não cobre as especificações do Material Design, as notas de lançamento do AndroidX ou a referência dos elementos que podem ser compostos do Jetpack de forma profunda. Esses virão. Por enquanto, o agente às vezes acessa uma consulta de documentos que não retorna nada de útil e precisa recorrer aos dados de treinamento.

Nenhum destes são bloqueadores. Todos eles são os tipos de problemas que serão corrigidos nos próximos três a seis ciclos de lançamento. Aposto que Google será enviado v1.0 por Google I/O 2026 com a maioria dessas lacunas fechadas.

O que fazer esta semana

Se você cria aplicativos Android e está lendo isto, aqui está o que eu faria esta semana.

Instale a CLI. Demora cinco minutos. Execute android init e deixe-o instalar habilidades em qualquer agente que você já usa. Experimente android create em um projeto descartável - tenha uma ideia de quão rápido o bootstrap do projeto pode ser quando o assistente termina.

Em seguida, escolha uma tarefa real que você tem evitado. Uma migração do Compose. Uma atualização do Navegação 3. Uma limpeza R8. Qualquer coisa em que o trabalho seja principalmente mecânico, mas tedioso. Entregue ao seu agente com a CLI instalada e veja o que acontece. A primeira vez que um agente conduz com êxito uma tarefa Android real de ponta a ponta, algo muda a forma como você pensa sobre o resto do trabalho que está em seu prato.

Em seguida, comece a escrever habilidades para sua própria equipe. Escolha um padrão de arquitetura que sua equipe aplica – suas convenções de DI, sua configuração de teste, sua abordagem de tratamento de erros – e escreva uma habilidade que ensine um agente a segui-lo. Solte-o em seu repositório. Deixe seus companheiros de equipe android init contra isso. Você terá dado à sua equipe uma atualização de memória institucional que aumenta toda vez que alguém usa um agente na base de código.

Perguntas frequentes

O Android CLI é gratuito?

Sim. O Android CLI pode ser baixado gratuitamente do d.android.com/tools/agents e é fornecido sob o mesmo licenciamento aberto que o restante das ferramentas da plataforma Android. Não há nível pago ou licença empresarial neste momento.

O Android CLI funciona com o Claude Code?

Sim. Claude Code é um dos 37 destinos de agente suportados. Depois de instalar a CLI, execute android init --agent=claude-code para instalar as habilidades oficiais em seu diretório de habilidades Claude Code.

Ainda preciso do Android Studio se tiver a CLI?

Para a maioria dos fluxos de trabalho orientados por agentes, não. Você ainda vai querer o Android Studio para depuração visual, trabalho de criador de perfil e inspeção de layout complexa. Mas a criação diária de projetos, o gerenciamento de dependências, o controle do emulador e os testes de UI agora podem acontecer inteiramente a partir do terminal.

Qual a diferença entre o Android CLI e o adb?

adb é uma ponte de depuração de dispositivo de baixo nível. O Android CLI é uma ferramenta de fluxo de trabalho de nível superior que agrupa adb, sdkmanager, avdmanager, partes do Gradle e o índice de documentação em uma única interface amigável ao agente. A CLI usa adb nos bastidores para algumas operações.

O que o android init realmente faz?

Ele verifica seu diretório inicial em busca de agentes de codificação instalados e, em seguida, coloca as habilidades Android oficiais no diretório de habilidades de cada agente. Isso ensina todos os agentes em sua máquina como usar a CLI. Passe --agent=<name> para definir o escopo da instalação para um único agente.

O comando chato que mudou minha mente

De volta ao ponto de partida. android create. Modelo de atividade vazio. Onze segundos.

Seria fácil olhar para esse comando e encolher os ombros. O andaime do projeto não é a parte difícil do desenvolvimento do Android. Qualquer um pode estruturar um projeto. O difícil é tudo o que vem depois.

Mas a razão pela qual esse comando ficou comigo - a razão pela qual estou sentado aqui escrevendo três mil palavras sobre uma ferramenta de desenvolvedor em uma terça-feira - é que ele me disse o que o Google decidiu. Eles decidiram que o atrito de começar as coisas é importante. Eles decidiram que o ecossistema do agente é mais importante do que o aprisionamento do agente. Eles decidiram que a próxima geração de desenvolvedores Android dedicará sua atenção ao que construir, não em como iniciar a construção.

Essa é uma aposta em um tipo de desenvolvedor diferente daquele para o qual o Android Studio foi construído. É uma aposta que estou feliz em fazer.

A questão para você é de que lado dessa aposta você deseja estar. Gaste os cinco minutos. Instale a CLI. Execute uma tarefa real através do agente de sua escolha. Veja como são onze segundos quando o assistente se vai. Em seguida, pergunte-se: o que mais em seu fluxo de trabalho foi um imposto que você esqueceu que estava pagando?

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

• Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e marca): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io