Tu agente instala tu app en un teléfono virtual, la abre, toca botones, lee lo que sale en pantalla y te dice si algo se rompió. Tú no mueves un dedo. Aquí montas ese entorno una sola vez y lo usas para siempre.
¿Para quién es esto?
Ya desarrollas una app Android y estás cansado de probar a mano lo mismo en cada cambio. Sabes moverte en una terminal y entiendes qué es una variable de entorno. No necesitas saber de emuladores: eso lo montamos aquí.
Nunca has abierto una terminal o todavía no tienes una app Android. Empieza por los tutoriales de la serie anterior y vuelve cuando tengas tu APK.
Antes de empezar: ¿tu máquina aguanta?
Marca lo que tienes. Un emulador Android no es un programa liviano: es una computadora entera corriendo dentro de la tuya, y encima el agente necesita su parte.
[ Qué gana tu agente con esto ]
Hoy tu agente escribe código a ciegas: cambia algo, te dice que ya está y tú abres el teléfono a comprobarlo. Con este entorno cierra el círculo — escribe, instala, prueba y ve el resultado con sus propios ojos antes de decirte nada.
Toca una capacidad y mírala en el teléfono
Todo esto lo hace el agente solo, por comandos, sobre el teléfono virtual. Ninguna necesita un celular de verdad ni que tú hagas nada a mano.
Cambias una línea, compilas, pasas el APK al teléfono, lo instalas, entras a la pantalla, tocas cinco veces para llegar al caso que te interesa. Ocho minutos. Y como cuesta ocho minutos, terminas probando solo lo que tocaste y no lo de al lado.
Le dices “verifica que sigue funcionando”. Corre el flujo completo —incluido lo de al lado— y vuelve con capturas. Tú mientras tanto estás en otra cosa. Y como no cuesta nada, se prueba todo, siempre.
[ ¿Sirve con Codex, o solo con Claude Code? ]
Esto no depende del modelo ni de lo listo que sea el agente. Depende de una sola cosa: si puede ejecutar comandos en TU máquina y ver la respuesta. Un emulador Android vive en tu disco, en tu procesador y en tu tarjeta gráfica — un agente que corre en un servidor ajeno no puede tocarlo, por muy bueno que sea.
Cuál puede y cuál no
Toca cada uno para ver por qué. La regla, en una línea: si el agente corre en tu terminal, puede; si corre en la nube, no.
Claude Code Sí puede
Es con el que está probado este montaje. Corre en tu terminal, ejecuta comandos y lee la salida, que es todo lo que hace falta.
Codex CLI Sí puede
Sí puede: la versión de terminal de Codex ejecuta comandos en tu propia máquina. Ojo con una cosa — su modo protegido (sandbox) puede bloquearle abrir el emulador o hablar con el teléfono virtual. Si te falla ahí, es permisos, no capacidad: dale acceso a la carpeta del SDK y a la red local.
Codex en la nube / web No puede
No, y no es cosa de configurarlo mejor. Esa versión corre en servidores de OpenAI, dentro de un contenedor aislado que no tiene tu disco, ni tu procesador, ni tu tarjeta gráfica. Puede escribirte el código de la app; no puede instalarla en un teléfono que vive en tu casa.
opencode Sí puede
Igual que los otros de terminal: ejecuta comandos locales. Cambia el prompt de arranque si usas otro nombre de carpeta de skills, y de ahí en más es lo mismo.
Cursor / agentes dentro del editor Con peros
Pueden ejecutar comandos, así que técnicamente sí. El problema es de constancia: si el agente vive dentro de una app empaquetada, sus rutas no siempre son las que tú ves en una terminal normal — justo la primera trampa de más abajo. Funciona, pero prepárate a pelear con las rutas.
[ El montaje, paso a paso ]
Aquí está la parte que sorprende: de todo el montaje, solo TRES cosas son tuyas. Lo demás lo hace el agente con un único prompt. No hace falta que teclees comandos ni que sepas qué es un SDK.
Es lo único que NO puede hacer el agente por ti, y si falta, nada de lo demás sirve. Reinicias, entras a la BIOS y buscas WHPX (en Intel) o SVM (en AMD). ¿No sabes si ya la tienes? Pégale esto a tu agente y te lo dice sin reiniciar nada.
Dime si esta máquina tiene la virtualización de hardware activada y si el emulador de Android podría usarla. Compruébalo ejecutando comandos (no me lo supongas) y dime exactamente qué hay que activar en la BIOS si está apagada.
Qué deberías verDebe responderte con un sí o un no claro y decirte el nombre de la opción (WHPX, Hyper-V, SVM o VT-x). Si te contesta “probablemente sí” sin haber ejecutado nada, insiste en que lo compruebe.
Este de aquí abajo. Cópialo tal cual, sin cambiarle nada. Le dice qué instalar, en qué orden y —lo más importante— que verifique cada paso ejecutándolo antes de pasar al siguiente.
Quiero que dejes montado en esta máquina un entorno de pruebas de Android con un teléfono virtual (emulador) que puedas manejar tú solo, sin que yo tenga que intervenir. Hazlo paso a paso y verifica cada paso antes de pasar al siguiente — no des nada por instalado hasta que lo hayas comprobado ejecutándolo.
1. Instala el JDK 17 y confirma que responde con `java -version`.
2. Instala las command line tools del Android SDK. Acepta las licencias: `sdkmanager --licenses` no acepta que le canalices "y" desde PowerShell, así que escribe los archivos de hash directamente en la carpeta `licenses` del SDK.
3. Con `sdkmanager` instala: `platform-tools`, `emulator`, y la imagen de sistema `system-images;android-34;google_apis;x86_64`.
4. IMPORTANTE — comprueba dónde quedó instalado de verdad. Si me estás hablando desde una app empaquetada, tu `AppData\Local` está redirigido y el SDK va a terminar dentro del paquete: tú lo verás en `AppData\Local\Android\Sdk` y yo desde mi consola no. Verifica con `Test-Path` la ruta física real y usa siempre esa en los scripts. Mejor todavía: instálalo en una carpeta neutra tipo `C:\Android\Sdk`.
5. Crea un teléfono virtual llamado `Telefono_QA` con 4 GB de RAM y pantalla 720x1600 a 320 dpi — a propósito modesto, para que lo que probemos se parezca al teléfono real de un usuario y no a un equipo de gama alta. Edita el `config.ini` leyéndolo como diccionario y reescribiéndolo entero; si lo parcheas con expresiones regulares vas a dejar claves duplicadas.
6. Arráncalo con `-gpu host -no-snapshot-load`. Con `-gpu auto` se cuelga (queda congelado y `adb` lo reporta offline), y los snapshots a medio guardar heredan el cuelgue en el siguiente arranque.
7. Instala Maestro para escribir flujos de prueba en YAML.
8. Déjame un script de apoyo con funciones de nombre claro para: ver el estado del entorno, levantar y apagar el teléfono, tomar capturas, falsear el GPS, cortar y restaurar la señal, leer los textos de la pantalla, subir el volumen, cambiar la RAM, instalar un APK, ver los errores de la app y correr un flujo de prueba.
9. Déjame también un acceso directo en el escritorio para abrirlo yo con doble clic, con la ruta física escrita literalmente.
10. Verifica de punta a punta antes de decirme que está listo, y muéstrame la evidencia: una captura legible del teléfono arriba, un toque que cambie la pantalla, el GPS puesto en una coordenada, la señal cortada y restaurada, y el volcado de los textos de una pantalla. Si algo no lo pudiste comprobar, dímelo explícitamente en vez de darlo por hecho.[ Qué le acabas de pedir ]
Pegar diez instrucciones sin saber qué dicen es cómo se firma un contrato sin leerlo. Aquí está cada punto traducido: qué hace y por qué está escrito así. Cada frase rara de ese prompt salió de un problema real que ya costó horas — no es paranoia, es cicatriz.
El prompt, punto por punto
Toca cualquiera para ver qué hace y por qué está redactado de esa forma tan específica.
«Verifica cada paso antes de pasar al siguiente»
Le prohíbe avanzar dando cosas por instaladas. Tiene que ejecutar algo y ver la respuesta antes de seguir.
Por qué asíEs la línea más importante del prompt entero. Sin ella, el agente encadena diez pasos suponiendo que el anterior salió bien, y cuando algo falla en el tercero te enteras en el décimo — con todo lo de en medio mal construido.
Instala el JDK 17 y confirma con java -version
Pone Java, que es el motor sobre el que corren las herramientas de Android.
Por qué asíEl «confirma con java -version» no sobra: instalar y quedar disponible en la terminal son dos cosas distintas. Muchas instalaciones terminan bien y aun así el comando no responde.
Instala las command line tools y acepta las licencias escribiendo los hash
Baja el instalador de piezas de Android y acepta los términos legales de Google.
Por qué asíEl comando normal para aceptar licencias se queda colgado esperando en PowerShell. Escribir los archivos de licencia a mano es el rodeo que sí funciona — la trampa nº 3 de más abajo.
Instala platform-tools, emulator y la imagen android-34
Las tres piezas de verdad: el cable de comunicación (adb), el emulador, y el sistema operativo del teléfono virtual.
Por qué asíLa imagen es lo que pesa: unos 6 GB. Se pide android-34 (Android 14) porque es lo que tiene la mayoría de gente, no lo más nuevo.
IMPORTANTE — comprueba DÓNDE quedó instalado de verdad
Le obliga a confirmar la ruta física real, no la que él cree, y a instalarlo en una carpeta neutra.
Por qué asíÉste es el punto que más tiempo ha costado. Si tu agente vive dentro de una app empaquetada, Windows le redirige las carpetas sin avisar: el SDK acaba en un sitio que solo él ve, y desde tu terminal esa misma ruta «no existe». Es la trampa nº 1.
Crea Telefono_QA con 4 GB de RAM, reescribiendo el config.ini entero
Crea el teléfono virtual, modesto a propósito.
Por qué asíModesto porque lo que quieres probar es cómo va tu app en el teléfono de un usuario cualquiera, no en un equipo de gama alta donde todo va bien. Y «reescribiendo entero» porque parchear ese archivo línea por línea deja claves duplicadas y el emulador arranca ignorando lo que pediste.
Arráncalo con -gpu host -no-snapshot-load
Enciende el teléfono usando tu tarjeta gráfica de verdad y sin cargar estados guardados.
Por qué asíUna palabra decide entre un teléfono que funciona y uno congelado. Con -gpu auto se queda tildado, sin táctil y reportado como desconectado. Y si llegó a guardar un estado en ese lío, el siguiente arranque hereda el cuelgue.
Instala Maestro
Añade la herramienta para escribir recorridos de prueba en un archivo de texto.
Por qué asíEs lo que convierte «pruébalo» en algo repetible. Escribes el recorrido una vez y se ejecuta igual en cada cambio, para siempre.
Déjame un script de apoyo con funciones de nombre claro
Te deja un archivo con atajos: levantar el teléfono, capturar, falsear GPS, cortar señal, leer errores.
Por qué asíPara que no dependas de que el agente recuerde los comandos exactos cada vez. Y de nombre claro para que TÚ también puedas usarlo sin preguntarle a nadie.
Déjame un acceso directo en el escritorio, con la ruta escrita literalmente
Un icono para abrir el entorno con doble clic.
Por qué así«Literalmente» es a propósito: si el acceso directo se arma con variables, se rompe justo por el problema de rutas del punto 4.
Verifica de punta a punta y muéstrame la evidencia
Le exige demostrar que todo funciona: captura, toque, GPS, corte de señal y lectura de pantalla.
Por qué asíSin esto un agente te dice «listo» y tú te enteras tres días después de que la mitad no servía. La última frase —«si algo no lo pudiste comprobar, dímelo»— es la que le da permiso para admitir fallos en vez de rellenar el hueco.
[ Mientras trabaja: cómo saber si va bien ]
El montaje tarda un rato y el agente va a escribir mucho. Estas tres preguntas sirven para no quedarte mirando texto sin saber si vas bien. Cópialas y pégaselas cuando quieras.
Párate un momento y dime en lenguaje simple: ¿en qué punto de los 10 vas, qué diste por terminado y cómo lo comprobaste? Si algo lo diste por bueno sin ejecutarlo, dímelo ahora.
Qué deberías verUn número de paso y, junto a cada cosa terminada, el comando con el que la verificó. Si no puede decirte cómo comprobó algo, es que no lo comprobó.
El emulador no responde. Antes de reinstalar nada, comprueba en este orden y dime qué encontraste: 1) si arrancó con -gpu host o con -gpu auto, 2) si adb lo ve como device u offline, 3) si hay un snapshot guardado de un arranque anterior. Después arréglalo.
Qué deberías verQue te diga cuál de los tres era, no que empiece a reinstalar cosas. Casi siempre es el primero.
Demuéstrame que el entorno funciona, sin darme nada por hecho: toma una captura del teléfono encendido, tócale algo y muéstrame que la pantalla cambió, pon el GPS en una coordenada, corta la señal y devuélvemela, y vuélcame los textos de una pantalla. Si alguna no la pudiste hacer, dilo explícitamente en vez de rellenarlo.
Qué deberías verCinco pruebas, no un resumen. Si te contesta con un «todo funciona correctamente» sin enseñarte nada, no está listo.
Es tu único trabajo real después de pegar el prompt: no aceptar un «ya quedó» sin evidencia. Usa la última pregunta de arriba. Un entorno que dice funcionar y no lo demuestra te va a costar más tiempo del que te ahorra.
[ Las cuatro trampas ]
Búscate por el síntoma
Si algo te falla, lo más probable es que sea una de estas cuatro. Están ordenadas por lo seguido que aparecen. Toca la que se parezca a lo tuyo.
La ruta fantasma
Tu agente jura que instaló el SDK y te enseña la ruta. Tú pegas esa MISMA ruta en tu terminal y te dice “no se encuentra el archivo”. Mismo usuario, permisos completos, y aun así no existe.
Tu agente corre dentro de una app empaquetada de la Store. Para esas apps, Windows redirige AppData\Local a AppData\Local\Packages\<app>\LocalCache\Local sin avisar. Los dos tienen razón: el archivo existe para él y no existe para ti, porque no están mirando la misma carpeta.
Instálalo en una carpeta neutra —C:\Android\Sdk— que se ve igual desde los dos lados. Para diagnosticarlo, corre Test-Path con la misma ruta desde el agente y desde tu terminal: si uno dice True y el otro False, es esto. Riesgo extra si lo dejas así: el día que se reinstale esa app, tu SDK se va con ella.
El teléfono congelado
El emulador abre, se ve la pantalla de Android… y ahí se queda. No responde al táctil y adb lo reporta como offline.
Arrancó con -gpu auto. El “auto” elige mal el modo de gráficos y deja el teléfono colgado. Peor: si guardó un snapshot en ese estado, el siguiente arranque hereda el cuelgue y parece que el problema es otro.
Arráncalo siempre con -gpu host -no-snapshot-load. El -gpu host además usa tu tarjeta gráfica de verdad, así que va bastante más rápido de paso.
Las licencias que no se aceptan
sdkmanager se queda esperando para siempre, o dice que no aceptaste las licencias aunque juraste que le diste que sí.
El comando interactivo de licencias no se lleva bien con PowerShell: canalizarle “y” no funciona como en Linux.
Que el agente escriba los archivos de hash directamente en la carpeta licenses del SDK. Es lo mismo que hace el comando interactivo, pero sin depender de que la terminal se porte bien.
El teléfono que no hace caso
Le pediste 4 GB de RAM y arrancó con otra cosa. Cambias el valor, reinicias, y sigue igual.
El config.ini del teléfono virtual se parcheó con expresiones regulares y quedaron claves duplicadas. El emulador lee la última que encuentra, no la que tú editaste.
Que lo lea entero como diccionario, cambie la clave y lo reescriba completo. Nunca parchear línea por línea un archivo de configuración: o lo entiendes entero o lo rompes.
[ Qué NO te resuelve esto ]
Emulador / AVD
Un teléfono Android completo corriendo como programa dentro de tu computadora. AVD es el nombre de cada teléfono virtual que creas: puedes tener varios, con distinta RAM y pantalla.
adb
El cable invisible entre tu computadora y el teléfono (virtual o real). Todo lo que hace el agente —tocar, instalar, leer la pantalla— pasa por aquí.
APK
El archivo instalable de tu app, el equivalente al .exe de Windows. Es lo que el agente le mete al teléfono virtual.
Maestro
Herramienta para escribir recorridos de prueba en un archivo de texto: “abre la app, toca aquí, escribe esto, comprueba que aparezca aquello”. Se escribe una vez y se repite siempre igual.
WHPX / SVM
El permiso del procesador para correr una computadora dentro de otra. WHPX en Intel, SVM en AMD. Viene apagado de fábrica en muchos equipos y se enciende en la BIOS: sin esto el emulador ni arranca.
sdkmanager
El instalador de piezas de Android por línea de comandos. Con él se bajan el emulador, adb y la imagen del sistema operativo del teléfono.