Android Dev Summit 2026: o Google volta a reunir devs depois de quatro anos e coloca os agentes no centro do Android

Mountain View, 28 de outubro de 2026 — Depois de quatro anos sem um evento próprio, o Google voltou a realizar o Android Dev Summit. A última edição tinha sido em 2022; desde então, as novidades da plataforma dividiam espaço com o resto da programação do Google I/O. Desta vez foram dois dias dedicados só ao Android, no campus Bay View, com keynote transmitido no YouTube e uma edição estendida em Londres.

O recado do keynote foi direto: o Android passa a ser construído com agentes de IA e para agentes de IA. O Android Studio abriu as portas para agentes de outras empresas, como Claude e Codex. O Android CLI deu a esses agentes acesso a aparelhos reais. E os apps ganharam um jeito padronizado de oferecer suas funções ao Gemini.

Neste briefing eu reúno o que foi anunciado, em que estágio cada novidade está e — a parte que o keynote passa rápido — como usar cada uma no dia a dia, com código.

Ficha do evento

Quando	28 e 29 de outubro de 2026
Onde	Campus Bay View do Google, Mountain View (EUA), com edição estendida em Londres
Contexto	Primeiro Android Dev Summit desde 2022
Trilhas	AI experiences, Android XR, Apps foundation, Tools & performance
Keynote	Cerca de 1 hora, com demos ao vivo — assista no YouTube

As manchetes

• Android Studio Rabbit 2 chega ao canal stable e aceita qualquer agente de código compatível com ACP — Claude, Codex, Antigravity e mais de 40 outros.
• Android CLI ganha aparelhos físicos remotos, renderização de Compose Preview no terminal, profiler com LeakCanary e plugins oficiais para Claude Code e Codex.
• Checklist de publicação em semáforo: a skill play-policy-insights audita o app antes do envio ao Google Play e aponta 🟢🟡🔴 o que falta.
• Migração de XML para Compose com um clique direito, conduzida por um agente dentro do Android Studio.
• AppFunctions entra em beta: funções do seu app viram tools para o Gemini e outros agentes, via Android MCP.
• A2UI (alpha): o agente passa a responder com telas nativas em Compose, montadas com o seu design system.
• Gemini Nano 4 + ML Kit Agentic API (alpha): um agente inteiro rodando no aparelho, com chamada de funções.
• Jetpack AppState (alpha) leva o modelo de estado do Compose para ViewModels e repositórios.
• Googlebook, foldables e Android XR: um código para muitas telas. O XREAL AURA estreia como o primeiro óculos XR com fio rodando Android XR.

---

1. O que já dá para usar (e o que ainda é laboratório)

Antes de sair instalando tudo, vale olhar a maturidade de cada anúncio.

Minha regra prática: stable vai para produção, beta entra atrás de feature flag, alpha e preview ficam em POC e estudo.

---

2. Android Studio Rabbit 2: traga o seu agente

O Android Studio deixou de ser "o IDE com o Gemini". Com o Bring Your Own Agent (BYOA), agora stable no Rabbit 2, ele vira o host de qualquer agente compatível com o Agent Client Protocol (ACP).

Como ativar:

1. Abra Settings > Tools > AI > Agents.
2. Instale agentes pelo marketplace (Claude Agent, Codex, Antigravity…). Dá para ter vários e alternar.
3. O agente passa a enxergar o que só o IDE sabe: estrutura do projeto e do build, resolução de símbolos, render de Compose Preview, Emulator e Logcat.

Junto vieram três recursos que mudam o dia a dia:

• Change Review — revisão agêntica das mudanças que o agente fez. Inicie pela lista de mudanças pendentes, pela janela de Git ou com /review. Gera relatório de problemas e um walkthrough guiado para mudanças grandes.
• Migration Assistant (Canary) — clique direito em um layout XML > AI › Migrate to Compose e o agente migra a tela para Compose. Tem uma seção inteira só sobre isso mais abaixo.
• Android Bench 2.0 — leaderboard que avalia modelos e harnesses em tarefas Android longas (migrar UI, construir app a partir de mocks), medindo se funciona de verdade, custo e tempo. Ótimo para escolher o agente do time: developer.android.com/bench.

ACP x MCP: não confunda

Esse foi o ponto que mais vi gerar confusão. São dois protocolos com papéis diferentes:

