ADK for Kotlin 1.0 leva agentes de IA para dentro do app Android
A Google fechou a versão 1.0 do Agent Development Kit para Kotlin, com paridade com o core em Python e Java e extensões on-device que rodam agentes direto no celular.
A Google anunciou no Google Developers Blog, em 9 de setembro de 2026, a disponibilidade geral do ADK for Kotlin↳Kotlin4 conteúdosBootcamp com 10 mil bolsas gratuitas: DIO e NTTDATA lançam formação para iniciantes e profissionais de tecnologiaDev (Back & Front) · nov 2023TQI lança bootcamp de Kotlin com 25 mil bolsas de estudo gratuitas para desenvolvedoresDev (Back & Front) · abr 2023GitHub anuncia suporte para Swift e segurança mais ampla para aplicativos móveisDev (Back & Front) · jun 2023Ver tudo em Dev (Back & Front) → 1.0, o Agent Development Kit voltado a quem escreve agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → em Kotlin, Java e Android. A versão sai do experimental (o 0.1.0 tinha sido o primeiro passo) e chega, segundo o post assinado pelo Developer Advocate Guillaume Laforge, com paridade completa de funcionalidades em relação ao ADK 1.0 Core (a base que já existia em Python e Java).
O recado para quem constrói é direto: em vez de tratar o app como um cliente burro que só chama uma API de LLM e faz parse de JSON na mão, o ADK oferece o loop de orquestração (tool calling, multi-agente, human-in-the-loop, persistência de sessão) como biblioteca idiomática de Kotlin, tanto no servidor quanto dentro do dispositivo.
Function calling gerado em tempo de compilação
O diferencial técnico mais interessante para o dev Kotlin é como o ADK trata as ferramentas (tools). A definição de uma função exposta ao modelo é feita com anotações @Tool e @Param sobre métodos comuns, e o schema que o LLM enxerga é gerado via KSP (Kotlin Symbol Processing) em tempo de compilação, não em runtime.
Na prática isso significa três coisas que o post enfatiza: schemas type-safe, suporte a suspend fun (funções de corrotina) e zero reflexão em runtime. Quem já sofreu com bibliotecas que montam schema por reflection sabe o custo disso em app Android, onde reflexão pesa em tempo de inicialização e atrapalha o R8/ProGuard. Gerar tudo no build é a escolha certa para mobile.
O padrão fica assim: você declara um serviço com métodos anotados e o KSP cria a extensão generatedTools() para você.
class InfrastructureDiagnosticsService {
@Tool
suspend fun getServiceMetrics(
@Param("Target service or database cluster") serviceName: String,
@Param("Time window in minutes") windowMinutes: Int? = 15,
): ServiceMetrics {
// consulta Datadog, Prometheus, Cloud Monitoring...
}
}No agente, as ferramentas entram de forma declarativa via tools = InfrastructureDiagnosticsService().generatedTools().
Skills e progressive disclosure para não estourar o contexto
Além das tools executáveis, o ADK separa o que chama de skills: conhecimento procedural e playbooks de domínio carregados sob demanda através de um SkillToolset. A ideia, no exemplo de um agente de triagem de incidentes de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, é não cravar as diretrizes de SRE no código, mas colocá-las num arquivo SKILL.md em src/main/resources/skills/, com os passos do procedimento e a lista de allowed-tools.
O ponto que merece atenção é o mecanismo de progressive disclosure: recursos auxiliares (por exemplo, um mitigation_rules.txt com a regra de nunca reiniciar nós primários em horário de pico) só são buscados pelo modelo quando ele precisa, mantendo o uso de tokens enxuto. Para quem paga por token e sofre com janela de contexto, essa é uma decisão de arquitetura que importa mais do que parece: o playbook completo não entope o prompt a cada turno.
No exemplo do post, o agente recebe um alerta P1 de latência, carrega a skill de triagem, chama getServiceMetrics() (que retorna 98,5% de saturação do pool de conexões), correlaciona com fetchRecentDeployments(), aponta o deploy deploy-9842 de 25 minutos atrás ("Add unindexed batch query...") como causa raiz e posta o diagnóstico no canal #production-alerts, sugerindo rollback imediato. É um roteiro fabricado para a demo (os números vêm hardcoded no serviço), mas ilustra bem o loop autônomo estruturado que o framework roda.
O que muda no Android: on-device e persistência nativa
A parte que realmente diferencia o ADK for Kotlin dos SDKs em Python/Java são as extensões Android-first. O framework é construído sobre um core Kotlin Multiplatform (KMP) agnóstico a backend de modelo, provedor de sessão ou sistema de memória, e por cima disso conecta componentes de arquitetura padrão do Android:
| Necessidade | Extensão do ADK for Kotlin |
|---|---|
| Modelos rodando no dispositivo | LiteRT-LM e ML Kit (beta) |
| Workflows híbridos nuvem/local | Firebase AI Logic |
| Sessão persistida entre reinícios de processo | Room (SQLite) via RoomSessionService |
| Memória indexada com busca full-text | AppSearch via AppSearchMemoryService |
| Arquivos gerados (recibos, extratos) | Android storage via FileArtifactService |
No exemplo de um assistente financeiro com Gemini 3.8 Flash via Firebase AI, o runner é montado ligando esses serviços em poucas linhas:
fun createAndroidRunner(context: Context, agent: LlmAgent) = InMemoryRunner(
agent = agent,
appName = "AndroidFinancialApp",
sessionService = RoomSessionService.fromContext(context),
memoryService = AppSearchMemoryService.fromContext(context),
artifactService = FileArtifactService.fromExternalFilesDir(context),
)O que isso substitui é o esforço manual de amarrar histórico de chat em SQLite, memória de longo prazo e persistência de artefatos, sobrevivendo a process death (quando o Android mata o app em background). Rodar agente on-device com LiteRT-LM também abre a porta para privacidade e uso offline, algo que um agente 100% em nuvem não entrega.
Human-in-the-loop para ações sensíveis
Um agente que move dinheiro não pode agir sozinho, e o ADK trata isso de forma nativa. Basta marcar a ferramenta com requireConfirmation = true:
@Tool(
name = "transferFunds",
description = "Transfers money. Requires explicit user approval.",
requireConfirmation = true
)
fun transferFunds(@Param("Recipient account ID") recipientId: String, @Param("Amount in USD") amount: Double): StringQuando o modelo decide chamar essa ferramenta, o ADK pausa a execução e emite uma solicitação de confirmação sintética. A UI intercepta esse pedido, mostra o botão de confirmar e, no turno seguinte, devolve um FunctionResponse com CONFIRMED_KEY = true para retomar e executar a transferência. É o padrão de confirmação em dois turnos, com serialização e resumibilidade de sessão embutidas. O próprio post ressalva: o exemplo é ilustrativo e não foi desenhado para atender requisitos de compliance.
Quando não vale (e como começar)
O ADK for Kotlin faz sentido para quem já vive no ecossistema JVM/Android e quer agentes idiomáticos sem carregar Python no stack de produção. Do lado servidor, há integração com Vertex AI (VertexAiSessionService, VertexAiRagMemoryService, VertexAiMemoryBankService) e interoperabilidade de primeira classe com Java, ou seja, dá para chamar um agente Kotlin de dentro de uma aplicação Java existente.
Onde pesar antes de adotar: é um framework 1.0 recém-lançado, algumas extensões ainda estão em beta (ML Kit on-device, por exemplo) e a orquestração fica acoplada ao ecossistema Google (Gemini, Firebase, Vertex AI). Quem precisa de neutralidade de fornecedor ou já padronizou em LangChain/outro runtime multi-linguagem talvez não queira migrar só por conveniência de linguagem. E o custo de rodar modelo (seja token na nuvem, seja bateria e memória on-device) continua sendo problema de quem constrói, não do framework.
Para experimentar, as dependências vão no build.gradle.kts:
dependencies {
implementation("com.google.adk:google-adk-kotlin-core:1.0.0")
ksp("com.google.adk:google-adk-kotlin-processor:1.0.0")
// extensões Android opcionais
implementation("com.google.adk:google-adk-kotlin-firebase-android:1.0.0")
implementation("com.google.adk:google-adk-kotlin-litertlm:1.0.0")
}O código, os exemplos e a documentação estão no repositório github.com/google/adk-kotlin e em adk.dev.
Fonte: Google Developers Blog
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Diego Lima. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
Comentários
Ninguém comentou ainda. Começa a conversa?