11 flujos de trabajo con Gemini en Android Studio: tests, previews, Agent Mode y crashes

A un desarrollador Android rara vez le hace falta otra lista de prompts ingeniosos para la IA. Lo que ayuda es cambiar menos de contexto, tener ciclos de feedback más rápidos y perder menos tiempo en tareas mecánicas. Ahí es donde Gemini en Android Studio se gana su sitio.

No lo trates como un compañero al que le dejas una feature mientras te vas. Piensa en él como un compañero rápido de pair programming dentro del IDE. Se le da bien explorar código desconocido, hacer el primer borrador del trabajo repetitivo, leer errores ruidosos y encadenar varios pasos pequeños en un único diff que puedes revisar.

La diferencia está en la precisión. Una petición como "construye esta feature" es demasiado vaga para actuar, mientras que pedirle a Gemini que siga un flujo de estado, proponga el arreglo más pequeño, ejecute los tests relevantes y te muestre el diff describe trabajo de ingeniería real.

A septiembre de 2026, Gemini en Android Studio trabaja sobre varios archivos en Agent Mode, mantiene conversaciones en paralelo, genera tests unitarios y previews de Compose, ayuda con errores de build y de Logcat, inspecciona crashes de App Quality Insights, actualiza dependencias e incluso puede desplegar en un dispositivo conectado e interactuar con él. Son capacidades documentadas del producto, no demos especulativas, y aparecen en la descripción general de funciones de Gemini. La cuestión práctica es cómo usarlas sin generar más trabajo de revisión del que ahorran.

Estos son los flujos que siguen compensando en el trabajo diario con Android.

1. Dale a Gemini un mapa del proyecto una sola vez

El prompt más rentable muchas veces no es un prompt. Es un archivo AGENTS.md breve, commiteado junto al código.

Gemini lee los archivos AGENTS.md del directorio de trabajo y de todos los directorios padre. Así puedes poner las reglas generales en la raíz del repositorio y añadir indicaciones más concretas dentro de módulos sueltos. Como el archivo vive junto al código, todo el equipo recibe las mismas instrucciones a través del control de versiones. La documentación de agent files tiene los detalles.

# Android project guidance
- Kotlin only.
- Follow the existing Clean Architecture boundaries.
- Keep business logic out of Composables and Activities.
- Expose immutable UI state from ViewModels.
- Collect Flow with lifecycle awareness.
- Prefer the libraries already used in the target module.
- Make the smallest safe diff; do not reformat unrelated files.
- Add or update tests for changed behavior.
- Before finishing, run the narrowest relevant Gradle test task.

En una app multimódulo, añade archivos locales allí donde las reglas cambien:

AGENTS.md
player/AGENTS.md
androidtv/AGENTS.md
billing/AGENTS.md

Aquí importa ser breve. Vale la pena incluir decisiones de arquitectura, dónde empieza cada módulo, qué librerías de test prefieres y las zonas que nadie debería tocar. Un manifiesto de 200 líneas solo acaba siendo contexto desactualizado.

Comprueba un detalle de versiones. Google documenta el soporte de AGENTS.md a partir de Android Studio Narwhal 4 Feature Drop Canary 4, mientras que Narwhal 3 Feature Drop esperaba un AGENT.md en singular. Mira la versión de tu IDE antes de dar por hecho que el archivo tiene efecto.

2. Usa un brief de tarea de cuatro líneas

Un prompt más largo no es mejor por sí mismo. Un formato corto y fiable tiene cuatro partes:

Goal: Add retry support to PlaybackRepository.
Context: Inspect PlaybackRepository, its interface, and existing tests.
Constraints: Preserve public APIs; use the existing coroutine/test stack; minimal diff.
Verification: Add failure-then-success tests and run the relevant module test task.

Funciona porque despeja cuatro ambigüedades habituales: qué hay que cambiar, dónde mirar, qué debe mantenerse estable y qué significa "terminado".