---

3. Android CLI: o toolchain inteiro na mão do agente

O Android CLI é a interface "tool-first" para qualquer terminal, agente ou pipeline de CI. A ideia é simples: o agente para de gastar tokens adivinhando como o Android funciona e passa a usar ferramentas oficiais.

# instale o CLI e configure o agente
android init

# aparelho físico real, num device lab do Google (via Firebase)
android device remote connect
android device hub            # janela para ver e controlar aparelhos e emuladores

# Compose Previews sem emulador e sem IDE
android preview

# performance e memória
android profiler systemtrace
android profiler heapdump capture
android profiler leakcanary

# qualidade do binário e sinais de produção
android analyze app-release.aab
android signals

# skills e documentação
android skills list
android skills add jetpack-compose-performance
android docs search "predictive back"

Os números divulgados pelo Google chamam atenção: agentes usando android preview terminaram tarefas de UI 77% mais rápido usando até 3x menos tokens.

Plugins oficiais para Claude Code e Codex

# Claude Code (dentro da sessão)
/plugin marketplace add android/android-cli-plugin
/plugin install android-cli@android-cli-plugin

# Claude Code (terminal)
claude plugin marketplace add android/android-cli-plugin
claude plugin install android-cli@android-cli-plugin

# Codex
codex plugin marketplace add android/android-cli-plugin
codex plugin add android-cli@android-cli-plugin

O plugin dá ao agente o necessário para criar projetos, gerenciar emuladores, inspecionar layouts ao vivo, rodar Journeys, instalar skills oficiais e consultar a Android Knowledge Base.

Skills oficiais

São mais de 30 skills em mais de 20 áreas, cada uma com avaliação. Elas focam onde os modelos costumam errar: performance de Compose, APIs novas de câmera, auditoria de segurança. Algumas que valem instalar já:

• jetpack-compose-performance
• android-profiler
• r8-analyzer
• play-policy-insights (audita código, manifest e SDKs contra as políticas do Play antes do envio)
• android-intent-security e android-permissions-security

Repositório: github.com/android/skills.

---

4. Validação: o agente confere o próprio trabalho

O trecho "Validating apps with Android Prototype" do keynote (12:45) bate numa tecla: agente bom é agente que valida o que fez. A demo mais marcante foi com o Claude Code:

O Google deu ao agente uma lista de jornadas críticas e um único prompt — encontrar e corrigir memory leaks. O Claude rodou cada jornada num aparelho separado, em paralelo, usou android profiler leakcanary, seguiu as cadeias de referência até o código, corrigiu e rodou tudo de novo para confirmar.

O que sustenta esse fluxo:

• Journeys — fluxos de usuário descritos em linguagem natural. O time escreve, o agente executa.
• LeakCanary integrado — no CLI e no Profiler do Studio, com Fix with AI (Canary).
• Android Performance Analyzer (APA) — o motor do Profiler agora também alimenta o CLI. Com a skill android-profiler, o agente captura trace, analisa, propõe correção e mede o impacto.
• androidx.tracing 2.0 — traces com arquivo, linha e argumentos; coroutines aparecem como fluxos conectados. Comece com androidx.tracing:tracing-wire.
• Recomposition tracing (Compose 1.13) — mostra por que algo recompôs, até a escrita de estado que causou.

Do crash em produção à correção

android signals traz crashes, ANRs e problemas de memória para o terminal. E o Crashlytics agora coleta heap dumps de OOMs reais e de Memory Limiter Kills do Android 17, desofuscados com o mapping do R8 e abertos no Perfetto (em early access).

R8 sem medo

# AGP 9.3: nota da sua configuração e ranking das keep rules mais caras
./gradlew :app:analyzeReleaseR8Config

Combine com a skill r8-analyzer e troque keep rules genéricas por Jetpack Keep (alpha), com anotações type-safe que o lint adiciona por você.

---

5. Antes do deploy: o checklist em semáforo

Um dos momentos mais práticos do evento: em vez de um checklist manual de publicação, você pede ao agente que audite o app e ele devolve um relatório em semáforo — 🟢 o que está ok, 🟡 o que precisa de revisão, 🔴 o que bloqueia o envio.

A skill oficial: play-policy-insights

Esse formato vem da skill oficial play-policy-insights, que audita código, manifest e SDKs contra as políticas do Google Play e cruza com a sua declaração de Data safety.

