DEV Community: Diego Ferreira Caetano

Android Dev Summit 2026: Google vuelve a reunir a los devs después de cuatro años y pone a los agentes en el centro de Android

Diego Ferreira Caetano — Sat, 31 Oct 2026 20:43:47 +0000

Mountain View, 28 de octubre de 2026 — Después de cuatro años sin un evento propio, Google volvió a realizar el Android Dev Summit. La última edición había sido en 2022; desde entonces, las novedades de la plataforma compartían espacio con el resto del Google I/O. Esta vez fueron dos días dedicados solo a Android, en el campus Bay View, con el keynote transmitido en YouTube y una edición extendida en Londres.

El mensaje del keynote fue directo: Android ahora se construye con agentes de IA y para agentes de IA. Android Studio abrió sus puertas a agentes de otras empresas, como Claude y Codex. Android CLI les dio a esos agentes acceso a dispositivos reales. Y las apps ganaron una forma estándar de ofrecer sus funciones a Gemini.

En este briefing reúno lo que se anunció, en qué etapa está cada novedad y — la parte que el keynote recorre rápido — cómo usar cada una en el día a día, con código.

Ficha del evento


Cuándo	28 y 29 de octubre de 2026
Dónde	Campus Bay View de Google, Mountain View (EE. UU.), con edición extendida en Londres
Contexto	Primer Android Dev Summit desde 2022
Tracks	AI experiences, Android XR, Apps foundation, Tools & performance
Keynote	Cerca de una hora, con demos en vivo — míralo en YouTube

Los titulares

Android Studio Rabbit 2 llega a stable y acepta cualquier agente de código compatible con ACP — Claude, Codex, Antigravity y más de 40 otros.
Android CLI suma dispositivos físicos remotos, render de Compose Preview en la terminal, un profiler con LeakCanary y plugins oficiales para Claude Code y Codex.
Checklist de publicación en semáforo: la skill play-policy-insights audita la app antes del envío a Google Play y marca 🟢🟡🔴 lo que falta.
Migración de XML a Compose con un clic derecho, guiada por un agente dentro de Android Studio.
AppFunctions pasa a beta: las funciones de tu app se vuelven tools para Gemini y otros agentes, vía Android MCP.
A2UI (alpha): los agentes ahora pueden responder con pantallas nativas en Compose, hechas con tu design system.
Gemini Nano 4 + ML Kit Agentic API (alpha): un agente completo corriendo en el dispositivo, con llamada de funciones.
Jetpack AppState (alpha) lleva el modelo de estado de Compose a ViewModels y repositorios.
Googlebook, plegables y Android XR: un código para muchas pantallas. XREAL AURA debuta como las primeras gafas XR con cable que corren Android XR.

1. Lo que ya puedes usar (y lo que todavía es laboratorio)

Antes de instalar todo, conviene mirar la madurez de cada anuncio.

Mi regla práctica: stable va a producción, beta entra detrás de un feature flag, alpha y preview se quedan en POC y estudio.

2. Android Studio Rabbit 2: trae tu propio agente

Android Studio dejó de ser "el IDE con Gemini". Con Bring Your Own Agent (BYOA), ahora stable en Rabbit 2, se convierte en el host de cualquier agente compatible con el Agent Client Protocol (ACP).

Cómo activarlo:

Abre Settings > Tools > AI > Agents.
Instala agentes desde el marketplace (Claude Agent, Codex, Antigravity…). Puedes tener varios y alternar.
El agente pasa a ver lo que solo el IDE sabe: estructura del proyecto y del build, resolución de símbolos, render de Compose Preview, el Emulator y Logcat.

Además llegaron tres funciones que cambian el día a día:

Change Review — revisión agéntica de los cambios que hizo el agente. Inícialo desde los cambios pendientes, la ventana de Git o con /review. Genera un reporte de problemas y un recorrido guiado para cambios grandes.
Migration Assistant (Canary) — clic derecho en un layout XML > AI › Migrate to Compose y el agente migra la pantalla a Compose. Más abajo hay una sección completa sobre esto.
Android Bench 2.0 — un leaderboard que evalúa modelos y harnesses en tareas Android largas (migrar UI, construir una app desde mocks), midiendo si realmente funciona, además de costo y tiempo. Ideal para elegir el agente del equipo: developer.android.com/bench.

ACP vs MCP: no los confundas

Es el punto que más confusión genera. Son dos protocolos con funciones distintas:

3. Android CLI: todo el toolchain en manos del agente

Android CLI es la interfaz "tool-first" para cualquier terminal, agente o pipeline de CI. La idea es simple: el agente deja de gastar tokens adivinando cómo funciona Android y usa herramientas oficiales.

# instala el CLI y configura el agente
android init

# un dispositivo físico real, en un device lab de Google (vía Firebase)
android device remote connect
android device hub            # ventana para ver y controlar dispositivos y emuladores

# Compose Previews sin emulador ni IDE
android preview

# rendimiento y memoria
android profiler systemtrace
android profiler heapdump capture
android profiler leakcanary

# calidad del binario y señales de producción
android analyze app-release.aab
android signals

# skills y documentación
android skills list
android skills add jetpack-compose-performance
android docs search "predictive back"

Los números que publicó Google llaman la atención: los agentes que usaron android preview terminaron tareas de UI 77% más rápido con hasta 3x menos tokens.

Plugins oficiales para Claude Code y Codex

# Claude Code (dentro de la sesión)
/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

El plugin le da al agente lo necesario para crear proyectos, gestionar emuladores, inspeccionar layouts en vivo, ejecutar Journeys, instalar skills oficiales y consultar la Android Knowledge Base.

Skills oficiales

Son más de 30 skills en más de 20 áreas, cada una respaldada por evaluaciones. Apuntan a donde los modelos suelen fallar: rendimiento de Compose, APIs nuevas de cámara, auditorías de seguridad. Algunas que vale instalar ya:

jetpack-compose-performance
android-profiler
r8-analyzer
play-policy-insights (audita código, manifest y SDKs contra las políticas de Play antes del envío)
android-intent-security y android-permissions-security

Repositorio: github.com/android/skills.

4. Validación: el agente revisa su propio trabajo

El bloque "Validating apps with Android Prototype" del keynote (12:45) insiste en una idea: un buen agente verifica lo que hizo. La demo más memorable fue con Claude Code:

Google le dio al agente una lista de recorridos críticos y un único prompt — encontrar y corregir memory leaks. Claude ejecutó cada recorrido en un dispositivo distinto, en paralelo, usó android profiler leakcanary, siguió las cadenas de referencias hasta el código, lo corrigió y volvió a ejecutar todo para confirmar.

Lo que sostiene ese flujo:

Journeys — flujos de usuario descritos en lenguaje natural. El equipo los escribe; el agente los ejecuta.
LeakCanary integrado — en el CLI y en el Profiler de Studio, con Fix with AI (Canary).
Android Performance Analyzer (APA) — el motor del Profiler ahora también alimenta el CLI. Con la skill android-profiler, el agente captura un trace, lo analiza, propone una corrección y mide el impacto.
androidx.tracing 2.0 — traces con archivo, línea y argumentos; las coroutines aparecen como flujos conectados. Empieza con androidx.tracing:tracing-wire.
Recomposition tracing (Compose 1.13) — muestra por qué algo se recompuso, hasta la escritura de estado que lo causó.

Del crash en producción a la corrección

android signals trae crashes, ANRs y problemas de memoria a la terminal. Y Crashlytics ahora recolecta heap dumps de OOMs reales y de Memory Limiter Kills de Android 17, desofuscados con el mapping de R8 y abiertos en Perfetto (early access).

R8 sin miedo

# AGP 9.3: puntaje de tu configuración y ranking de las keep rules más costosas
./gradlew :app:analyzeReleaseR8Config

Combínalo con la skill r8-analyzer y reemplaza keep rules genéricas por Jetpack Keep (alpha), anotaciones type-safe que lint puede agregar por ti.

5. Antes del deploy: el checklist en semáforo

Uno de los momentos más prácticos del evento: en lugar de un checklist manual de publicación, le pides al agente que audite la app y te devuelve un reporte en semáforo — 🟢 lo que está bien, 🟡 lo que necesita revisión, 🔴 lo que bloquea el envío.

La skill oficial: `play-policy-insights`

Ese formato viene de la skill oficial play-policy-insights, que audita tu código, manifest y SDKs contra las políticas de Google Play y lo cruza con tu declaración de Data safety.

1. Instala la skill

android skills add play-policy-insights

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

2. Ejecútala con un prompt (este es el que sugiere Google):

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

3. Qué revisa

Data safety — compara lo que tu código recolecta y transmite con lo que declaraste en Play Console.
Credenciales de login de demostración — si los revisores de Play pueden entrar a la app.
Permisos restringidos — permisos sensibles u obsoletos donde se espera una alternativa con alcance limitado.

4. Cómo leer el reporte

Estado general	Significado	Qué hacer
🟢 Compliant	No se encontraron violaciones activas	Seguir con el envío
🟡 Needs Review	Sin violaciones críticas, pero hay declaraciones manuales en Play Console o permisos restringidos para revisar	Revisar antes de enviar
🔴 Non-Compliant	Violaciones o diferencias en Data safety	Corregir antes del envío