Para trabajo arriesgado, añade una línea más:

Before editing, explain the likely root cause and propose a plan.

Para tareas rutinarias, sáltate la ceremonia y pide el diff directamente. El tamaño del prompt debe ir acorde con el riesgo.

3. Mantén el contexto acotado y los hilos separados

Amontonar contexto puede empeorar la respuesta si la mayor parte no tiene que ver con la pregunta. Cuando baste para razonar sobre el cambio, adjunta el ViewModel, el modelo de estado, el contrato del repositorio y los tests cercanos, y deja fuera el resto de la aplicación. Android Studio permite adjuntar archivos del proyecto directamente a una consulta.

Usa hilos distintos para tareas distintas, por ejemplo:

• un bug de reproducción
• una migración de dependencias
• generación de tests
• trabajo de UI en Compose

Gemini recuerda el historial de la conversación. Google señala que los hilos separados pueden mejorar la calidad de las respuestas al limitar el contexto al tema actual, y que borrar el historial obsoleto ayuda cuando un chat se ha desviado. Consulta Chat with Gemini. Una regla sencilla: si tu siguiente prompt necesita la frase "ignora todo lo anterior", abre un hilo nuevo.

4. Deja que Next Edit Prediction haga la edición tediosa que viene después

El autocompletado trabaja donde está el cursor. Next Edit Prediction va un paso más allá y adivina el cambio relacionado en otra parte del archivo o del proyecto. Brilla justo después de cambios como estos:

• una propiedad nueva en un estado de UI
• un caso renombrado de una sealed class
• una firma de función modificada
• una rama de un mapeo repetido que acabas de actualizar
• la misma comprobación defensiva necesaria en un punto vecino

Cuando el editor muestra Tab to move, un primer Tab te lleva al cambio sugerido y un segundo lo aplica. Si la predicción falla, pulsa Esc. Las predicciones se pueden pausar, y el retardo antes de lanzar una petición se ajusta en la configuración del editor de IA, como explica la página de Next Edit Prediction.

Aceptar sugerencias por reflejo es un mal hábito. Una edición rápida y equivocada copiada en varios archivos sigue siendo una regresión.

5. Pregunta desde donde aparece el error

Cuando falla la sincronización de Gradle o la app se cuelga, el IDE ya tiene contexto estructurado. Usa ahí mismo la acción Ask Gemini en lugar de pegar ruido en un chat.

Dentro de Logcat, Gemini puede recibir el stack trace en cuestión y responder con un resumen en lenguaje llano, causas probables y arreglos sugeridos. La documentación de la integración con Logcat lo cubre. Funciona bien una pregunta de seguimiento que cuestione la respuesta:

Trace this to the first frame owned by our app. Explain the state that makes it fail.
Propose the smallest fix, identify any behavior change, and add a regression test.
Do not hide the problem with a broad try/catch or a non-null assertion.

Esa última instrucción evita dos resultados habituales del tipo "build en verde, arreglo malo".

Con fallos de build, pídele a Gemini que separe el error raíz de la cadena de fallos que provocó. Arreglar el primer error con sentido suele ser más rápido que perseguir 40 mensajes derivados.

6. Genera tests a partir del comportamiento, no de la implementación

Clases completas de tests unitarios en Kotlin o Java, con código de preparación, mocks y casos individuales, están al alcance de Gemini, que las adapta a la configuración que ya tiene el proyecto. Aun así, Google sigue llamando preview a todo el flujo y lo documenta para Android Studio Panda 4 Canary 3 o posterior. La página de generación de tests unitarios tiene los detalles.

Una petición floja se ve así:

Write tests for PlaybackViewModel.

Una útil se ve así:

Generate unit tests for PlaybackViewModel.
Cover observable behavior:
- initial state;
- successful playback start;
- repository failure;
- duplicate play requests;
- cancellation when the ViewModel is cleared.
Use the test libraries and coroutine dispatcher pattern already present in this module.
Do not test private methods or reproduce the implementation in the assertions.
Use deterministic virtual time and verify emitted UI states in order.
Run the narrowest relevant test task after editing.

Revisa todo lo que escriba. Pregúntate si cada test podría fallar por el motivo correcto. Los problemas habituales son mocks demasiado permisivos, aserciones que repiten la preparación, esperas reales, falta de cobertura de la cancelación y tests soldados a detalles privados de la implementación.

La IA es excelente quitando la fricción del andamiaje, pero tu estrategia de tests no es suya.

7. Genera previews de Compose antes de abrir el emulador

Las previews son una forma barata de obtener feedback en Compose, pero escribir datos creíbles para ellas es aburrido. Gemini crea una preview para un único Composable o para cada uno que cumpla los requisitos en un archivo, con datos simulados para los parámetros de la preview incluidos. Ves el resultado como un diff que puedes aceptar o rechazar. Consulta Generate Compose previews.

El camino feliz por sí solo demuestra poco, así que pide una matriz compacta de estados:

Generate previews for compact phone, tablet, and Android TV widths.
Include loading, populated, empty, long-title, and error states.
Use the existing theme and PreviewParameterProvider pattern.
Do not call a ViewModel, network layer, or dependency injection from previews.

Así las previews funcionan como tests de diseño baratos. Las suposiciones de layout suelen romperse con títulos muy largos, contenido vacío, gestión del foco y pantallas grandes.

Para Android TV, pide explícitamente variantes con y sin foco. Un layout que funciona bien al tacto puede desmoronarse cuando alguien lo recorre con el D-pad del mando.

8. Apunta Agent Mode a un corte vertical acotado

En Agent Mode, Gemini puede trazar un plan para un trabajo de varios pasos, editar varios archivos, ejecutar herramientas, compilar el proyecto y reintentar cuando algo falla. También puede llevar varias conversaciones en paralelo, como describe la documentación de Agent Mode.

El punto ideal es un corte vertical acotado, nunca "moderniza la app". Por ejemplo:

Add a Saved Episodes filter to the Downloads screen.
First inspect the existing state, reducer/ViewModel, domain model, repository, and tests.
Reuse the current filter component and architecture.
Do not change persistence or navigation contracts.
Implement the smallest complete slice, add tests, build the module, and summarize every file changed.
Pause before any public API or database schema change.

Una tarea así es lo bastante grande para beneficiarse del trabajo entre archivos y lo bastante pequeña para revisarla.

Usa conversaciones en paralelo solo para trabajos independientes, como generar tests en un hilo mientras otro investiga un aviso de build sin relación. Dos agentes tocando archivos que se solapan son una invitación a suposiciones contradictorias.

9. Haz que el agente demuestre un cambio de UI en un dispositivo

Un diff de código no demuestra que una feature de UI funcione.

El agente de Android Studio puede instalar un build en un dispositivo conectado, mirar la pantalla, hacer capturas, leer Logcat y manejar el dispositivo mediante herramientas de entrada. Tras un arreglo de UI, un prompt de verificación como este cierra el ciclo:

Build and run the app on the connected device.
Open the Downloads screen, apply the Saved filter, and verify the empty and populated states.
Capture a screenshot of the final state and check Logcat for new errors.
If verification fails, stop and report what you observed before making another broad change.

Mantén a una persona en el ciclo de aprobación para todo lo que tenga que ver con inicio de sesión, compras, acciones destructivas o datos reales de usuarios. El acceso al dispositivo hace al agente más capaz, y eso no es lo mismo que hacerlo más fiable.

10. Trata los datos de crashes en producción como punto de partida

Dentro de App Quality Insights puedes pedirle a Gemini que resuma un crash, señale el archivo donde empezó, describa la causa probable y proponga un cambio de código. La guía de análisis de crashes de Google lo explica paso a paso.