1. Instale a skill

android skills add play-policy-insights

# alternativa, fora do Android CLI:
npx skills add https://github.com/android/skills --skill play-policy-insights

2. Rode com um prompt (o Google sugere este):

Audit this app for Google Play policy compliance before I submit it.

3. O que ela verifica

• Data safety — compara o que o código coleta e envia com o que você declarou no Play Console.
• Credenciais de login de demonstração — se os revisores do Play conseguem entrar no app.
• Permissões restritas — uso de permissões sensíveis ou obsoletas onde há alternativa com escopo.

4. Como ler o relatório

Status geral	Significado	O que fazer
🟢 Compliant	Nenhuma violação ativa encontrada	Seguir com o envio
🟡 Needs Review	Sem violações críticas, mas há declarações manuais no Play Console ou permissões restritas para revisar	Revisar antes de enviar
🔴 Non-Compliant	Violações ou divergências no Data safety	Corrigir antes do envio

Cada achado tem severidade — 🔴 Critical (violação confirmada), 🟡 Important (por exemplo, permissão obsoleta onde se espera uma com escopo), 🔵 Suggestion (recomendação) — e vem com política afetada, arquivos, evidência, nível de confiança, recomendação e links. O relatório termina com divergências de Data safety, acessos locais a dados e um checklist de remediação.

Dois cuidados:

• O relatório é consultivo: não é parecer jurídico nem garantia de aprovação.
• A skill grava arquivos temporários em .scratch/play_policy_insights_<uuid> na raiz do projeto. Coloque .scratch/ no .gitignore.

No Android Studio, o Play Policy Insights também aparece como verificações de lint direto no código.

Indo além: uma skill de "release readiness" com todos os gates

A política do Play é só um dos portões. Com as ferramentas do Android CLI dá para montar uma skill própria que roda todos os gates e devolve um único semáforo. Este é um exemplo que escrevi para estudo — adapte os caminhos e limites ao seu projeto:

---
name: release-readiness
description: Use antes de publicar uma release. Roda os gates de build, tamanho, política do Play, segurança, estabilidade e jornadas críticas e devolve um relatório em semáforo.
---

# Release readiness

Rode todos os gates abaixo, em ordem. Não pare na primeira falha: o relatório precisa mostrar todos.

## Gates

1. **Build** — `./gradlew :app:bundleRelease`. 🔴 se falhar.
2. **Tamanho e R8** — rode `android analyze` no AAB de release e `./gradlew :app:analyzeReleaseR8Config`.
   🟡 se a nota de shrinking caiu em relação a `docs/release/last-analyze.json`. 🔴 se a ofuscação estiver desligada.
3. **Política do Play** — rode a skill `play-policy-insights` e copie o status geral dela.
4. **Segurança** — rode as skills `android-permissions-security` e `android-intent-security`. 🔴 para qualquer achado Critical.
5. **Estabilidade** — `android signals` na versão de produção atual. 🟡 para novos clusters de crash ou ANR.
   🔴 se a taxa de usuários sem crash ficou abaixo do limite em `docs/release/thresholds.md`.
6. **Jornadas críticas** — rode as Journeys de `journeys/`. 🔴 se alguma falhar.

## Saída

Escreva `release-report.md` com:
- status geral (o pior gate define o status);
- uma linha por gate: status, gate, evidência, próxima ação;
- checklist de remediação.

Não publique, não faça upload e não crie tags. A decisão de publicar é humana.

No Claude Code, salve em .claude/skills/release-readiness/SKILL.md e chame com /release-readiness. Em outros agentes, use a pasta de skills equivalente. A regra "o pior gate define o status" é o que transforma seis verificações num semáforo único e honesto.

---

6. Compose-first na prática: de XML para Compose com um clique direito

Outro destaque do keynote: migrar uma tela de XML Views para Jetpack Compose deixou de ser um projeto manual. O Migration Assistant (Android Studio Canary) aparece no menu de contexto do layout e entrega o trabalho para um agente.

Passo a passo

