El nuevo ejemplo Jetpacker de Google muestra cómo un agente en la nube puede enviar pantallas interactivas a una aplicación Android en lugar de limitarse a responder con texto. La guía, publicada el 28 de septiembre de 2026, utiliza AG-UI para los eventos en tiempo real y A2UI para las descripciones que Jetpack Compose representa como componentes nativos. Las bibliotecas A2UI de AndroidX llegaron a la versión 1.0.0-alpha01 el 23 de septiembre; el artículo posterior enseña a combinarlas. Para quien desarrolla una app, la novedad útil es una forma reutilizable de mostrar las etapas cambiantes de un agente sin programar una pantalla nueva para cada paso. Es un ejemplo en fase alfa, no una prueba de que las reservas autónomas estén listas para producción.
El servidor describe la pantalla; la app decide qué puede mostrar
En la guía de Android Developers, un coordinador del Agent Development Kit (ADK) alojado en la nube distribuye tareas de vuelos, hoteles y otros elementos del itinerario. AG-UI transporta eventos de progreso e interacción entre servidor y teléfono. A2UI lleva descripciones declarativas de controles, como selectores de opciones y tarjetas de estado de reserva. El renderizador de Compose convierte esos mensajes en interfaz nativa a partir de un catálogo registrado por la app. El servidor puede cambiar el orden y el contenido de los componentes admitidos; no puede crear un componente nativo arbitrario en un móvil que no lo incluya.
Esa frontera es el valor práctico del modelo de catálogos de A2UI. La aplicación define qué componentes y propiedades admite, y la biblioteca analiza y valida los mensajes del protocolo en vez de ejecutar código arbitrario enviado por el agente. El ejemplo del blog usa un esquema A2UI v0.9, mientras que los paquetes de AndroidX llevan la etiqueta de versión 1.0.0-alpha01: son números que describen elementos diferentes. Google también advierte de que modificar las propiedades de un componente personalizado exige actualizar de forma coordinada el catálogo y el código Kotlin. El diseño dinámico puede ahorrar algunas actualizaciones de la app, pero no elimina el trabajo de compatibilidad.
Este patrón dentro de la propia aplicación es distinto de Android AppFunctions, que expone funciones de una app a agentes del sistema. Aquí la aplicación Android es la interfaz de su propio flujo en la nube. Usar uno de los mecanismos no significa que todos los asistentes o dispositivos Android admitan el otro.
El ejemplo deja tareas de producción pendientes
El código de reservas ilustra una confirmación antes de ejecutar la herramienta que reserva, pero la búsqueda de vuelos de muestra devuelve horarios fijos y la función de reserva es una simulación. Utiliza InMemoryRunner de ADK. La guía de ADK sobre sesiones aclara que el estado en memoria se pierde cuando se reinicia el proceso; una reserva de larga duración necesita un servicio de sesiones persistente si debe sobrevivir a un fallo del servidor. La afirmación de Google de que el flujo en la nube puede continuar cuando se cierra la aplicación móvil no garantiza que este ejemplo sobreviva a un reinicio del servidor.
Antes de aplicar esta arquitectura a compras u otras acciones importantes, un equipo debería definir autenticación, permisos por herramienta, confirmación expresa, estado duradero, transacciones idempotentes y recuperación tras una desconexión. Son implicaciones técnicas del diseño mostrado, no funciones demostradas por el ejemplo. También conviene probar mensajes A2UI malformados o antiguos frente al catálogo del cliente: la descripción de interfaz enviada por el agente cruza un límite de confianza aunque no sea código ejecutable.
Por dónde empezar
Este patrón encaja con tareas de varios pasos que deben mostrar opciones cambiantes en una pantalla Android nativa, como un itinerario que pueda continuar después de dejar la app en segundo plano. Un formulario local sencillo o una respuesta de modelo de un solo paso quizá no justifiquen un coordinador en la nube y dos protocolos de interfaz. El ejemplo Jetpacker permite evaluar el renderizado de componentes y el flujo de confirmación; después hay que elegir un almacén persistente de sesiones y delimitar las acciones autorizadas al agente antes de tratar el prototipo como servicio. Las publicaciones de septiembre aportan piezas, pero la fiabilidad y el control dependen de la aplicación que las rodea.
Fuentes
Artículos Relacionados
Google recurre las órdenes de la UE sobre IA en Android y datos de Search
Dos medidas de julio llegan a los tribunales. Los recursos no suspenden automáticamente las exigencias sobre Android y datos anonimizados de búsqueda.
Clio compra Learned Hand y entra en el trabajo judicial con IA
La compra aporta a Clio una herramienta para jueces y funcionarios. Los tribunales aún necesitan pruebas sobre datos, revisión humana y resultados.
Google Play prueba suscripciones por plazas y consumo, con acceso aún limitado
Las plazas de equipo, el crédito por uso y la compra combinada pueden cambiar los planes de una app. Antes conviene verificar el acceso y los derechos.
Android Studio Rabbit 2 integra agentes de programación, aún en Canary
Rabbit 2 Canary 2 conecta Codex, Claude Agent y otros agentes ACP con herramientas de Android Studio. Qué pueden probar los desarrolladores.