Cada hallazgo tiene severidad — 🔴 Critical (violación confirmada), 🟡 Important (por ejemplo, un permiso obsoleto donde se espera uno con alcance), 🔵 Suggestion (recomendación) — e incluye la política, los archivos afectados, la evidencia, un nivel de confianza, una recomendación y enlaces. El reporte termina con diferencias de Data safety, accesos locales a datos y un checklist de remediación.

Dos cuidados:

El reporte es consultivo: no es asesoría legal ni garantía de aprobación.
La skill escribe archivos temporales en .scratch/play_policy_insights_<uuid> en la raíz del proyecto. Agrega .scratch/ al .gitignore.

En Android Studio, Play Policy Insights también aparece como verificaciones de lint directamente en el código.

Más allá: una skill de "release readiness" con todos los gates

La política de Play es solo una de las puertas. Con las herramientas de Android CLI puedes escribir tu propia skill que ejecute todos los gates y devuelva un único semáforo. Este es un ejemplo que escribí para estudio — adapta rutas y umbrales a tu proyecto:

---
name: release-readiness
description: Úsala antes de publicar una release. Ejecuta los gates de build, tamaño, política de Play, seguridad, estabilidad y recorridos críticos y devuelve un reporte en semáforo.
---

# Release readiness

Ejecuta todos los gates de abajo, en orden. No te detengas en la primera falla: el reporte debe mostrar todos.

## Gates

1. **Build** — `./gradlew :app:bundleRelease`. 🔴 si falla.
2. **Tamaño y R8** — ejecuta `android analyze` sobre el AAB de release y `./gradlew :app:analyzeReleaseR8Config`.
   🟡 si el puntaje de shrinking bajó respecto de `docs/release/last-analyze.json`. 🔴 si la ofuscación está desactivada.
3. **Política de Play** — ejecuta la skill `play-policy-insights` y copia su estado general.
4. **Seguridad** — ejecuta las skills `android-permissions-security` y `android-intent-security`. 🔴 ante cualquier hallazgo Critical.
5. **Estabilidad** — `android signals` para la versión actual en producción. 🟡 ante nuevos clusters de crash o ANR.
   🔴 si los usuarios sin crash cayeron por debajo del umbral de `docs/release/thresholds.md`.
6. **Recorridos críticos** — ejecuta las Journeys de `journeys/`. 🔴 si alguna falla.

## Salida

Escribe `release-report.md` con:
- el estado general (el peor gate define el estado);
- una fila por gate: estado, gate, evidencia, próxima acción;
- un checklist de remediación.

No publiques, no subas nada y no crees tags. Publicar es una decisión humana.

En Claude Code, guárdala en .claude/skills/release-readiness/SKILL.md y llámala con /release-readiness. En otros agentes, usa su carpeta de skills equivalente. La regla "el peor gate define el estado" es lo que convierte seis verificaciones en un semáforo único y honesto.

6. Compose-first en la práctica: de XML a Compose con un clic derecho

Otro punto destacado del keynote: migrar una pantalla de XML Views a Jetpack Compose dejó de ser un proyecto manual. El Migration Assistant (Android Studio Canary) aparece en el menú contextual del layout y le delega el trabajo a un agente.

Paso a paso

Instala el Android Studio Canary más reciente — la función está en ese canal.
Elige el agente. Funciona con el agente integrado de Studio o con cualquier agente agregado vía Bring Your Own Agent (Claude, Codex…). También conviene instalar la skill oficial Migrate to Compose, que aparece en android skills list.
Haz clic derecho en el layout XML (por ejemplo, res/layout/fragment_profile.xml) y elige AI › Migrate to Compose. Para migrar todo el proyecto, abre la action palette y ejecuta la migración desde ahí.
Define el alcance con el agente. Te pregunta qué migrar ahora, qué queda en interoperabilidad y cómo tratar las vistas personalizadas.
Revisa el plan. El agente arma un plan por etapas antes de tocar cualquier archivo.
Conversión. El agente convierte el layout, el código de view binding y la lógica asociada en Compose idiomático.
Sigue la timeline. La ventana del agente muestra qué etapa está corriendo y desde dónde retomar si se detiene. El progreso se guarda con la conversación: puedes irte y volver después.
Valida. Revisa los Compose Previews (o android preview en la terminal) y ejecuta Change Review con /review antes del commit.

Ejemplo: lo que entra y lo que sale

Un ejemplo ilustrativo de este tipo de conversión — una pantalla de perfil con 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() }
    }
}

Después (Compose idiomático, con 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 la transición, el Fragment puede seguir existiendo y solo alojar 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 lo que generó el agente

[ ] ¿El estado está elevado (Composable sin estado + un Route que recolecta el ViewModel)?
[ ] ¿Los textos usan stringResource en lugar de strings fijos?
[ ] ¿El tema del XML se mapeó a MaterialTheme (colores, tipografía, formas)?
[ ] ¿Se preservó la accesibilidad: contentDescription, tamaños táctiles, orden de lectura?
[ ] ¿Las pruebas de UI pasaron a composeTestRule (o screenshot tests)?
[ ] ¿Sin recomposiciones innecesarias? Usa el recomposition tracing de Compose 1.13 y la skill jetpack-compose-performance.
[ ] ¿Se eliminaron el XML y la clase de binding antiguos una vez estabilizada la pantalla?

Estrategia recomendada: migra pantalla por pantalla, empezando por las más simples o las que vas a tocar de todos modos, y usa ComposeView como puente. Migrar toda la app de una vez genera un diff imposible de revisar — incluso con un agente.

7. Compose-first: estado fuera de la UI con Jetpack AppState

Si alguna vez peleaste con un combine de cinco Flows, esto te va a gustar. Jetpack AppState (alpha) usa el runtime de Compose fuera de la UI, en ViewModels, repositorios y servicios. Son dos piezas:

Transform — ejecuta un bloque @Composable sin UI y devuelve un State<R> que se recompone solo cuando cambia cualquier estado leído.
StateStore — un mapa type-safe de estado compartido entre activities, services y widgets, con persistencia opcional en 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" }

Ojo: todo módulo que llama a transform necesita buildFeatures { compose = true } y el plugin del Compose Compiler, aunque no tenga UI.

Un ViewModel que cambia de fuente según la conectividad:

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)
    }
}

Sin flatMapLatest, sin stateIn: un if común decide qué fuente observar.

Debounce de búsqueda con LaunchedEffect, dentro de 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
}

Cuándo NO usar transform: representa el valor actual, no un flujo de eventos. Las actualizaciones rápidas antes de la recomposición se descartan y los valores iguales consecutivos no disparan nada. Para totales acumulados, logs, eventos únicos y backpressure, sigue con Flow.

Las pruebas son simples con 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)
}

Completan el paquete Compose 1.13 (stable pronto: Grid y FlexBox stable, Progressive Blur, Formatted Text) y Navigation 3 1.2 (stable: deep links y predictive back más rico). Ejemplos: github.com/android/appstate-recipes.

8. A2UI: cuando la respuesta del agente es una pantalla

Un muro de texto en un chat no es buena UX. Con A2UI (Agent-to-UI), el agente envía JSON declarativo y tu app renderiza componentes nativos de tu propio catálogo — sin ejecutar código arbitrario.

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() }
        // clics y errores vuelven al agente
        viewModelScope.launch(start = CoroutineStart.UNDISPATCHED) {
            processor.outboundEvents.collect(::handleOutboundA2uiEvent)
        }
    }

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

Pantalla:

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

Lo que más me gustó: las defensas contra alucinaciones vienen incluidas. Un componente desconocido se convierte en un error reportado al agente para que se corrija; el payload se valida contra un schema; los índices de lista absurdos pasan a un mapa disperso para no agotar la memoria.

9. Gemini Nano 4: un agente completo en el dispositivo

Gemini Nano 4 trajo function calling nativo, y ML Kit sumó una Agentic API (alpha) que ejecuta el bucle agéntico completo en el dispositivo, sobre AICore.

Requisitos: Android 14+ inscrito en el AICore Developer Preview, un dispositivo compatible, minSdk 26, Kotlin 2.3+.

dependencies {
    implementation("com.google.mlkit:genai-agent:1.0.0-alpha1")
    // opcional: tools vía 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) }
}

// sin historial: runner.runSingleTurnAsync(prompt)
// al destruir: runner.close()

Límites que debes conocer:

maxTurns es 10 por defecto, para evitar bucles infinitos y ahorrar batería.
La inferencia solo corre con la app en primer plano; demasiadas llamadas devuelven ErrorCode.BUSY.
El modelo puede elegir la tool o el argumento equivocado: la seguridad de las acciones es responsabilidad de tu app. Confirma con el usuario las acciones sensibles.
Para bases de conocimiento enormes, el propio Google recomienda una arquitectura híbrida con modelos en la nube.

10. Android MCP y AppFunctions: tu app como tool de Gemini

Para mí, este es el cambio más estratégico del evento. AppFunctions es el equivalente móvil de las tools de MCP: tu app se convierte en un servidor MCP on-device, y Gemini (u otro agente autorizado) descubre y llama a funciones de tu app para cumplir lo que pide el usuario. Está en beta y funciona en 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?,
)

Fíjate en dos detalles:

El KDoc es el prompt. Con isDescribedByKDoc = true, la documentación se convierte en la descripción que lee el agente para decidir cuándo llamar a la función. Escríbela pensando en el modelo.
Las excepciones tipadas (AppFunctionInvalidArgumentException, AppFunctionElementNotFoundException) le dicen al agente por qué falló, para que intente de otra manera.

Probando sin Gemini:

adb shell cmd app_function list-app-functions

AppFunctions vs servidor MCP remoto: AppFunctions corre localmente, usa el estado real de la app y no necesita backend. Un MCP remoto es agnóstico de plataforma y depende de la red. Los agentes consideran ambos juntos.

Para llegar a los usuarios, la Connected Apps Platform (preview) lleva los servicios de tu app a Gemini y a la Búsqueda: construyes con Android MCP o MCP remoto, prototipas en el Gemini dev mode y te registras en Google Connected Console.

⚠️ Realidad a oct/2026: la integración con Gemini todavía está limitada a apps seleccionadas. Puedes implementarla y probarla hoy; para producción hay un Early Access Program.

11. Un código, muchas pantallas: Googlebook, plegables y XR

Googlebook es la nueva categoría de laptops sobre una base Android, con socios como HP, Dell, Lenovo, Acer y Asus. La misma app corre en el teléfono y en la laptop, sin un código separado.

La Compose adaptive skill se actualizó para que el agente haga el trabajo pesado: atajos de teclado, cursores, hover y tooltips; migración a Grid, FlexBox y mediaQuery; manejo de estado de punta a punta; y posturas de plegables, como layouts tabletop para pantallas de multimedia y cámara.

📌 Aviso de Google Play: en 2027 Play revisará de cerca cómo corren las apps y los juegos en plegables. Sigue las adaptive app quality guidelines.

Android XR y XREAL AURA

XREAL AURA son las primeras gafas XR con cable que corren Android XR. Pesan menos de 95 g porque el procesamiento va en un "puck" con Snapdragon Reality Elite. Tienen pantalla Sony Micro-OLED 1200p a 120 Hz, ejecutan apps de Google Play y hasta cinco ventanas virtuales. Precio: US$ 1.099 de lanzamiento hasta diciembre (US$ 1.279 después), a la venta en Estados Unidos, Canadá, Japón y Corea del Sur.

Para los devs, lo más importante: el núcleo de Jetpack XR ya es stable (SceneCore, ARCore for Jetpack XR y XR Runtime), igual que los emuladores de gafas XR en Android Studio y el Android XR Engine Hub. Compose for XR sigue en alpha.

El primer paso es espacializar una pantalla que ya tienes:

Subspace {
    SpatialPanel(
        SubspaceModifier
            .height(824.dp)
            .width(1400.dp)
            .resizable()
            .transformingMovable(),
    ) {
        MyExistingScreen() // tu pantalla Compose actual
    }
}

El contenido dentro de Subspace solo se muestra cuando la espacialización está activa. En el teléfono se ignora, así que el mismo código sirve para ambos mundos.

12. Más allá del keynote: 5 laboratorios para esta semana

Un agente con ojos y manos (stable) — instala Android CLI y el plugin en Claude Code o Codex, escribe 3 Journeys de tus flujos críticos y pide: "ejecuta los recorridos, captura un trace de inicio y propón la corrección de mayor impacto". Mide el cold start antes y después.
Calidad en CI (stable) — ejecuta android analyze sobre el AAB de release, guarda el JSON como artefacto y haz fallar el build si baja el puntaje de shrinking. Usa analyzeReleaseR8Config para atacar las 5 keep rules más costosas.
Un ViewModel sin combine (alpha) — reescribe un ViewModel con 3+ fuentes usando transform y pruébalo con transformTest. Compara la legibilidad y verifica si se perdió algún evento.
Tu app como tool (beta) — usa la skill de AppFunctions para encontrar las 3 funciones de mayor valor, implementa una y valídala con adb shell cmd app_function list-app-functions.
Una respuesta como UI (alpha) — arma un catálogo A2UI con 3 componentes de tu design system y aliméntalo con JSON fijo antes de conectar un modelo real. Prueba el camino de error.

Lo que deja el Dev Summit

El regreso del Android Dev Summit no estuvo marcado por una API aislada. Estuvo marcado por un cambio en el rol de quien desarrolla para Android: orquestar agentes que construyen, validan y optimizan la app — y diseñar la app para que la usen agentes.

Si quieres actuar ya, esta es mi lectura:

Para adoptar hoy: Rabbit 2 con BYOA, Android CLI con skills, Change Review y el checklist en semáforo en el flujo del equipo.
Este trimestre: migrar las pantallas XML que más se tocan, definir qué funciones de la app serán AppFunctions y preparar la UI adaptativa para plegables y Googlebook.
En POC: A2UI, Gemini Nano 4 y AppState, siguiendo las APIs en su camino a stable.

¿Cuál de estas novedades vas a probar primero? Cuéntame en los comentarios. 👇

Fuentes

Este artículo también está disponible en portugués e inglés.

Android Dev Summit 2026: Google brings developers back together after four years and puts agents at the center of Android

Diego Ferreira Caetano — Sat, 31 Oct 2026 20:43:04 +0000

Mountain View, October 28, 2026 — After four years without a dedicated event, Google brought back the Android Dev Summit. The last edition was in 2022; since then, platform news had to share the stage with the rest of Google I/O. This time it was two days devoted entirely to Android, at the Bay View campus, with the keynote streamed on YouTube and an extended edition in London.

The keynote's message was blunt: Android is now built with AI agents and for AI agents. Android Studio opened its doors to agents from other companies, such as Claude and Codex. Android CLI gave those agents access to real devices. And apps gained a standard way to offer their functions to Gemini.

In this briefing I gather what was announced, how mature each piece is and — the part the keynote moves through quickly — how to use each one day to day, with code.

Event fact sheet


When	October 28–29, 2026
Where	Google's Bay View campus, Mountain View (US), plus an extended edition in London
Context	First Android Dev Summit since 2022
Tracks	AI experiences, Android XR, Apps foundation, Tools & performance
Keynote	About one hour, with live demos — watch on YouTube

The headlines

Android Studio Rabbit 2 reaches stable and accepts any ACP-compatible coding agent — Claude, Codex, Antigravity and 40+ others.
Android CLI gains remote physical devices, Compose Preview rendering in the terminal, a LeakCanary-powered profiler and official plugins for Claude Code and Codex.
A traffic-light release checklist: the play-policy-insights skill audits your app before you submit to Google Play and flags 🟢🟡🔴 what's missing.
XML-to-Compose migration with a right-click, driven by an agent inside Android Studio.
AppFunctions goes beta: functions in your app become tools for Gemini and other agents, through Android MCP.
A2UI (alpha): agents can now answer with native Compose screens built from your design system.
Gemini Nano 4 + ML Kit Agentic API (alpha): a whole agent running on the device, with function calling.
Jetpack AppState (alpha) brings Compose's state model to ViewModels and repositories.
Googlebook, foldables and Android XR: one codebase for many screens. XREAL AURA debuts as the first wired XR glasses running Android XR.

1. What you can ship today (and what is still a lab)

Before installing everything, check how mature each announcement is.

My rule of thumb: stable goes to production, beta goes behind a feature flag, alpha and preview stay in POCs and study projects.

2. Android Studio Rabbit 2: bring your own agent

Android Studio is no longer "the IDE with Gemini". With Bring Your Own Agent (BYOA), now stable in Rabbit 2, it hosts any agent that speaks the Agent Client Protocol (ACP).

How to turn it on:

Open Settings > Tools > AI > Agents.
Install agents from the marketplace (Claude Agent, Codex, Antigravity…). You can keep several and switch.
The agent now sees what only the IDE knows: project and build structure, symbol resolution, Compose Preview rendering, the Emulator and Logcat.

Three more features change the daily workflow:

Change Review — agentic review of the changes your agent made. Start it from pending agent changes, the Git window, or with /review. You get an issues report and a guided walkthrough for large changes.
Migration Assistant (Canary) — right-click an XML layout > AI › Migrate to Compose and the agent migrates the screen to Compose. There's a full section on it further down.
Android Bench 2.0 — a leaderboard that scores models and agent harnesses on long Android tasks (migrating UI, building an app from mocks), measuring whether the result actually works, plus cost and time. Great for picking your team's agent: developer.android.com/bench.

ACP vs MCP: don't mix them up

This is the point I see causing the most confusion. Two protocols, two jobs:

3. Android CLI: the whole toolchain in your agent's hands

Android CLI is the tool-first interface for any terminal, agent or CI pipeline. The idea is simple: your agent stops burning tokens guessing how Android works and uses official tools instead.

# install the CLI and set up your agent
android init

# a real physical device from a Google device lab (via Firebase)
android device remote connect
android device hub            # window to view and control devices and emulators

# Compose Previews with no emulator and no IDE
android preview

# performance and memory
android profiler systemtrace
android profiler heapdump capture
android profiler leakcanary

# binary quality and production signals
android analyze app-release.aab
android signals

# skills and docs
android skills list
android skills add jetpack-compose-performance
android docs search "predictive back"

Google's numbers stand out: agents using android preview finished UI tasks 77% faster with up to 3x fewer tokens.

Official plugins for Claude Code and Codex

# Claude Code (inside a session)
/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

The plugin gives your agent what it needs to create projects, manage emulators, inspect live layouts, run Journeys, install official skills and search the Android Knowledge Base.

Official skills

There are 30+ skills across 20+ areas, each backed by evaluations. They target the areas where models tend to fall short: Compose performance, new camera APIs, security audits. A few worth installing now:

jetpack-compose-performance
android-profiler
r8-analyzer
play-policy-insights (audits code, manifest and SDKs against Play policies before you submit)
android-intent-security and android-permissions-security