1. Instale o Android Studio Canary mais recente — a feature está nesse canal.
2. Escolha o agente. Funciona com o agente nativo do Studio ou com qualquer agente adicionado via Bring Your Own Agent (Claude, Codex…). Vale também instalar a skill oficial Migrate to Compose, que aparece em android skills list.
3. Clique direito no layout XML (por exemplo, res/layout/fragment_profile.xml) e escolha AI › Migrate to Compose. Para migrar o projeto inteiro, abra a action palette e rode a migração por lá.
4. Defina o escopo junto com o agente. Ele pergunta o que migrar agora, o que fica em interoperabilidade e como tratar componentes customizados.
5. Revise o plano. O agente monta um plano por etapas antes de alterar qualquer arquivo.
6. Conversão. O agente converte o layout, o código de view binding e a lógica associada em Compose idiomático.
7. Acompanhe pela timeline. A janela do agente mostra qual etapa está rodando e de onde retomar se ele parar. O progresso fica salvo com a conversa: dá para sair e voltar depois.
8. Valide. Confira os Compose Previews (ou android preview no terminal) e rode o Change Review com /review antes do commit.

Exemplo: o que entra e o que sai

Um exemplo ilustrativo do tipo de conversão — uma tela de perfil com ViewBinding.

Antes (XML + ViewBinding):

<!-- res/layout/fragment_profile.xml -->
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical"
    android:padding="16dp">

    <TextView
        android:id="@+id/name"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textAppearance="?attr/textAppearanceHeadlineSmall" />

    <TextView
        android:id="@+id/role"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:id="@+id/follow"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/follow" />
</LinearLayout>

class ProfileFragment : Fragment(R.layout.fragment_profile) {
    private val viewModel: ProfileViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        val binding = FragmentProfileBinding.bind(view)
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { state ->
                    binding.name.text = state.name
                    binding.role.text = state.role
                    binding.follow.isEnabled = !state.isFollowing
                }
            }
        }
        binding.follow.setOnClickListener { viewModel.follow() }
    }
}

Depois (Compose idiomático, com estado elevado):

@Composable
fun ProfileRoute(viewModel: ProfileViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()
    ProfileScreen(state = state, onFollow = viewModel::follow)
}

@Composable
fun ProfileScreen(state: ProfileUiState, onFollow: () -> Unit, modifier: Modifier = Modifier) {
    Column(modifier.padding(16.dp)) {
        Text(state.name, style = MaterialTheme.typography.headlineSmall)
        Text(state.role)
        Button(onClick = onFollow, enabled = !state.isFollowing) {
            Text(stringResource(R.string.follow))
        }
    }
}

@Preview
@Composable
private fun ProfileScreenPreview() {
    ProfileScreen(ProfileUiState(name = "Ada", role = "Android Engineer"), onFollow = {})
}

Durante a transição, o Fragment pode continuar existindo e só hospedar o Compose:

class ProfileFragment : Fragment() {
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?) =
        ComposeView(requireContext()).apply {
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent { MaterialTheme { ProfileRoute() } }
        }
}

Checklist para revisar o que o agente gerou

• [ ] O estado está elevado (Composable sem estado + Route que coleta o ViewModel)?
• [ ] Textos usam stringResource e não strings fixas?
• [ ] O tema do XML foi mapeado para MaterialTheme (cores, tipografia, shapes)?
• [ ] Acessibilidade preservada: contentDescription, tamanhos de toque, ordem de leitura?
• [ ] Testes de UI migrados para composeTestRule (ou screenshot tests)?
• [ ] Sem recomposições desnecessárias? Use o recomposition tracing do Compose 1.13 e a skill jetpack-compose-performance.
• [ ] XML e classe de binding antigos removidos depois que a tela estabilizou?

Estratégia recomendada: migre tela a tela, começando pelas mais simples ou pelas que você já vai mexer, e use ComposeView como ponte. Migrar o app inteiro de uma vez gera um diff impossível de revisar — mesmo com agente.

---

7. Compose-first: estado fora da UI com Jetpack AppState

Quem já brigou com combine de cinco Flows vai gostar dessa. O Jetpack AppState (alpha) usa o runtime do Compose fora da UI, em ViewModels, repositórios e serviços. São duas peças:

• Transform — roda um bloco @Composable sem UI e devolve um State<R> que recompõe sozinho quando qualquer estado lido muda.
• StateStore — mapa type-safe de estado compartilhado entre activities, services e widgets, com integração opcional ao DataStore.

[versions]
appstate = "1.0.0-alpha01"

