Android Studio abre para 40 agentes de IA

O gargalo de codar mobile com IA genérica

Android Studio sempre foi um ambiente pesado para quem tenta usar IA de forma improvisada. Você pede para um modelo genérico gerar uma tela em Jetpack Compose, ele devolve um código que parece certo, mas quebra no Gradle, ignora permissões, erra o lifecycle e não entende o que o Logcat está dizendo. Quem já tentou colar trace de ANR ou heap dump no chat sabe como isso vira adivinhação. O contexto real do projeto, estrutura de módulos, símbolos, emulator, políticas da Play, tudo ficava fora da janela do modelo. O resultado era retrabalho constante e token queimado à toa.

É exatamente essa fricção que o Google tenta eliminar agora. Em vez de melhorar só o Gemini dentro da IDE, a empresa abriu a porteira para agentes externos trabalharem direto no projeto. A mudança parece simples, mas muda a arquitetura do desenvolvimento mobile. Não é mais sobre autocomplete esperto, é sobre dar para o agente acesso a ferramentas, terminal, profiler e até dispositivo físico. Para quem opera app em produção, a pergunta deixa de ser qual modelo escreve melhor e passa a ser qual agente entende o Android de verdade.

O fato: Android Studio virou um hub de agentes

O anúncio central do Android Dev Summit foi o Bring Your Own Agent no Android Studio Rabbit 2. Na prática, a IDE agora fala o protocolo aberto Agent Client Protocol e permite instalar e rodar mais de 40 agentes de código pelo marketplace interno. Isso inclui o Claude Agent da Anthropic, o Codex da OpenAI e o Antigravity do próprio Google, rodando lado a lado. Esses agentes não ficam só sugerindo texto, eles acessam estrutura do projeto, resolução de símbolos, emulator e Logcat de forma nativa.

Junto com isso, o Google lançou o Android Bench 2.0 para comparar modelos em projetos de vários dias, levando em conta funcionalidade, tempo e custo, além de ferramentas como o Change Review, que analisa diffs pendentes, aponta bugs e explica mudanças passo a passo. A versão Canary ainda traz um assistente de migração de XML para Compose e o teste do Lightbuild, um sistema de build declarativo em YAML legível tanto por humanos quanto por agentes. E fora da IDE, apareceu até o XREAL AURA, óculos de 1.099 dólares com Android XR que usa o Gemini para entender o ambiente e projetar workspaces virtuais.

Como funciona na visão de quem opera

Pelo que dá para inferir da arquitetura, o Google separou em duas camadas. Dentro da IDE, o ACP funciona como uma ponte padronizada entre agente e ferramentas do Android Studio. O agente pede para listar arquivos, resolver um símbolo, instalar no emulator ou filtrar o Logcat, e a IDE executa. Isso evita aquele fluxo antigo de copiar e colar contexto manualmente. No terminal e no CI, a história é o Android CLI virando plugin oficial para Claude Code, Codex e Antigravity, o que permite rodar o mesmo agente fora da interface gráfica.

O detalhe mais interessante para custo e latência está nos previews de Compose renderizados direto no terminal. Segundo testes internos do Google, agentes concluíram tarefas de UI 77% mais rápido e com até três vezes menos tokens, porque não precisam subir o emulator só para checar visual. Outra jogada esperta foi tirar a análise de heap dump do celular e jogar para a máquina host, com o LeakCanary integrado ao CLI e ao Profiler. Em teste A/B com o Claude Opus 5.5, isso quase dobrou a velocidade para achar memory leaks e cortou 25% dos tokens. Somam-se a isso comandos para capturar traces com o Android Performance Analyzer, puxar crashes do Firebase Crashlytics, checar otimização no compilador R8 e mais de 30 Android Skills que injetam documentação atualizada no prompt, como checagem de políticas da Play antes do submit.

Onde entra o Gemini Nano e o on-device

A outra peça é a Agentic API com Gemini Nano 4 e o suporte a Model Context Protocol. A ideia é permitir funções de agente rodando localmente no smartphone, sem roundtrip para a nuvem para tarefas simples, e plugar serviços do app direto na Busca do Google e no app Gemini. Ainda não há números públicos de latência ou consumo de bateria, mas é plausível que o Nano cuide de classificação, resumo e roteamento local, enquanto tarefas pesadas de código continuam no modelo grande via nuvem. Para produto, isso abre caminho para assistentes dentro do app que não dependem de backend próprio.

O que isso muda na prática

Quem ganha primeiro é o time mobile que já vive no terminal e no CI. Se você mantém um app com vários módulos, flavors e testes instrumentados, poder delegar para um agente que roda build, abre preview, lê trace e propõe fix com verificação é uma economia real de ciclo. Indie devs também ganham, porque podem usar o Claude para refatoração pesada e o Codex para gerar testes, sem trocar de IDE. Quem perde um pouco são as extensões e wrappers que só faziam ponte entre IDE e API externa, porque agora a integração é nativa.

• Troque um fluxo manual por agente com verificação: deixe o agente gerar, mas exija passar no Change Review e em build limpo antes do merge.
• Adote o preview via CLI para telas de Compose e meça tokens antes e depois, o ganho de 3x menos tokens precisa aparecer na sua fatura.
• Alimente o agente com Skills oficiais para permissões, Play Policy e R8, em vez de confiar só no treinamento do modelo.

Uma ação prática para esta semana é simples. Instale o plugin do Android CLI no seu agente atual, escolha uma tela pequena em Compose e peça para iterar só pelo terminal, sem abrir o emulator. Ative a captura de trace e o pull de crashes do Crashlytics pelo agente e compare o tempo com seu fluxo antigo. Se você não medir custo por tarefa resolvida, vai achar que está mais rápido quando na verdade só está gastando mais tokens em loop.

Isso escala ou só move o gargalo?

Aqui fica minha dúvida real. Abrir para 40 agentes resolve o problema de contexto, mas cria um problema novo de orquestração e custo. Agentes com acesso a emulator, dispositivo físico via streaming dos labs do Google, profiler e rede podem entrar em loop, rodar builds repetidos e estourar cota de API sem entregar. O Change Review ajuda, mas revisão gerada por IA de código gerado por IA ainda precisa de humano que entenda Android de verdade, senão vira aprovação automática de bug sutil de lifecycle ou vazamento de memória. E tem o lock-in silencioso. O ACP é aberto, mas as melhores ferramentas, preview rápido, streaming de device, integração com Crashlytics, continuam no ecossistema Google.

No fim, o Google acertou no diagnóstico. Desenvolvimento Android não precisava de mais um chatbot, precisava de agentes com mãos na ferramenta e olhos no custo. Se o ganho de velocidade com menos tokens se confirmar fora do lab, isso vira padrão para mobile. Mas fica a pergunta que todo tech lead deveria fazer antes de liberar geral: quem paga a conta quando o agente resolve rápido, porém do jeito errado?