Repo: github.com/android/skills.

4. Validation: the agent checks its own work

The "Validating apps with Android Prototype" segment of the keynote (12:45) drives home one idea: a good agent verifies what it did. The most memorable demo used Claude Code:

Google gave the agent a list of critical user journeys and a single prompt — find and fix memory leaks. Claude ran each journey on a separate device in parallel, used android profiler leakcanary, followed each reference chain back to the code, fixed it and re-ran everything to confirm.

What powers this workflow:

Journeys — user flows written in natural language. Your team writes them; the agent runs them.
Built-in LeakCanary — in the CLI and in the Studio Profiler, with Fix with AI (Canary).
Android Performance Analyzer (APA) — the Profiler's engine now powers the CLI too. With the android-profiler skill, the agent captures a trace, analyzes it, proposes a fix and measures the impact.
androidx.tracing 2.0 — trace sections with file, line and arguments; coroutines show up as connected flows. Start with androidx.tracing:tracing-wire.
Recomposition tracing (Compose 1.13) — shows why something recomposed, back to the state write that caused it.

From a production crash to a fix

android signals brings crashes, ANRs and memory issues to the terminal. Crashlytics now collects heap dumps from real OOMs and Android 17 Memory Limiter Kills, deobfuscated with your R8 mapping and opened in Perfetto (early access).

R8 without fear

# AGP 9.3: a score for your config and a ranking of the costliest keep rules
./gradlew :app:analyzeReleaseR8Config

Pair it with the r8-analyzer skill and replace broad keep rules with Jetpack Keep (alpha), type-safe annotations that lint can add for you.

5. Before you ship: the traffic-light checklist

One of the most practical moments of the event: instead of a manual release checklist, you ask the agent to audit the app and it returns a traffic-light report — 🟢 what's fine, 🟡 what needs a review, 🔴 what blocks submission.

The official skill: `play-policy-insights`

This format comes from the official play-policy-insights skill, which audits your code, manifest and SDKs against Google Play policies and cross-checks your Data safety declaration.

1. Install the skill

android skills add play-policy-insights

# alternative, outside Android CLI:
npx skills add https://github.com/android/skills --skill play-policy-insights

2. Run it with a prompt (this is the one Google suggests):

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

3. What it checks

Data safety — compares what your code collects and transmits with what you declared in the Play Console.
Demo login credentials — whether Play reviewers can actually get into the app.
Restricted permissions — sensitive or deprecated permissions where a scoped alternative is expected.

4. How to read the report

Overall status	Meaning	What to do
🟢 Compliant	No active violations found	Go ahead and submit
🟡 Needs Review	No critical violations, but manual Play Console declarations or restricted permissions need attention	Review before submitting
🔴 Non-Compliant	Violations or Data safety mismatches	Fix before submitting

Each finding has a severity — 🔴 Critical (verified violation), 🟡 Important (for example, a deprecated permission where a scoped one is expected), 🔵 Suggestion (advisory) — and lists the policy, affected files, evidence, a confidence level, a recommendation and reference links. The report ends with Data safety discrepancies, local data access and a remediation checklist.

Two caveats:

The report is advisory: it is not legal advice or a guarantee of approval.
The skill writes scratch files to .scratch/play_policy_insights_<uuid> at the project root. Add .scratch/ to your .gitignore.

In Android Studio, Play Policy Insights also shows up as lint checks right in your code.

Going further: a "release readiness" skill with every gate

Play policy is only one gate. With Android CLI's tools you can write your own skill that runs every gate and returns a single traffic light. Here's an example I wrote for study — adapt paths and thresholds to your project:

---
name: release-readiness
description: Use before publishing a release. Runs build, size, Play policy, security, stability and critical-journey gates and returns a traffic-light report.
---

# Release readiness

Run every gate below, in order. Do not stop at the first failure: the report must show all gates.

## Gates

1. **Build** — `./gradlew :app:bundleRelease`. 🔴 if it fails.
2. **Size and R8** — run `android analyze` on the release AAB and `./gradlew :app:analyzeReleaseR8Config`.
   🟡 if the shrinking score dropped vs. `docs/release/last-analyze.json`. 🔴 if obfuscation is off.
3. **Play policy** — run the `play-policy-insights` skill and copy its overall status.
4. **Security** — run the `android-permissions-security` and `android-intent-security` skills. 🔴 for any Critical finding.
5. **Stability** — `android signals` for the current production version. 🟡 for new crash or ANR clusters.
   🔴 if crash-free users fell below the threshold in `docs/release/thresholds.md`.
6. **Critical journeys** — run the Journeys in `journeys/`. 🔴 if any fails.

## Output

Write `release-report.md` with:
- the overall status (the worst gate wins);
- one row per gate: status, gate, evidence, next action;
- a remediation checklist.

Do not publish, upload or tag anything. Shipping is a human decision.

In Claude Code, save it as .claude/skills/release-readiness/SKILL.md and call it with /release-readiness. In other agents, use their equivalent skills folder. The "worst gate wins" rule is what turns six checks into one honest traffic light.

6. Compose-first in practice: from XML to Compose with a right-click

Another keynote highlight: migrating a screen from XML Views to Jetpack Compose is no longer a manual project. The Migration Assistant (Android Studio Canary) shows up in the layout's context menu and hands the work to an agent.

Step by step

Install the latest Android Studio Canary — the feature lives in that channel.
Pick your agent. It works with Studio's built-in agent or with any agent added through Bring Your Own Agent (Claude, Codex…). It's also worth installing the official Migrate to Compose skill, listed in android skills list.
Right-click the XML layout (for example, res/layout/fragment_profile.xml) and choose AI › Migrate to Compose. To migrate the whole project, open the action palette and run the migration from there.
Scope it with the agent. It asks what to migrate now, what stays in interop, and how to handle custom views.
Review the plan. The agent drafts a step-by-step plan before touching any file.
Conversion. The agent converts the layout, the view-binding code and the related logic into idiomatic Compose.
Follow the timeline. The agent window shows which step is running and where to resume if it stops. Progress is saved with the conversation, so you can step away and come back.
Validate. Check the Compose Previews (or android preview in the terminal) and run Change Review with /review before committing.

Example: what goes in and what comes out

An illustrative example of this kind of conversion — a profile screen using ViewBinding.

Before (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() }
    }
}

After (idiomatic Compose, with hoisted state):

@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 = {})
}

During the transition, the Fragment can stay and simply host Compose:

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

Checklist to review what the agent produced

[ ] Is state hoisted (stateless Composable + a Route that collects the ViewModel)?
[ ] Do texts use stringResource instead of hardcoded strings?
[ ] Was the XML theme mapped to MaterialTheme (colors, typography, shapes)?
[ ] Is accessibility preserved: contentDescription, touch target sizes, reading order?
[ ] Were UI tests moved to composeTestRule (or screenshot tests)?
[ ] No needless recompositions? Use Compose 1.13's recomposition tracing and the jetpack-compose-performance skill.
[ ] Were the old XML and binding class removed once the screen settled?

Recommended strategy: migrate screen by screen, starting with the simplest ones or the ones you're about to touch anyway, and use ComposeView as the bridge. Migrating the whole app at once produces a diff nobody can review — even with an agent.

7. Compose-first: state beyond the UI with Jetpack AppState

If you have ever fought a five-Flow combine, you will like this one. Jetpack AppState (alpha) runs the Compose runtime outside the UI, in ViewModels, repositories and services. Two pieces:

Transform — runs a @Composable block with no UI and returns a State<R> that recomposes whenever any state it reads changes.
StateStore — a type-safe map of state shared across activities, services and widgets, with optional DataStore persistence.

[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" }

Note: any module that calls transform needs buildFeatures { compose = true } and the Compose Compiler plugin, even without UI.

A ViewModel that switches sources based on connectivity:

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)
    }
}

No flatMapLatest, no stateIn — a plain if decides which source to observe.

Search debounce with LaunchedEffect, inside 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
}

When NOT to use transform: it represents the current value, not a stream of events. Rapid updates before recomposition are dropped, and equal consecutive values trigger nothing. For running totals, logs, one-time events and backpressure, stick with Flow.

Testing is simple with 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)
}

Rounding it out: Compose 1.13 (stable soon: Grid and FlexBox stable, Progressive Blur, Formatted Text) and Navigation 3 1.2 (stable: deep links and richer predictive back). Examples: github.com/android/appstate-recipes.

8. A2UI: when the agent's answer is a screen

A wall of chat text is poor UX. With A2UI (Agent-to-UI), the agent sends declarative JSON and your app renders native components from your own catalog — no arbitrary code is executed.

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() }
        // clicks and errors flow back to the agent
        viewModelScope.launch(start = CoroutineStart.UNDISPATCHED) {
            processor.outboundEvents.collect(::handleOutboundA2uiEvent)
        }
    }

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

Screen:

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

My favorite part: hallucination defenses come built in. An unknown component becomes an error reported back to the agent so it can self-correct; payloads are validated against a schema; absurd list indexes switch to a sparse map so they can't blow up memory.

9. Gemini Nano 4: a whole agent on the device

Gemini Nano 4 brings native function calling, and ML Kit gained an Agentic API (alpha) that runs the complete agent loop on the device, on top of AICore.

Requirements: Android 14+ enrolled in the AICore Developer Preview, a supported device, minSdk 26, Kotlin 2.3+.