[libraries]
androidx-appstate-transform = { module = "androidx.appstate.transform:transform", version.ref = "appstate" }
androidx-appstate-transform-testing = { module = "androidx.appstate.transform:transform-testing", version.ref = "appstate" }
androidx-appstate-statestore = { module = "androidx.appstate.statestore:statestore", version.ref = "appstate" }

Atenção: todo módulo que chama transform precisa de buildFeatures { compose = true } e do plugin do Compose Compiler, mesmo sem UI.

Antes e depois. Um ViewModel que troca de fonte conforme a conectividade:

class HomeViewModel(
    private val mediaRepository: MediaRepository,
    private val networkMonitor: NetworkMonitor,
) : ViewModel() {
    val uiState: State<HomeUiState> = transform<HomeUiState>(
        initialValue = HomeUiState.Loading,
        scope = viewModelScope,
    ) {
        val isOnline by networkMonitor.isOnline
        val tracks = if (isOnline) {
            mediaRepository.allTracksFlow.collectAsState(initial = null).value
        } else {
            mediaRepository.downloadedTracksFlow.collectAsState(initial = null).value
        } ?: return@transform HomeUiState.Loading

        HomeUiState.Success(tracks = tracks, isOnline = isOnline)
    }
}

Sem flatMapLatest, sem stateIn, e o if comum decide qual fonte observar.

Debounce de busca com LaunchedEffect, dentro do transform:

var query: String by mutableStateOf("")

val searchResults: List<String> by transform<List<String>>(
    initialValue = emptyList(),
    scope = coroutineScope,
) {
    var results by remember { mutableStateOf(emptyList<String>()) }
    LaunchedEffect(query) {
        if (query.isBlank()) { results = emptyList(); return@LaunchedEffect }
        delay(300.milliseconds)
        results = api.search(query)
    }
    results
}

Quando NÃO usar transform: ele representa o valor atual, não um fluxo de eventos. Atualizações rápidas antes da recomposição são descartadas e valores iguais em sequência não disparam nada. Para totais acumulados, logs, eventos únicos e backpressure, continue com Flow.

Testes ficam simples com transformTest:

@Test
fun testStateUpdate() = transformTest {
    var sourceState by mutableStateOf(0)
    val state = transform(initialValue = 0, scope = backgroundScope, dispatcher = testDispatcher) {
        sourceState
    }
    sourceState = 1
    advance()
    assertThat(state.value).isEqualTo(1)
}

Completam o pacote Compose 1.13 (stable em breve: Grid e FlexBox stable, Progressive Blur, Formatted Text) e Navigation 3 1.2 (stable: deep links e predictive back mais rico). Exemplos: github.com/android/appstate-recipes.

---

8. A2UI: quando a resposta do agente é uma tela

Chat com muro de texto não é boa UX. Com o A2UI (Agent-to-UI), o agente envia JSON declarativo e o seu app renderiza componentes nativos do seu catálogo — sem executar código arbitrário.

dependencies {
    implementation("androidx.a2ui.compose:compose-runtime:1.0.0-alpha01")
    implementation("androidx.a2ui.compose:compose-ui:1.0.0-alpha01")
    androidTestImplementation("androidx.a2ui.compose:compose-ui-testing:1.0.0-alpha01")
}

ViewModel:

class AgenticUiViewModel : ViewModel() {
    private val parser = A2uiMessageParser()
    private val processor = A2uiMessageProcessor(catalogs = listOf(CustomDesignSystemCatalog))

    val a2uiSurfaces: StateFlow<List<A2uiSurfaceModel>> = processor.activeSurfaces

    init {
        viewModelScope.launch(Dispatchers.Default) { processor.collectMessages() }
        // cliques e erros voltam para o agente
        viewModelScope.launch(start = CoroutineStart.UNDISPATCHED) {
            processor.outboundEvents.collect(::handleOutboundA2uiEvent)
        }
    }

    fun onNetworkMessage(json: String) = processor.processInput(parser, json)
}

Tela:

@Composable
fun AgenticUiScreen(viewModel: AgenticUiViewModel) {
    val surfaces by viewModel.a2uiSurfaces.collectAsStateWithLifecycle()
    Column(Modifier.fillMaxSize()) {
        surfaces.forEach { surface ->
            key(surface.id) { A2uiSurface(surfaceModel = surface) }
        }
    }
}