Buenas preguntas de seguimiento son:

What evidence in this stack trace supports that root cause?
Which assumptions are you making?
Could this be lifecycle-, concurrency-, process-death-, or device-specific?
What telemetry or test would distinguish the alternatives?

Los crashes en producción suelen revelar problemas de timing y de estado que un solo stack trace no explica. El resumen ahorra tiempo de lectura, pero la hipótesis sigue necesitando validación.

11. Actualiza las dependencias por grupos acotados, de uno en uno

El flujo de dependencias puede encontrar actualizaciones compatibles, modificar el proyecto, resolver los errores de build resultantes, ejecutar los tests y terminar con un informe que incluye diffs por archivo. Se describe en Automate dependency updates.

Es potente, así que reduce el radio de impacto:

Update only Kotlin coroutines and the related test artifact.
Do not update AGP, Kotlin, Compose, Gradle, or unrelated libraries.
Read the relevant migration notes first.
Build affected modules, run their unit tests, and report behavior or API changes.
Stop if the update requires a public API, minSdk, targetSdk, or build-system change.

Evita una revisión gigante de "actualízalo todo" que mezcle AGP, Kotlin, Compose, serialización, DI y veinte librerías. El diff puede aparecer en minutos, pero alguien todavía tiene que entenderlo.

Protege el contexto antes de optimizar los prompts

Cuando está activado el uso compartido del contexto del proyecto, un archivo .aiexclude decide qué puede leer Gemini. Su sintaxis es la misma que la de .gitignore, y cada regla se aplica a la carpeta que contiene el archivo y a todo lo que hay debajo. Las funciones de IA no ven nada fuera del proyecto abierto y sus raíces de VCS adjuntas, pero los archivos sensibles dentro de esos límites deberían excluirse igualmente por nombre. La página de configuración de .aiexclude tiene los pasos.

*.jks
*.keystore
local.properties
secrets/
**/production-config.json
**/customer-data/

Los dos archivos no son intercambiables, así que no los trates como si lo fueran. Averigua qué permite tu organización antes de que código propietario o datos de producción vayan a ninguna parte. En el plan individual, el aviso de privacidad de Google dice que los prompts, las respuestas, los datos de uso y el feedback pueden recopilarse y ser leídos por revisores humanos, y desaconseja introducir información confidencial o personal. Los acuerdos de empresa pueden ser distintos, así que lee las condiciones que cubren tu cuenta.

Una regla de 60 segundos para revisar cambios hechos por IA

Antes de aceptar un diff de Gemini, hazte seis preguntas:

1. ¿El diff se limita a lo que pediste?
2. ¿Siguen intactos los límites de módulos y de arquitectura?
3. ¿Se ha inventado una API, una dependencia o una convención?
4. ¿Los errores se gestionan de verdad o simplemente se tragan?
5. ¿Fallarían los tests nuevos si el comportamiento se rompiera?
6. ¿El build, la ejecución de tests y la comprobación en el dispositivo respaldan el cambio?

Si esas respuestas no salen rápido, el cambio es demasiado grande: divídelo.

El flujo que se va acumulando

Lo que mejor funciona es un ciclo sencillo:

Explicar → planificar → editar → probar → ejecutar → inspeccionar → resumir.

Gemini ayuda más cuando acorta ese ciclo dentro de Android Studio. Y ayuda menos cuando entrega un bloque grande de Kotlin verosímil que nadie ha anclado al repositorio ni ha ejecutado.

La productividad no sale de teclear más rápido. La confianza llega antes: un stack trace que por fin tiene sentido, un test que compila, una preview de Compose con datos realistas, una captura del dispositivo y un diff lo bastante pequeño para leerlo.

Deja que Gemini cubra el tramo mecánico entre una intención y la prueba de que funciona. La arquitectura, las decisiones de compromiso y la responsabilidad siguen siendo trabajo del ingeniero.