dependencies {
    implementation("com.google.mlkit:genai-agent:1.0.0-alpha1")
    // optional: 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) }
}

// no history: runner.runSingleTurnAsync(prompt)
// on destroy: runner.close()

Limits you need to know:

maxTurns defaults to 10, to prevent runaway loops and save battery.
Inference only runs while your app is in the foreground; too many calls return ErrorCode.BUSY.
The model can pick the wrong tool or argument: the safety of actions is your app's job. Confirm sensitive actions with the user.
For huge knowledge bases, Google itself recommends a hybrid architecture with cloud models.

10. Android MCP and AppFunctions: your app as a Gemini tool

To me, this is the most strategic change of the event. AppFunctions is the mobile equivalent of MCP tools: your app becomes an on-device MCP server, and Gemini (or any authorized agent) discovers and calls your app's functions to fulfill a user's request. It is in beta and runs on 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?,
)

Two details worth noticing:

The KDoc is the prompt. With isDescribedByKDoc = true, your docs become the description the agent reads to decide when to call the function. Write them for the model.
Typed exceptions (AppFunctionInvalidArgumentException, AppFunctionElementNotFoundException) tell the agent why a call failed, so it can try another way.

Testing without Gemini:

adb shell cmd app_function list-app-functions

AppFunctions vs a remote MCP server: AppFunctions runs locally, uses the app's real state and needs no backend. A remote MCP server is platform-agnostic and depends on the network. Agents consider both together.

To reach users, the Connected Apps Platform (preview) brings your app's services to Gemini and Search: build with Android MCP or remote MCP, prototype in Gemini dev mode, and register through the Google Connected Console.

⚠️ Reality check (Oct 2026): the Gemini integration is still limited to selected apps. You can implement and test today; for production there is an Early Access Program.

11. One codebase, many screens: Googlebook, foldables and XR

Googlebook is the new category of laptops built on an Android foundation, with partners such as HP, Dell, Lenovo, Acer and Asus. The same app runs on the phone and the laptop, with no separate codebase.

The Compose adaptive skill was updated so your agent can do the heavy lifting: keyboard shortcuts, pointer cursors, hover states and tooltips; migration to Grid, FlexBox and mediaQuery; end-to-end state handling; and foldable postures, such as tabletop layouts for media and camera screens.

📌 Heads-up from Google Play: in 2027 Play will look closely at how apps and games run on foldables. Follow the adaptive app quality guidelines.

Android XR and XREAL AURA

XREAL AURA is the first wired XR glasses running Android XR. It stays under 95 g because the compute lives in a puck powered by Snapdragon Reality Elite. It has a Sony Micro-OLED 1200p display at 120 Hz, runs Google Play apps and up to five virtual windows. Price: US$1,099 launch price through December (US$1,279 after), available in the US, Canada, Japan and South Korea.

For developers, the key news: the Jetpack XR core is now stable (SceneCore, ARCore for Jetpack XR and XR Runtime), and so are the XR glasses emulators in Android Studio and the Android XR Engine Hub. Compose for XR is still alpha.

The first step is spatializing a screen you already have:

Subspace {
    SpatialPanel(
        SubspaceModifier
            .height(824.dp)
            .width(1400.dp)
            .resizable()
            .transformingMovable(),
    ) {
        MyExistingScreen() // your current Compose screen
    }
}

Content inside Subspace only renders when spatialization is on. On a phone it is ignored, so the same code serves both worlds.

12. Beyond the keynote: 5 labs to try this week

An agent with eyes and hands (stable) — install Android CLI and the plugin in Claude Code or Codex, write 3 Journeys for your critical flows, and ask: "run the journeys, capture a startup trace and propose the highest-impact fix". Measure cold start before and after.
Quality gates in CI (stable) — run android analyze on your release AAB, store the JSON as a pipeline artifact and fail the build if the shrinking score drops. Use analyzeReleaseR8Config to go after the 5 costliest keep rules.
A ViewModel without combine (alpha) — rewrite a ViewModel with 3+ sources using transform and test it with transformTest. Compare readability and check whether any event got lost.
Your app as a tool (beta) — use the AppFunctions skill to find your 3 highest-value functions, implement one and validate it with adb shell cmd app_function list-app-functions.
An answer as UI (alpha) — build an A2UI catalog with 3 components from your design system and feed it fixed JSON before wiring a real model. Test the error path.

What the Dev Summit leaves behind

The return of the Android Dev Summit was not defined by a single API. It was defined by a shift in the Android developer's role: orchestrating agents that build, validate and optimize the app — and designing the app to be used by agents.

If you want to act now, here is my read:

Adopt today: Rabbit 2 with BYOA, Android CLI with skills, Change Review and the traffic-light checklist in your team's workflow.
This quarter: migrate the XML screens you touch most, map which app functions become AppFunctions, and get the UI adaptive for foldables and Googlebook.
As POCs: A2UI, Gemini Nano 4 and AppState, following the APIs on their way to stable.

Which of these will you try first? Tell me in the comments. 👇

Sources

This article is also available in Portuguese and Spanish.

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

Diego Ferreira Caetano — Sat, 31 Oct 2026 20:43:00 +0000

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:

Abra Settings > Tools > AI > Agents.
Instale agentes pelo marketplace (Claude Agent, Codex, Antigravity…). Dá para ter vários e alternar.
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

Instale o Android Studio Canary mais recente — a feature está nesse canal.
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.
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á.
Defina o escopo junto com o agente. Ele pergunta o que migrar agora, o que fica em interoperabilidade e como tratar componentes customizados.
Revise o plano. O agente monta um plano por etapas antes de alterar qualquer arquivo.
Conversão. O agente converte o layout, o código de view binding e a lógica associada em Compose idiomático.
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.
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:

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.
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

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.
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.
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.
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.
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

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

AI in Practice: RAG, MCP and Multi-Agent Systems in Kotlin, Without Magic Frameworks

Diego Ferreira Caetano — Sun, 18 Oct 2026 16:43:50 +0000

AI in Practice: Demystifying RAG, MCP and Multi-Agent Systems in Kotlin, Without "Magic" Frameworks

❗ Opening provocation: The market was flooded with buzzwords: RAG, MCP, multi-agent architecture, ReAct, guardrails. Every day a new framework promises autonomous agents in two lines of code. But what happens when you put that "demo agent" in front of a real customer support desk? It hallucinates, ignores business rules and leaks data. Enough vibes-based engineering!

This article walks through a real project, DSupport, built by hand in Kotlin Multiplatform with no agent framework. Every concept comes with the real code from the repository and an explanation of how it works, line by line.

📦 Full code: github.com/diegoferreiracaetano/dsupport-kt. Every stage is a git tag (etapa-1 to etapa-12), so you can see the exact code at that point.

How to read the code snippets: the numbers ①②③ in the comments show up again in the explanation right below, under 🔍 Reading the code.

1️⃣ The Big Illusion of "Everything Is an LLM": Deterministic vs. Non-Deterministic

There is an illusion that the language model should make 100% of a software's decisions. But an LLM is a probabilistic engine: the same input can produce different outputs. Asking it, through a prompt, to never show sensitive data is Russian roulette.

+-----------------------------------------------------------------------+
|                        HYBRID SYSTEM (DSupport)                        |
+------------------------------------+----------------------------------+
|  Model (non-deterministic)         |  Code (deterministic)            |
+------------------------------------+----------------------------------+
|  - understand natural language     |  - validate types and rules      |
|  - decide which tool to call       |  - hide sensitive data           |
|  - draft the reply                 |  - block what must not pass      |
|  - route between specialists       |  - tests that run offline        |
+------------------------------------+----------------------------------+

⚠️ Why does relying on the prompt alone fail in production? A prompt is a suggestion, not a guarantee. A prompt injection or a plain stochastic variation breaks the rule. Whatever matters to the business must be enforced in code.

The contrast: three ways to build it

Approach	What it delivers	Where it breaks
100% deterministic (`if/else`, state machines)	Predictable, fast, zero cost	It does not understand paraphrase; the rule list grows forever
100% model ("magic" framework)	Flexible, looks smart	Unpredictable answers, endless loops, runaway cost
Hybrid (DSupport)	The model understands and chooses; the code validates and blocks	Costs more than an `if`: it needs evals and tracing

In practice: where the deterministic version fails

This is the first thing anyone would try, and it is a great idea for predictable questions:

// A deterministic router (illustration, not in the repository)
fun route(message: String): Intent = when {
    "refund" in message.lowercase()                     -> Intent.POLICY   // ①
    Regex("""order\s*#?\d+""").containsMatchIn(message) -> Intent.ORDER    // ②
    else                                                -> Intent.OTHER    // ③
}

🔍 Reading the code

① It looks for the exact word "refund". "I want my money back" does not contain it.
② It requires the pattern "order 1042". "Where is the thing I bought Monday?" does not match.
③ Anything not predicted lands here, silently.

"my package never showed up"           -> OTHER   (wrong)
"where is the thing I bought Monday?"  -> OTHER   (wrong)
"I want my money back"                 -> OTHER   (wrong)

💡 The deterministic version fails on language, not on logic. The agent fails on trust. The right question is not "AI or code?" but "what does each one do best?". In DSupport, 5 roles use a model and 14 pieces are plain code (guardrails, validator, TF-IDF search, tools, MCP transport, tracing, eval scoring and more).

2️⃣ The DSupport Architecture: Clean Separation of Responsibilities