O que mais gostei: as defesas contra alucinação já vêm prontas. Componente desconhecido vira erro reportado ao agente para ele se corrigir; o payload é validado contra schema; índices de lista absurdos viram mapa esparso para não estourar memória.

---

9. Gemini Nano 4: um agente inteiro no aparelho

O Gemini Nano 4 trouxe function calling nativo, e o ML Kit ganhou uma Agentic API (alpha) que roda o loop agêntico completo no aparelho, sobre o AICore.

Pré-requisitos: Android 14+ no AICore Developer Preview, aparelho suportado, minSdk 26, Kotlin 2.3+.

dependencies {
    implementation("com.google.mlkit:genai-agent:1.0.0-alpha1")
    // opcional: tools via AppFunctions
    implementation("androidx.appfunctions:appfunctions:1.0.0-alpha13")
    ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha13")
}

val agent = Agent.builder()
    .setName("Assistant")
    .setInstructions("You are a helpful on-device assistant.")
    .build()

val runner = AgentRunner(agent)
val session = runner.getOrCreateSession("chat_session")

val prompt = Content.builder().text("Can you help me organize my day?").build()

lifecycleScope.launch {
    session.runAsync(prompt)
        .textTokens()
        .collect { token -> Log.d("Agent", token) }
}

// sem histórico: runner.runSingleTurnAsync(prompt)
// ao destruir: runner.close()

Limites que você precisa saber:

• maxTurns padrão é 10, para evitar loop infinito e poupar bateria.
• Inferência só com o app em primeiro plano; excesso de chamadas devolve ErrorCode.BUSY.
• O modelo pode escolher a tool ou o argumento errado: a segurança das ações é do seu app. Confirme ações sensíveis com o usuário.
• Para bases de conhecimento enormes, o próprio Google recomenda arquitetura híbrida com modelos em nuvem.

---

10. Android MCP e AppFunctions: seu app como tool do Gemini

Esta é, para mim, a mudança mais estratégica do evento. AppFunctions é o equivalente mobile das tools do MCP: seu app vira um servidor MCP on-device e o Gemini (ou outro agente autorizado) descobre e chama funções do app para cumprir o pedido do usuário. Está em beta e roda no Android 16+.

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "TaskAppFunctionService",
    appFunctionXmlFileName = "task_app_function_service",
)
abstract class BaseTaskAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var taskRepository: TaskRepository

    /**
     * Creates a task based on [createTaskParams].
     *
     * @param createTaskParams The parameter to describe how to create the task.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createTask(createTaskParams: CreateTaskParams): Task =
        withContext(Dispatchers.IO) {
            if (createTaskParams.title == null && createTaskParams.content == null) {
                throw AppFunctionInvalidArgumentException("Title or content should be non-null")
            }
            val id = taskRepository.createTask(createTaskParams.title, createTaskParams.content)
            taskRepository.getTask(id)?.toTask()
                ?: throw AppFunctionElementNotFoundException("Task not found for ID = $id")
        }
}

/** The parameter to create the task. */
@AppFunctionSerializable(isDescribedByKDoc = true)
data class CreateTaskParams(
    /** The title of the task. */ val title: String?,
    /** The content of the task. */ val content: String?,
)

Repare em dois detalhes:

1. O KDoc é o prompt. Com isDescribedByKDoc = true, a documentação vira a descrição que o agente lê para decidir quando chamar a função. Escreva pensando no modelo.
2. Exceções tipadas (AppFunctionInvalidArgumentException, AppFunctionElementNotFoundException) dizem ao agente por que falhou, para ele tentar de outro jeito.

Testando sem o Gemini:

adb shell cmd app_function list-app-functions

AppFunctions x servidor MCP remoto: AppFunctions roda local, usa o estado real do app e não exige backend. MCP remoto é agnóstico de plataforma e depende de rede. Os agentes consideram os dois juntos.

Para levar isso a usuários, a Connected Apps Platform (preview) leva os serviços do app ao Gemini e à Busca: você constrói com Android MCP ou MCP remoto, prototipa no Gemini dev mode e registra no Google Connected Console.

⚠️ Realidade em out/2026: a integração com o Gemini ainda está restrita a apps selecionados. Dá para implementar e testar hoje; para produção, há um Early Access Program.

---