For testability and vendor independence (no vendor lock-in), DSupport uses Clean Architecture and Ports & Adapters in Kotlin Multiplatform. The golden rule: dependencies point inward.

🧱 How the modules are separated

contract: the shared types (SupportAnswer, AgentEvent). No external dependencies.
core: the heart. Agent loop, orchestration, guardrails, review and the ports (interfaces). It does not know what HTTP, Anthropic or JSON is.
adapters: implement the ports. Anthropic client, RAG engine, JSON files, MCP client. Swapping Claude for another model means writing a new adapter, without touching core.
mcp-orders and mcp-tickets: independent servers that speak the MCP protocol.
cli, server, app: entry points (terminal, Ktor API with SSE, Compose app on desktop and iPhone).
eval: the evaluation suite with a golden dataset.

A real port: what `core` knows about the model

interface LlmClient {
    suspend fun next(request: LlmRequest): LlmReply                                      // ①
    suspend fun structured(request: LlmRequest, schema: OutputSchema): StructuredReply   // ②
}

🔍 Reading the code

① next returns text or a tool request (LlmReply.Text or LlmReply.ToolCalls). It is the basis of the agent loop.
② structured forces the model to fill in a JSON form (we will see it in section 3).
There is no provider import here. AnthropicLlmClient, in the adapters module, implements this interface and translates everything to the Anthropic JSON, with 2 retries on 429 and 5xx errors.

ℹ️ Why does this matter? The project's 380+ tests run offline, with test doubles in place of the model. No test spends a cent on the API.

3️⃣ The Concepts Mapped in Practice (From Theory to Code)

🔹 Agent loop: the model decides, the code acts (`etapa-1`)

In one sentence: a for loop with a limit. The model asks for a tool, the code runs it, the result goes back, and the cycle repeats until there is an answer.

private suspend fun loop(): String {
    repeat(maxTurns) {                                                              // ①
        val reply = llm.next(LlmRequest(system, history.toList(), specs))           // ②
        when (reply) {
            is LlmReply.Text -> return finalAnswer(reply.text)                      // ③
            is LlmReply.ToolCalls -> {
                history += Message.AssistantToolCalls(reply.calls)
                val results = coroutineScope {
                    reply.calls.map { call -> async { execute(call.tool, call.args) } }.awaitAll()   // ④
                }
                reply.calls.zip(results).forEach { (call, result) ->
                    history += Message.ToolResult(call.id, call.tool, result.content, result.isError) // ⑤
                }
            }
        }
    }
    return "Turn limit of $maxTurns reached. Escalating to a human agent."          // ⑥
}

🔍 Reading the code

① repeat(maxTurns): the loop always has a limit. Without it, a confused model calls tools forever.
② On every turn the whole history is sent again, together with the list of available tools.
③ If the model answered with text, it is over. Before returning, the answer goes through the guardrails (finalAnswer).
④ If it asked for tools, they run in parallel (async + awaitAll). Two independent lookups take as long as the slower one.
⑤ Results enter the history in the same order as the requests, because the model API requires that match.
⑥ Limit reached? The code returns an escalation message. The model does not decide that.

🛑 The model never executes anything. It only asks. Your code executes, validates and decides what comes back.

🔹 Tools (function calling): giving the model hands (`etapa-3`)

A tool is a function with a name, a description and an input schema (JSON Schema). The model only sees that; the code does the work.

interface Tool {
    val spec: ToolSpec                                   // ① name, description, schema
    suspend fun run(args: JsonObject): ToolResult        // ② executes
}

override suspend fun run(args: JsonObject): ToolResult {
    val orderId = args.stringArg("order_id") ?: return fail("missing_argument:order_id")     // ①
    val email = args.stringArg("email") ?: return fail("missing_argument:email")
    val order = orders.findOwned(orderId, email)                                            // ②
        ?: return fail("order_not_found_or_email_mismatch")
    val late = order.status == OrderStatus.IN_TRANSIT && order.eta < today()                // ③
    return ok("status" to JsonPrimitive(order.status.wire), "late" to JsonPrimitive(late))  // ④
}

🔍 Reading the code (GetOrderStatusTool, shortened)

① Missing argument? It returns a readable error result, not an exception. The model reads missing_argument:email and asks the customer for the email.
② findOwned only returns the order if the number and the email match. This is the first lock against data leaks.
③ The delay is computed in code, from the estimated date. The model does not "guess" that it is late: it reads late: true.
④ The return is short JSON, already in the right shape, without dumping the whole database into the context.

💡 The tool description is part of the prompt. A vague description makes the model pick the wrong tool. Write it as if it were instructions for an intern.

🔹 RAG (Retrieval-Augmented Generation): answering with a consultation (`etapa-4`)

Instead of letting the model invent the return policy, RAG searches the help center and forces it to answer only from what was found.

class SearchKbTool(
    private val kb: KnowledgeSearch,
    private val minScore: Double = 0.25,                                  // ①
) : Tool {
    override suspend fun run(args: JsonObject): ToolResult {
        val query = args.stringArg("query") ?: return fail("missing_argument:query")
        val relevant = kb.search(query).filter { it.score >= minScore }   // ②
        if (relevant.isEmpty()) return fail("nothing_relevant_found")     // ③
        val results = relevant.map {
            buildJsonObject { put("doc_id", it.docId); put("title", it.title); put("snippet", it.snippet); put("score", it.score) }  // ④
        }
        return ok("results" to JsonArray(results))
    }
}

🔍 Reading the code

① The relevance cut-off is the most important piece. Without it, the search always returns something.
② Only what is similar enough to the question gets through.
③ Nothing relevant? An honest answer: "nothing found". The knowledge specialist is instructed to reply NO_ANSWER in that case, instead of inventing.
④ Every result carries the article title. That is how the final answer can cite the source, and the validator (below) checks that the cited source really came from the search.

Articles are split by section (MarkdownChunker) and turned into vectors with TF-IDF, a simple word weighting. There is an optional VoyageEmbedder for semantic search. Notice: the search itself is deterministic code, and it works without an API key.

⚠️ RAG without a relevance cut-off is the number one cause of "confident answers based on a passage that has nothing to do with the question".

🔹 MCP (Model Context Protocol): tools in separate processes (`etapa-5`)

MCP is an open standard: tools live in other programs and speak JSON-RPC. In this project, over stdio with the official Kotlin SDK: the client starts the server as a child process. A session has 3 messages: initialize, tools/list, tools/call.

{
  "servers": [
    { "name": "orders",  "command": ["mcp-orders/build/install/mcp-orders/bin/mcp-orders"],   "env": { "DATA_DIR": "data" } },
    { "name": "tickets", "command": ["mcp-tickets/build/install/mcp-tickets/bin/mcp-tickets"], "env": { "DATA_DIR": "data" } }
  ]
}

On the server side, any list of Tool becomes an MCP server:

server.addTool(
    name = spec.name,
    description = spec.description,
    inputSchema = ToolSchema(properties = spec.inputSchema["properties"] as? JsonObject, required = ...),   // ①
    toolAnnotations = ToolAnnotations(readOnlyHint = spec.readOnly, destructiveHint = spec.destructive),    // ②
) { request ->
    val result = tool.run(request.arguments ?: JsonObject(emptyMap()))                                       // ③
    CallToolResult(content = listOf(TextContent(result.content)), isError = result.isError)                  // ④
}

🔍 Reading the code (server)

① The same ToolSpec of the local tools is converted to the protocol schema.
② The readOnly and destructive flags travel along: a client can use them to ask for confirmation.
③ The tool is the same class as before. Nothing was rewritten to become remote.
④ The result goes back as text, with the error flag.

On the client side, a remote failure must never freeze the agent:

override suspend fun run(args: JsonObject): ToolResult = try {
    withTimeout(timeoutMs) { connection.callTool(spec.name, args) }     // ①
} catch (e: CancellationException) {
    if (e is TimeoutCancellationException) ToolResult("error: ${spec.name} timed out", isError = true) else throw e   // ②
} catch (e: Exception) {
    ToolResult("error: ${e.message}", isError = true)                    // ③
}

🔍 Reading the code (client)

① Every remote call has a timeout. A slow server does not freeze the loop.
② A timeout becomes an error result. A real cancellation (CancellationException) is rethrown, so coroutines do not break.
③ A dead server or an exception also becomes an error the model can read and work around.

💡 MCP benefit: adding the tickets server is one line in config/mcp-servers.json. The agent code does not change: it does not know whether a tool is local or remote.

🛑 On an MCP server over stdio, stdout is the protocol. A stray println corrupts the conversation. That is why the server redirects System.out to System.err.

🔹 Multi-agent orchestration: one orchestrator, three specialists (`etapa-6`)

Instead of one giant "super prompt", an orchestrator with a senior-support-specialist profile delegates to agents with a short prompt and only the tools they need.

Who may use what is configuration, not code:

{
  "agents": {
    "knowledge":  { "tools": ["search_kb"] },
    "orders":     { "tools": ["get_order_status", "track_shipment"] },
    "escalation": { "tools": ["create_ticket"] }
  }
}

And each specialist is exposed to the orchestrator as if it were a tool:

class SubAgentTool(
    private val name: String,
    description: String,
    private val newAgent: () -> Agent,                           // ①
) : Tool {
    override val spec = ToolSpec(name, description, stringSchema("task"))

    override suspend fun run(args: JsonObject): ToolResult {
        val task = args.stringArg("task") ?: return fail("missing_argument:task")
        return try {
            ToolResult(newAgent().run(task))                     // ②
        } catch (e: CancellationException) {
            throw e
        } catch (e: Exception) {
            ToolResult("error: specialist '$name' failed: ${e.message}", isError = true)   // ③
        }
    }
}