11. Um código, muitas telas: Googlebook, foldables e XR

Googlebook é a nova categoria de laptops sobre base Android, com parceiros como HP, Dell, Lenovo, Acer e Asus. O mesmo app roda no celular e no notebook, sem codebase separado.

A Compose adaptive skill foi atualizada para o agente fazer o trabalho pesado: atalhos de teclado, cursores, hover e tooltips; migração para Grid, FlexBox e mediaQuery; estado ponta a ponta; e posturas de foldable, como layout tabletop em telas de mídia e câmera.

📌 Recado do Google Play: em 2027 o Play vai olhar de perto como apps e jogos rodam em foldables. Siga as adaptive quality guidelines.

Android XR e XREAL AURA

O XREAL AURA é o primeiro óculos XR com fio rodando Android XR. Fica abaixo de 95 g porque o processamento vai num "puck" com Snapdragon Reality Elite. Tem tela Sony Micro-OLED 1200p a 120 Hz, roda apps do Google Play e até cinco janelas virtuais. Preço: US$ 1.099 promocional até dezembro (US$ 1.279 depois), à venda nos EUA, Canadá, Japão e Coreia do Sul.

Para devs, o mais importante: o núcleo do Jetpack XR ficou stable (SceneCore, ARCore for Jetpack XR e XR Runtime), assim como os emuladores de óculos XR no Android Studio e o Android XR Engine Hub. O Compose for XR segue em alpha.

O primeiro passo é espacializar uma tela que você já tem:

Subspace {
    SpatialPanel(
        SubspaceModifier
            .height(824.dp)
            .width(1400.dp)
            .resizable()
            .transformingMovable(),
    ) {
        MyExistingScreen() // sua tela Compose atual
    }
}

O conteúdo de Subspace só aparece quando a espacialização está ativa. No celular ele é ignorado, então o mesmo código serve para os dois mundos.

---

12. Indo além do keynote: 5 laboratórios para fazer esta semana

1. Agente com olhos e mãos (stable) — instale o Android CLI e o plugin no Claude Code ou Codex, escreva 3 Journeys dos fluxos críticos e peça: "rode as jornadas, capture o trace de startup e proponha a correção de maior impacto". Meça o cold start antes e depois.
2. Qualidade no CI (stable) — rode android analyze no AAB de release, salve o JSON como artefato e falhe o build se a nota de shrinking cair. Use analyzeReleaseR8Config para atacar as 5 keep rules mais caras.
3. ViewModel sem combine (alpha) — reescreva um ViewModel com 3+ fontes usando transform e teste com transformTest. Compare legibilidade e verifique se algum evento se perdeu.
4. Seu app como tool (beta) — use a skill de AppFunctions para achar as 3 funções de maior valor, implemente uma e valide com adb shell cmd app_function list-app-functions.
5. Resposta como UI (alpha) — monte um catálogo A2UI com 3 componentes do seu design system e alimente com JSON fixo antes de ligar um modelo real. Teste o caminho de erro.

---

O que fica do Dev Summit

O retorno do Android Dev Summit não foi marcado por uma API isolada. Foi marcado por uma mudança no papel de quem desenvolve para Android: orquestrar agentes que constroem, validam e otimizam o app — e projetar o app para ser usado por agentes.

Para quem quer agir agora, minha leitura é esta:

• Já dá para adotar: Rabbit 2 com BYOA, Android CLI com skills, Change Review e o checklist em semáforo no fluxo do time.
• Neste trimestre: migrar as telas XML mais mexidas, mapear quais funções do app viram AppFunctions e preparar a UI adaptativa para foldables e Googlebook.
• Em POC: A2UI, Gemini Nano 4 e AppState, acompanhando a evolução das APIs até o stable.

E você, qual dessas novidades vai testar primeiro? Conta nos comentários. 👇

---

Fontes

• Android Dev Summit 2026 keynote
• Agentic and Flexible: A next era of Android development
• What's new in Android developer tools and performance at Android Dev Summit
• Android skills (catálogo) e play-policy-insights
• Overview of AppFunctions
• Render A2UI surfaces in your app
• Build agentic workflows with Gemini Nano
• Jetpack AppState e Transform
• Develop UI with Jetpack Compose for XR
• TechCrunch — Xreal Aura

Este artigo também está disponível em inglês e espanhol.