🔍 Reading the code

① It receives an agent factory, not an agent. Every call creates a new agent, because an agent keeps its history and two parallel calls must not share it.
② Running the specialist is just calling run(task). To the orchestrator, this is a tool like any other.
③ If the specialist fails, the orchestrator receives an error and moves on.

The orchestrator has no data tools. Its profile, in the prompt, starts like this:

You are a senior customer support specialist and the coordinator of a small team. [...]
You never look up data yourself: you decide who handles each part and always delegate to a specialist.
[...]
- Never promise anything the specialists did not confirm: no dates, refunds or outcomes of your own.

⚠️ If you also give the data tools to the orchestrator, it skips delegation and the design collapses. That is why DSupportAssembly fails to assemble the system if the orchestrator has tools.

🔹 Guardrails: rules the model can neither see nor skip (`etapa-7`)

Guardrails are deterministic code that runs at 3 fixed points of the loop. Every guardrail implements this interface:

interface Hook {
    val covers: Set<String> get() = emptySet()                                                              // ①
    suspend fun beforeTool(agent: String, tool: ToolSpec, args: JsonObject): Decision = Decision.Allow      // ②
    suspend fun afterTool(agent: String, tool: ToolSpec, args: JsonObject, result: ToolResult): ToolResult = result   // ③
    suspend fun beforeFinal(agent: String, history: List<Message>, text: String): String = text            // ④
}

🔍 Reading the code

① Which tools the guardrail protects.
② Before the tool: it can allow, deny or modify the arguments.
③ After the tool: it can rewrite the result (for example, hide personal data).
④ Before the final answer: it can rewrite it.

A concrete example: IdentityGate only lets an order lookup through with a valid number and email.

override suspend fun beforeTool(agent: String, tool: ToolSpec, args: JsonObject): Decision = when {
    tool.name !in covers -> Decision.Allow                                                                   // ①
    args.stringArg("order_id")?.let { digits.matches(it) } != true ->
        Decision.Deny("order_id is missing or invalid. Ask the customer for the order number.")              // ②
    args.stringArg("email")?.let { Patterns.email.matches(it) } != true ->
        Decision.Deny("email is missing or invalid. Ask the customer for the email used in the purchase.")
    else -> Decision.Allow                                                                                   // ③
}

🔍 Reading the code

① Other tools pass straight through.
② The denial carries an instruction for the model ("ask the customer for the number"). The model reads the reason and acts, instead of retrying blindly.
③ Only what passed both checks reaches the tool. The model cannot get around it: the guardrail runs in code, not in the prompt.

And the case that proves a prompt is not enough: two parallel create_ticket calls.

override suspend fun beforeTool(agent: String, tool: ToolSpec, args: JsonObject): Decision {
    val email = customerOf(tool, args) ?: return Decision.Allow
    return lock.withLock {                                                                         // ①
        if (email in inFlight) {
            return@withLock Decision.Deny("A ticket for this customer is already being created. Do not open another.")  // ②
        }
        val existing = tickets.findOpenByEmail(email)
        if (existing != null) {
            return@withLock Decision.Deny("Ticket ${existing.ticketId} is already open for this customer. [...]")        // ③
        }
        inFlight += email                                                                          // ④
        Decision.Allow
    }
}

🔍 Reading the code (TicketDedup)

① A Mutex guarantees only one call at a time enters this check.
② A creation is already in progress for this customer? Deny.
③ A ticket is already open? Deny and give the number, so the model can tell the customer.
④ Before allowing, it reserves the customer. That is what stops two simultaneous calls from both passing.

🛑 "Please never create duplicate tickets" in the prompt is a wish. The Mutex is a guarantee.

How guardrails plug into the loop (a snippet of Agent.guarded):

for (hook in hooks) {
    when (val decision = hook.beforeTool(name, tool.spec, args)) {
        Decision.Allow -> Unit
        is Decision.Deny -> return ToolResult("blocked by ${hook.name}: ${decision.reason}", isError = true)   // ①
        is Decision.Modify -> args = decision.args                                                             // ②
    }
}

① Denied: the tool does not even run, and the model receives the reason.
② Modified: the tool runs with the corrected arguments.

🔹 Structured output and validation in code (`etapa-8.1`)

The final answer is not a paragraph: it is a JSON form.

data class SupportAnswer(
    val answer: String = "",
    val intent: String = "other",
    val sources: List<String> = emptyList(),
    val confidence: Double = 0.0,
    val escalated: Boolean = false,
    @SerialName("ticket_id") val ticketId: String? = null,
)

But a schema only guarantees the shape, not the truth. Code checks the truth:

fun problems(answer: SupportAnswer, evidence: List<String>): List<String> = buildList {
    val results = evidence.joinToString("\n")                                                      // ①
    if (answer.intent !in INTENTS) add("invalid intent: ${answer.intent}")                         // ②
    if (answer.confidence !in 0.0..1.0) add("confidence out of range 0..1: ${answer.confidence}")  // ③
    answer.ticketId?.let { ticket ->
        if (ticket !in results) add("ticket $ticket does not appear in the tool results (invented?)")   // ④
        if (ticket !in answer.answer) add("ticket $ticket is missing from the customer-facing text")
    }
    answer.sources.filter { !results.contains(it, ignoreCase = true) }
        .forEach { add("source \"$it\" does not appear in the tool results") }                     // ⑤
}

🔍 Reading the code

① evidence is everything the tools returned in that conversation: the source of truth.
② The intent must be in the closed list (policy, order, return, complaint, other).
③ The JSON schema cannot express a range, so the confidence range is checked here.
④ An invented ticket is rejected: the number must have appeared in the tool output, and must also be in the text the customer will read.
⑤ An invented source is rejected: you may only cite what the search really returned.

Every problem found is a sentence in English, written for the model to read and fix.

🔹 Producer–reviewer loop, with a limit (`etapa-8.2`)

A second model reviews the draft. But the reviewer is a model too, so the code checks first:

suspend fun answer(question: String): SupportAnswer {
    producer.run(question)
    for (round in 0..maxRevisions) {                                                                  // ①
        val draft = decode(producer.finish(SupportAnswerSchema.output))                               // ②
        val problems = validator.problems(draft, producer.evidence).ifEmpty { review(question, draft) }  // ③
        events.emit(AgentEvent.ReviewRound(round + 1, problems.isEmpty(), problems))                  // ④
        if (problems.isEmpty()) return draft                                                          // ⑤
        producer.followUp("A reviewer rejected your answer. Fix these points and answer the customer again:\n" +
            problems.joinToString("\n") { "- $it" })                                                  // ⑥
    }
    return escalate(question, intent)                                                                 // ⑦
}

🔍 Reading the code

① At most maxRevisions (2) fixes. This limit is what stops the endless loop.
② The producer hands in the draft in the structured format.
③ Code first (cheap and exact). Only if it passes, the reviewer model judges the claims.
④ Every round becomes an event, and shows up in the trace.
⑤ Approved: return it.
⑥ Rejected: the problems go back to the producer, with instructions to fix.
⑦ Limit reached? The code opens the ticket for a human. The model does not decide to escalate.

🔹 Observability: an airplane black box (`etapa-9.1`)

With agents running in parallel, "it went wrong" is not enough. Every event carries a runId and a parentRunId, and the tree rebuilds itself. The trick: the parent travels in the coroutine context, with no parameter passed at all.

class RunContext(val runId: String, val parentRunId: String?) : AbstractCoroutineContextElement(Key) {   // ①
    companion object Key : CoroutineContext.Key<RunContext>
}

suspend fun run(task: String): String {
    parentRunId = coroutineContext[RunContext]?.runId        // ②
    runId = runIds.next()                                    // ③
    return inRun { events.emit(AgentEvent.AgentStarted(name, depth, task, runId, parentRunId)); loop() }   // ④
}

🔍 Reading the code

① RunContext is a coroutine-context element that stores "who am I and who called me".
② A sub-agent is born inside the parent's tool call, so it finds the parent's RunContext and reads its id.
③ Every run gets a unique id (r1, r2...), safe for concurrent calls.
④ inRun installs the new context for everything this agent does next.

The result, generated only from the list of events:

[orchestrator] r1
  model call: 900 in / 80 out tokens, 700 ms
  tool orders: 1300 ms
    [orders] r2
      model call: 400 in / 40 out tokens, 500 ms

🔹 Server and app: the same stream of events, now on a screen (`etapa-11` and `etapa-12`)

call.respondTextWriter(ContentType.Text.EventStream) {
    answerCustomer(question)
        .catch { failure -> write(ServerSentEvents.errorFrame(failure.message ?: "")); flush() }   // ①
        .collect { event ->
            write(ServerSentEvents.frame(event))                                                    // ②
            flush()                                                                                 // ③
        }
}

🔍 Reading the code

① A failure midway becomes an event: error frame, instead of a connection that dies silently.
② Every AgentEvent becomes one SSE frame (data: {...}).
③ The flush is what makes the app show the live trace: without it, everything would arrive at once at the end.

The API key stays only on the server. The app (Compose, desktop and iPhone) reads the same stream and draws the conversation, the sources, the escalation badge and the trace.

4️⃣ Anatomy of a Real Run: The Producer–Reviewer Loop and Guardrails

The customer writes: "My order 1042 has not arrived. My email is ana@example.com".

🔬 The real terminal trace

$ REFERENCE_DATE=2026-10-15 ./gradlew :cli:run --args="My order 1042 has not arrived. My email is ana@example.com"

[orchestrator] calls orders {"task":"Check the status, tracking and delivery progress..."}
[orders] calls get_order_status {"order_id":"1042","email":"ana@example.com"}
[orders] calls track_shipment   {"order_id":"1042","email":"ana@example.com"}     <- in parallel
[orders] get_order_status finished in 12 ms: {"ok":true,"status":"in_transit","late":true,"days_late":10}
[orchestrator] calls escalation {"task":"Delayed order. Order number: 1042 ..."}
[escalation] create_ticket finished in 17 ms: {"ok":true,"ticket_id":"TCK-1001"}
review round 1: rejected (4 problems)
review round 2: approved

What each line shows

The two lookups of the orders specialist leave together, because the loop runs tools in parallel.
late: true, days_late: 10 was computed by the code, not guessed by the model.
The delay triggered the escalation specialist, which opened ticket TCK-1001.
The reviewer rejected the first draft and approved the second. That is the producer–reviewer loop at work.

ℹ️ Efficiency and cost: this run involved 12 model calls, about 15 thousand input tokens and 2 thousand output tokens, costing about US$ 0.0025 (a quarter of a cent) with claude-haiku-5-5.

5️⃣ Continuous Evaluation (Evals): How to Prove Your Agent Works

If you do not measure the agent, you only have opinions. The eval module has a golden dataset of 15 cases run 3 times each, because the model is not deterministic: with the same code, 3 cases changed outcome between two single runs.

Each case is just data:

{
  "id": "g01",
  "question": "How many days do I have to return an item?",
  "expected_intents": ["return", "policy"],
  "should_escalate": false,
  "must_contain": ["30 days"],
  "expected_sources": ["Returns Policy"]
}

🔍 Reading the case

expected_intents: did the orchestrator route correctly?
should_escalate: did it hand over to a human (or not) at the right time?
must_contain: is the vital fact (30 days) in the answer?
expected_sources: did the answer cite the right source?
There is also must_not_contain, to check for leaks.

📊 Real evolution and metrics of the project

Metric	Before	After	What it means in practice
Routing accuracy	100%	100%	The orchestrator sends the question to the right specialist
Groundedness	100%	100%	No answer invents facts outside the sources
No leaks	100%	100%	Customer data does not show up where it should not
Expected facts	93%	100%	The vital information was delivered
Cited sources	86%	100%	You can see where the answer came from
Escalation precision	80%	100%	Hands over to a human at the right time (recall: 100%)
Fallback after failed review	9%	0%	Answers refined without hitting the limit

🔎 What the evals discovered (and code review never would)

Two of my own rules contradicted each other. confidence treated "asking the customer for a detail" as uncertainty, and a validator rejected low confidence.
The reviewer invented objections. It rejected "please send your email" because it did not know the assistant can ask for that.
A deterministic routing error. "Where do I find my tracking code?" always went to orders, instead of the help center.
A test case that was just my assumption. The case demanded an escalation that the assistant, correctly, avoided.

Total cost: about 30 cents of a dollar, one afternoon.

🧪 Tests and Containerization

One test class per production class, with test doubles at the ports. Zero API calls.

@Test
fun `given a malformed email when checking an order tool then should deny`() = runTest {
    val decision = gate.beforeTool("orders", spec("get_order_status"),
        argsOf("order_id" to "1042", "email" to "not-an-email"))     // ①

    assertIs<Decision.Deny>(decision)                                // ②
}

① The test name reads like a sentence: given / when / then. It documents the rule.
② No model, no network: the guardrail is plain code, so the test runs in milliseconds.

A multi-stage Dockerfile for the server (build with the JDK, run with the JRE):

# ① build stage, with the full JDK
FROM eclipse-temurin:21-jdk AS build
WORKDIR /src
COPY . .
RUN ./gradlew :server:installDist --no-daemon

# ② final image, much smaller, JRE only
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/server/build/install/server/ ./
COPY config ./config
COPY data ./data
ENV DATA_DIR=data
EXPOSE 8080
# ③ starts the server
CMD ["bin/server"]

① The full JDK exists only to compile.
② The final image carries only the JRE and the build output.
③ The API key comes in through an environment variable (-e ANTHROPIC_API_KEY), never inside the image.

./gradlew test    # 380+ tests, offline, without spending 1 cent on the API

🏁 Provocative Conclusion: The Future of AI in Engineered Software

Software engineering did not change just because we now use AI. Agents without strong typing, clean architecture, guardrails in code and automated evaluation are unpredictable toys.

🛑 The price of "multi": one delayed-order question cost 12 model calls and about 10 seconds. Multi-agent is not free. Use one agent with tools when the task is small, and split into specialists only when prompts and toolsets grow and the roles are clearly different.

The real innovation is not the newest framework on Twitter. It is knowing where to use the model's non-determinism (understanding language, writing the reply) and where to use the determinism of code (validating, blocking, measuring).

💬 Your turn

Which rule in your project could be code instead of a prompt? Tell me in the comments.
Do you disagree that most of an agent should be deterministic? I want to hear the counter-example.
Share this with someone about to build "an AI agent". A star on the repository helps: github.com/diegoferreiracaetano/dsupport-kt

📖 Leia em português: docs/article/artigo-multiagentes-kotlin.md

DEV Community: Diego Ferreira Caetano

Android Dev Summit 2026: Google vuelve a reunir a los devs después de cuatro años y pone a los agentes en el centro de Android

Ficha del evento

Los titulares

1. Lo que ya puedes usar (y lo que todavía es laboratorio)

2. Android Studio Rabbit 2: trae tu propio agente

ACP vs MCP: no los confundas

3. Android CLI: todo el toolchain en manos del agente

Plugins oficiales para Claude Code y Codex

Skills oficiales

4. Validación: el agente revisa su propio trabajo

Del crash en producción a la corrección

R8 sin miedo

5. Antes del deploy: el checklist en semáforo

La skill oficial: play-policy-insights

Más allá: una skill de "release readiness" con todos los gates

6. Compose-first en la práctica: de XML a Compose con un clic derecho

Paso a paso

Ejemplo: lo que entra y lo que sale

Checklist para revisar lo que generó el agente

7. Compose-first: estado fuera de la UI con Jetpack AppState

8. A2UI: cuando la respuesta del agente es una pantalla

9. Gemini Nano 4: un agente completo en el dispositivo

10. Android MCP y AppFunctions: tu app como tool de Gemini

11. Un código, muchas pantallas: Googlebook, plegables y XR

Android XR y XREAL AURA

12. Más allá del keynote: 5 laboratorios para esta semana

Lo que deja el Dev Summit

Fuentes

Android Dev Summit 2026: Google brings developers back together after four years and puts agents at the center of Android

Event fact sheet

The headlines

1. What you can ship today (and what is still a lab)

2. Android Studio Rabbit 2: bring your own agent

ACP vs MCP: don't mix them up

3. Android CLI: the whole toolchain in your agent's hands

Official plugins for Claude Code and Codex

Official skills

4. Validation: the agent checks its own work

From a production crash to a fix

R8 without fear

5. Before you ship: the traffic-light checklist

The official skill: play-policy-insights

Going further: a "release readiness" skill with every gate

6. Compose-first in practice: from XML to Compose with a right-click

Step by step

Example: what goes in and what comes out

Checklist to review what the agent produced

7. Compose-first: state beyond the UI with Jetpack AppState

8. A2UI: when the agent's answer is a screen

9. Gemini Nano 4: a whole agent on the device

10. Android MCP and AppFunctions: your app as a Gemini tool

11. One codebase, many screens: Googlebook, foldables and XR

Android XR and XREAL AURA

12. Beyond the keynote: 5 labs to try this week

What the Dev Summit leaves behind

Sources

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

Ficha do evento

As manchetes

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

2. Android Studio Rabbit 2: traga o seu agente

ACP x MCP: não confunda

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

Plugins oficiais para Claude Code e Codex

Skills oficiais

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

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

R8 sem medo

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

A skill oficial: play-policy-insights

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

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

Passo a passo

Exemplo: o que entra e o que sai

Checklist para revisar o que o agente gerou

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

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

9. Gemini Nano 4: um agente inteiro no aparelho

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

La skill oficial: `play-policy-insights`

The official skill: `play-policy-insights`

A skill oficial: `play-policy-insights`

A real port: what `core` knows about the model

🔹 Agent loop: the model decides, the code acts (`etapa-1`)

🔹 Tools (function calling): giving the model hands (`etapa-3`)

🔹 RAG (Retrieval-Augmented Generation): answering with a consultation (`etapa-4`)

🔹 MCP (Model Context Protocol): tools in separate processes (`etapa-5`)

🔹 Multi-agent orchestration: one orchestrator, three specialists (`etapa-6`)

🔹 Guardrails: rules the model can neither see nor skip (`etapa-7`)

🔹 Structured output and validation in code (`etapa-8.1`)

🔹 Producer–reviewer loop, with a limit (`etapa-8.2`)

🔹 Observability: an airplane black box (`etapa-9.1`)

🔹 Server and app: the same stream of events, now on a screen (`etapa-11` and `etapa-12`)