Android CLI de Google: lo probé con Claude Code
Lo primero que probé después de instalar el nuevo Android CLI de Google fue el comando más aburrido del manual. android create. Plantilla de actividad vacía. Sin indicadores inteligentes, sin indicaciones creativas: simplemente lo más común que se le ocurre a un cerebro entrenado por Java después de quince años de hacer clic en el asistente "Nuevo proyecto" de Android Studio.
Terminó en once segundos. Un proyecto Kotlin en funcionamiento. Gradle conectado. Redactar dependencias ancladas. Manifiesto cuerdo. Abrí el directorio en mi editor y lo miré como si me hubiera insultado.
He pasado tantas horas de mi vida dentro de ese mago. Elegir versiones mínimas de SDK. Alternando "Incluir soporte Hilt". Me pregunto si esta vez realmente quiero un gráfico de navegación. El mago está bien. También es un impuesto que pago cada vez que quiero empezar algo nuevo en Android, y el impuesto se paga por atención, no por minutos. Once segundos en una terminal acababan de eliminarlo.
Esa fue la primera sorpresa. La segunda sorpresa, la que realmente importó, llegó aproximadamente una hora después, cuando apunté con Claude Code al Android CLI y vi a un agente hacer algo que habría jurado que faltaba un año.
Así es como se ve un lanzamiento importante y silencioso. Google obtuvo una vista previa de [Android CLI el 16 de abril de 2026] (https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html), escondido dentro de una publicación de blog de desarrollador que ni siquiera llegó a la cima de Hacker News esa semana. Sin discurso de apertura. No hay vídeo de lanzamiento con tomas cinematográficas de drones. Solo un enlace de descarga en d.android.com/tools/agents, una etiqueta de vista previa de la versión 0.7 y una promesa silenciosa de que esto fue creado primero para los agentes y luego para los humanos.
Quiero explicarle lo que probé, lo que funcionó, lo que falló y por qué creo que esta CLI cambiará la forma en que construyo aplicaciones Android durante los próximos dos años. Quédese conmigo durante la instalación: la parte interesante aparece alrededor del tercer comando.
Por qué incluso existirá una CLI para Android Studio en 2026
Para comprender por qué Google creó esto, debe comprender el problema que resuelve. Y el problema no es "Android Studio es molesto". Android Studio está bien. El problema es que los agentes AI no pueden usar Android Studio.
Piense en cómo funcionan realmente Claude Code, Codex o Gemini CLI. El agente lee archivos. El agente escribe archivos. El agente ejecuta comandos de shell y lee su salida. Esa es toda la superficie. Es un sistema de entrada y salida de texto que reside en su terminal. Cuando le pides a uno de estos agentes que "me cree una nueva pantalla para la página de configuración", puede editar tus archivos Kotlin durante todo el día. Lo que no puede hacer es abrir Android Studio, hacer clic en Archivo → Nuevo → Actividad, completar el cuadro de diálogo y hacer clic en Aceptar.
Entonces, durante los últimos dos años, cada agente que tocó el desarrollo de Android ha estado haciendo este baile incómodo: generando archivos a mano que Android Studio habría generado correctamente a través de plantillas, jugueteando con la configuración de Gradle que no entendía completamente y pidiendo constantemente al humano que "simplemente abra Studio y haga clic en esto por mí". El agente era un brillante colaborador con una mano permanentemente atada a la espalda.
El Android CLI corta ese nudo. Expone las partes de Android Studio que los agentes realmente necesitan (creación de proyectos, control del emulador, inspección de diseño, búsqueda de documentación, captura de captura de pantalla) como comandos simples que cualquier agente puede ejecutar desde un shell. De repente el agente tiene ambas manos.
Los números que informa Google respaldan esto de una manera que no esperaba. En sus puntos de referencia internos, [los agentes que utilizaron Android CLI completaron tareas 3 veces más rápido y consumieron un 70 % menos de tokens] (https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html) que los agentes que intentaron impulsar la antigua cadena de herramientas directamente. Por lo general, soy escéptico con respecto a los números de los proveedores: cada lanzamiento de herramienta afirma que es 10 veces más rápido que lo que reemplaza, y casi nunca lo es. Pero la reducción simbólica del 70% pasa la prueba del olfato para mí. Explicaré por qué en un minuto, cuando lleguemos al comando de diseño.
Pero antes de todo eso, instalemos el dispositivo. Porque Google tomó una decisión aquí que confundirá a la primera ola de desarrolladores que intenten esto.
Instalación de Android CLI: no es donde crees
Si ya tiene Android Studio instalado y asume que la nueva CLI viene con él (al igual que adb, sdkmanager y el resto de las herramientas de la plataforma), pasará diez minutos frustrados buscando en su directorio Android/sdk un binario que no existe allí.
El Android CLI se envía por separado. A propósito. Lo instala desde d.android.com/tools/agents, que le brinda un único binario para macOS, Linux o Windows. No hay indicadores del administrador del SDK. Sin complemento Gradle. Simplemente descárgalo, muévelo a tu PATH y listo.
Lo instalé en mi Mac así:
curl -L -o android https://d.android.com/tools/agents/macos/android
# Make it executable and move it into PATH
chmod +x android
sudo mv android /usr/local/bin/
# Verify
android -h
El resultado de -h es lo primero que vale la pena leer. Enumera todos los comandos que admite la CLI (create, docs, emulator, screen, layout, resolve, skills, init) y una descripción de una línea para cada uno. Lo leí dos veces antes de ejecutar cualquier otra cosa, porque la superficie de comando es lo suficientemente pequeña como para que puedas tenerlo todo en tu cabeza, lo cual importa más de lo que parece.
Después de la instalación, el siguiente paso es android init. Aquí es donde ocurre la magia, y un leve problema.
android init
Lo que hace init: escanea su directorio de inicio en busca de agentes de codificación instalados, encuentra todos los que reconoce y coloca una copia de las habilidades oficiales de Android en el directorio de habilidades de cada agente. En mi máquina encontró Claude Code en ~/.claude/, abandonó la habilidad allí y me preguntó si quería instalarlo también para Gemini CLI y Antigravity. A ambos les dije que sí, porque por qué no.
El problema leve: si no tiene ningún agente de codificación instalado y ejecuta init sin argumentos, de forma predeterminada instalará habilidades para Gemini y Antigravity en ~/.gemini/antigravity/skills. Si desea limitar el alcance de la instalación, pase --agent=claude-code o --agent=gemini o cualquier destino que realmente utilice. Aprendí esto de la manera más difícil después de preguntarme durante diez minutos por qué la instalación de mi Cursor no estaba adquiriendo las habilidades; resulta que tuve que volver a ejecutar android init --agent=cursor explícitamente.
El subcomando oficial skills add enumera [37 objetivos de agentes admitidos] (https://www.devclass.com/development/2026/04/21/google-previews-android-cli-for-new-world-of-agentic-development/5218263) en este punto: claude-code, gemini, codex, cursor, opencode, windsurf, cline, Aider, github-copilot y una larga cola del ecosistema de agentes de codificación más pequeño. Lo que sea que esté usando, es casi seguro que esté en la lista.
Una vez que finalice init, habrá terminado con la configuración. La CLI está instalada, las habilidades se cargan en sus agentes y puede comenzar a usar los comandos orientados a humanos y las habilidades orientadas a agentes juntos. De aquí en adelante, todo lo que probé a continuación funciona igual ya sea que ejecuto los comandos directamente o si dejo que Claude Code los controle.
Los seis comandos que realmente importan
La CLI expone alrededor de una docena de subcomandos, pero sigo buscando seis de ellos. Permítanme repasar cada uno con lo que probé y lo que aprendí.
android create — Andamio de proyectos que deja de hacerle perder el tiempo
Esta es la droga de entrada. android create genera un proyecto completo de Android Studio a partir de una plantilla, con valores predeterminados sensibles incorporados. La plantilla predeterminada es empty-activity, que le brinda un iniciador basado en Compose con Kotlin, AGP 9 y un tema básico ya conectado.
android create --name MyApp --package com.mejba.myapp
Once segundos. Hecho. Puede pasar --template para elegir algo que no sea la actividad vacía: la vista previa v0.7 incluye plantillas para Compose Material 3, navegación y algunos otros puntos de partida comunes. Espero que esta lista crezca.
Lo que me sorprendió aquí no fue la velocidad. Fue la coherencia. Cuando desarrollas un proyecto de esta manera, obtienes los valores predeterminados actuales recomendados por Google, los que el equipo de Android mantiene activamente. Ya no es necesario iniciar un proyecto en 2026 con patrones que eran idiomáticos en 2023. La CLI es, de hecho, una bomba de frescura obstinada para nuevos proyectos.
android docs: el comando que hace que su agente esté menos equivocado
Este parece pequeño y es enorme. android docs search <query> accede al índice de documentación oficial Android y devuelve una lista de URL de documentos relevantes. android docs fetch <url> extrae el contenido de una página de documento específica como texto sin formato.
android docs search "navigation 3 setup"
android docs fetch https://developer.android.com/guide/navigation/navigation-3
¿Por qué es esto enorme? Porque cada desarrollador de Android que ha utilizado un agente AI ha visto cómo el agente inventaba con confianza una API que no existe, o generaba código basado en un patrón obsoleto de 2022, o alucinaba con un modificador de redacción cuyo nombre cambió hace dieciocho meses. La razón por la que hace esto es que los datos de entrenamiento del agente están congelados en algún momento del pasado y Android se mueve rápidamente.
Cuando el agente tiene acceso a android docs, puede basar su respuesta en la documentación actual en el momento de la consulta. Vi a Claude Code usar este patrón exacto cuando le pedí que migrara un gráfico de navegación basado en fragmentos a Navegación 3; el primer comando fue android docs search "navigation 3 migration", luego android docs fetch en el resultado superior y luego escribió código que realmente se compiló con la API actual.
Por cierto, esa es la reducción de tokens del 70% sobre la que sigues leyendo. No es magia. El agente deja de hacer preguntas aclaratorias, deja de generar código roto que debe corregirse, deja de realizar cinco intentos para encontrar el nombre del modificador correcto. Una búsqueda de documentos y luego una edición correcta. El coste simbólico de docs fetch es real pero pequeño; el costo simbólico de tres rondas de código roto y corrección es enorme.
android emulator — Finalmente, control del emulador desde un Shell
Activar un emulador desde dentro de Android Studio está bien. Activar un emulador desde una canalización de CI, o desde dentro de un bucle de agente, solía requerir una pila de comandos avdmanager, sdkmanager y emulator que tenía que buscar cada vez. La nueva CLI reemplaza eso con android emulator list, android emulator create, android emulator start y android emulator stop.
android emulator list
android emulator start --device pixel_8_pro --api 34
Probé esto en una máquina limpia: instalación nueva de SDK, sin AVD preconfigurados. La CLI se encargó de aprovisionar el perfil del dispositivo, descargar la imagen del sistema si faltaba y ejecutar el emulador con una configuración de ventana sensata. Unos noventa segundos de un extremo a otro en una conexión por cable. Nada que no pudiera haber hecho yo mismo con cinco comandos de terminal; todo lo que no tenía que recordar cómo hacerlo.
android layout: JSON en lugar de capturas de pantalla y por qué es importante
Aquí es donde la CLI comienza a parecer como si hubiera sido diseñada por alguien que realmente envió flujos de trabajo de producción AI. android layout consulta el emulador o dispositivo conectado actualmente en ejecución y devuelve un documento JSON que describe toda la jerarquía de la interfaz de usuario: cada elemento, su posición, su contenido de texto, sus hijos.
android layout --pretty --output current-screen.json
El resultado es un árbol estructurado. Botones, campos de texto, elementos de vista del reciclador, modales: todo ello representado como nodos JSON con límites, identificadores y contenido. Un agente AI puede leer esto en unos cientos de tokens y saber exactamente qué hay en la pantalla, qué botones existen, qué texto muestran y dónde se encuentran en el diseño.
Compare esto con la alternativa, que le pide al agente que mire una captura de pantalla y descubra la interfaz de usuario a partir de píxeles. Los modelos de visión funcionan. También queman fichas como una estufa de leña. Una captura de pantalla de 1080p equivale a miles de tokens una vez que el modelo la codifica; un diseño JSON para la misma pantalla suele tener menos de quinientos. Para los bucles de agentes que necesitan comprender el estado de la interfaz de usuario en cada turno, esta es la diferencia entre un flujo de trabajo asequible y uno que le cuesta diez dólares por tarea.
También está android layout --automator, que recurre al formato XML clásico de UI Automator con los metadatos enfocables /enabled que los ingenieros de automatización de pruebas han estado analizando durante años. Misma idea, forma ligeramente diferente, útil cuando se necesitan las convenciones del marco de prueba.
android screen capture: capturas de pantalla con anotaciones integradas
El comando screen capture hace lo que cabría esperar: toma una captura de pantalla PNG del dispositivo actual. La bandera interesante es --annotate, que dibuja cuadros delimitadores etiquetados alrededor de cada elemento de la interfaz de usuario detectado y le asigna un número a cada uno.
android screen capture --output screenshot.png
android screen capture --annotate --output annotated.png
Cuando el agente tiene una captura de pantalla anotada, puede hacer referencia a los elementos por su etiqueta numérica. "Toca el elemento 4" en lugar de "toca el botón que dice 'Continuar' en la esquina inferior derecha". Menos ambigüedad, menos toques incorrectos y mucho menos intercambios entre el agente y el dispositivo.
Esta es una pequeña mejora ergonómica que se agrava enormemente durante una sesión larga con el agente. Vi una sesión de Claude Code ejecutar treinta interacciones de UI seguidas sin un solo toque incorrecto porque cada referencia era numérica. Con capturas de pantalla sin formato, se esperaría al menos tres o cuatro fallos en tantas acciones.
android screen resolve: el puente entre el agente y ADB
Una vez que el agente ha decidido con qué elemento quiere interactuar, android screen resolve convierte el identificador numérico de una captura de pantalla anotada en coordenadas de píxeles reales en el dispositivo actual.
android screen resolve --element 4
# returns something like: { "x": 540, "y": 1820 }
Puede canalizar esas coordenadas directamente a adb shell input tap 540 1820 y tendrá un canal de automatización de UI en funcionamiento. Este es el momento en que la CLI deja de ser una ayuda de andamiaje de proyectos y comienza a ser una cadena de herramientas de prueba completa impulsada por agentes. Un agente puede: iniciar un emulador, instalar su APK, capturar una captura de pantalla anotada, decidir qué tocar, resolver coordenadas, activar el grifo a través de ADB, capturar otra captura de pantalla y verificar el nuevo estado, todo en un bucle continuo, todo en comandos simples.
Es, hasta donde puedo decir, la primera vez que alguien integra ese bucle en las herramientas oficiales Android. No es un marco de terceros. No es un proyecto de investigación. El propietario real de la plataforma lo envió.
Si desea ver cómo se ve un ecosistema de agentes cuando se construye en torno a habilidades como esta desde cero, mi guía de habilidades de agentes para Claude Code recorre el mismo patrón en un dominio diferente, y los paralelos son sorprendentes.
Lo que construí en un fin de semana (y lo que se rompió)
La teoría está bien. Déjame contarte lo que realmente sucedió cuando intenté usar esto para un trabajo real.
El proyecto: una pequeña aplicación de seguimiento de hábitos, basada en Compose, tres pantallas, base de datos Room, Hilt para DI. Nada exótico. Algo que he construido variantes media docena de veces para probar nuevas herramientas.
El plan: hacer que Claude Code impulse toda la compilación a través de Android CLI. Escribiría la especificación en un archivo de rebajas, se lo entregaría a Claude y le dejaría crear el proyecto, configurar la dependencia, crear andamios de pantalla, probar el emulador y realizar iteraciones por sí solo. Sólo intervendría cuando algo se rompiera.
El resultado, después de una tarde de sábado: una aplicación que funciona en el emulador. Tres pantallas. CRUD sobre hábitos. Persistencia trabajando. Una interfaz de usuario de redacción chiflada pero funcional. Tiempo total dirigido por el agente: unas tres horas, con quizás cuarenta y cinco minutos de intervención humana.
Lo que funcionó maravillosamente:
El paso de andamiaje del proyecto fue instantáneo. Claude ejecutó android create --name HabitTracker --package me.mejba.habits e inmediatamente preguntó al índice de documentos sobre las mejores prácticas actuales sobre la configuración de Hilt con Compose. Recuperó el documento canónico, extrajo los fragmentos relevantes y agregó las dependencias y módulos sin equivocarse. Todo el arranque del proyecto desde el "directorio vacío" hasta "compilación y ejecución" tomó ocho minutos. Me quedé anonadado.
El bucle del emulador fue donde sentí el verdadero cambio. Claude escribía una pantalla, ejecutaba android emulator start, compilaba e instalaba el APK, luego android screen capture --annotate para ver cómo se veía realmente la pantalla. Cuando el diseño era incorrecto, comparaba la captura de pantalla con mis especificaciones, editaba el archivo de redacción, lo reconstruía y capturaba nuevamente. No hay ningún ser humano en el circuito de la retroalimentación visual: el agente podría ver su propio trabajo e iterarlo. He querido esto durante dos años.
Lo que se rompió:
The first hard wall was Hilt. Claude generó un módulo Hilt perfectamente correcto que no funcionó porque el complemento kapt no estaba habilitado en el archivo Gradle del proyecto. The error message was clear; the fix was one line. Claude lo encontró en el segundo intento, pero solo después de que le insinué que el problema era la configuración de Gradle en lugar del código Hilt. La CLI aún no tiene un subcomando gradle, y esa es una brecha que sentí.
The second hard wall was emulator stability. Aproximadamente dos horas después, mi emulador llegó a un estado en el que no respondía a la entrada táctil. android screen capture devolvió una imagen congelada. adb shell input tap did nothing. Tuve que android emulator stop manualmente, reiniciarlo y reinstalar la aplicación. Claude no podría haberse recuperado de esto por sí solo: el modo de falla estaba debajo de la capa de abstracción de la CLI. Esto se volverá más suave con el tiempo, pero aún no lo es.
El tercer tema fue más interesante. Alrededor del 80% del proceso de construcción, Claude se volvió perezoso. Las vistas previas de Compose que generó dejaron de usar los proveedores @PreviewParameter que había configurado anteriormente; el andamiaje de prueba que escribió en la pantalla uno no se llevó a las pantallas dos y tres. La CLI no puede solucionar este problema: es un problema de comportamiento del agente, no un problema de herramientas. Pero es un recordatorio de que la CLI elimina la fricción del ciclo de compilación sin eliminar la responsabilidad de dirigir el trabajo del agente.
Si ha leído mi artículo sobre por qué [el contexto supera a la configuración en el diseño del agente] (https://www.mejba.me/ai-agent-context-beats-configuration), sabrá que soy un disco rayado en este punto. Mejores herramientas no reemplazan una mejor dirección. Simplemente dejaron que la mala dirección fracasara más rápido.
El sistema de habilidades: esta es la verdadera historia
He estado hablando de comandos durante dos mil palabras. Permítanme retroceder y contarles sobre la parte que creo que será más importante durante el próximo año y de la que casi nadie habla todavía.
Android CLI se entrega con un sistema de [habilidades del agente] (https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html): archivos de rebajas que le enseñan a un agente cómo usar la CLI para una tarea específica. La vista previa v0.7 incluye habilidades para la configuración de Navigation 3, migración de borde a borde, actualización de AGP 9, migración de XML a Compose, análisis de reglas de mantenimiento de R8 y actualización de la biblioteca de facturación de Play Google.
Cuando ejecuta android init, esas habilidades se instalan en el directorio de habilidades de su agente. Cuando le pide a Claude Code que "migre este diseño XML a Compose", carga la habilidad relevante, sigue las instrucciones que escribió Google y usa los comandos CLI que recomienda la habilidad. El agente ya no está adivinando cómo realizar una migración de Compose en función de sus datos de entrenamiento: está siguiendo el manual oficial del equipo Android para esa tarea específica.
Este es el patrón que he estado esperando durante dos años a que alguien me lo envíe. El propietario de la plataforma (el equipo que realmente sabe la forma correcta de hacer algo) escribe el manual una vez, en un formato que el agente pueda leer, y todos los desarrolladores que utilizan cualquier agente obtienen el beneficio. No es un tutorial enterrado en desarrollador.android.com que nadie lee. No es una respuesta de Stack Overflow que fuera correcta en 2022. Un conjunto de instrucciones en vivo, ejecutable y legible por el agente, mantenido por el equipo propietario de la plataforma.
Si Google hace esto bien (y "hacer esto bien" significa un flujo constante de nuevas habilidades, actualizaciones rápidas cuando cambian las API y una integración profunda con el resto de la plataforma), esta será la herramienta de desarrollo menos apreciada de 2026. La CLI es la superficie. Las habilidades son la sustancia.
Y aquí está lo que nadie menciona en la cobertura del lanzamiento: puedes escribir tus propias habilidades. El formato es abierto. Si su equipo tiene estándares arquitectónicos ("use siempre este patrón DI, nunca este"), puede escribir una habilidad que enseñe a todos los agentes de su equipo a seguirlos. Puedes enviar esa habilidad como parte de tu repositorio. Se une un nuevo desarrollador, ejecuta android init y, de repente, su agente hace cumplir los estándares de su equipo. La memoria institucional de su código base se vuelve ejecutable.
Esto es algo silencioso, extraño e importante. Voy a escribir más sobre ello.
Qué significa esto para el desarrollo de Android en 2026
Permítanme decir lo que creo que está sucediendo aquí, porque no lo veo claramente expresado en ningún otro lugar.
Google acaba de decirle a la comunidad de desarrolladores Android que el futuro del desarrollo de Android está impulsado por agentes, y construyeron las herramientas oficiales en torno a esa suposición. No como una apuesta paralela. No como un proyecto de laboratorio experimental. Como la próxima generación de cómo la plataforma espera que usted trabaje.
La señal es inequívoca cuando se mira lo que hicieron y lo que no hicieron. No crearon una "CLI de Gemini para Android". Crearon una CLI que admite 37 agentes en igualdad de condiciones, incluidos Claude Code y Codex, competidores directos de su propio Gemini. Esta es una decisión estratégica de Google para optimizar la productividad de los desarrolladores en lugar de la dependencia del agente. Le indica que han decidido que la plataforma gana cuando los desarrolladores envían más aplicaciones más rápido, independientemente del agente que utilicen para hacerlo.
Esa decisión ejercerá presión sobre todos los demás propietarios de plataformas móviles. La historia de las herramientas de desarrollo de Apple para los agentes AI es, en el momento de escribir este artículo, básicamente inexistente: Xcode no se puede programar en ninguna de las formas que necesita un agente y no existe una CLI bendecida por Apple para la creación de proyectos, el control del simulador o la inspección de la interfaz de usuario. Si la brecha de productividad entre el desarrollo de Android impulsado por agentes y el desarrollo de iOS con Xcode mediante clic se triplica, como sugieren los números de Google, esa brecha comenzará a aparecer en la velocidad de envío. Los equipos multiplataforma lo notarán.
Para los desarrolladores individuales, la implicación práctica es más sencilla. Si compila para Android y aún no está utilizando un agente AI en su flujo de trabajo, la vía de acceso se ha vuelto mucho más corta. La CLI maneja las partes del flujo de trabajo que solían requerir el IDE. Claude Code o Gemini CLI o Codex manejan las partes que solían requerirlo. Usted se convierte en el arquitecto, el revisor y la persona que sabe cómo se ve bien, y el agente escribe a máquina.
Si desea ver cómo se desarrolla este mismo patrón en el lado del escritorio, mi tutorial de Antigravity, IDE de Google para agentes AI, cubre el mismo cambio en los flujos de trabajo en forma de IDE. Mismo libro de jugadas, diferente superficie.
Donde el Android CLI sigue siendo difícil
He sido positivo en esta publicación porque creo que el lanzamiento es realmente importante. Pero la etiqueta de vista previa v0.7 es honesta. Hay verdaderas asperezas.
Todavía no existe ningún subcomando gradle. Cuando el agente necesita agregar un complemento, modificar una dependencia o cambiar un tipo de compilación, debe editar los archivos build.gradle.kts directamente. El agente puede hacer esto; no siempre es bueno en eso. Un comando gradle add-plugin o gradle add-dependency cerraría una de las mayores brechas restantes.
La biblioteca de habilidades es pequeña. Seis habilidades en el lanzamiento son un punto de partida, no un sistema terminado. La habilidad de migración de XML a Compose es excelente; la habilidad Google Play Billing está bien; los demás aún no los he usado en producción. La biblioteca necesita crecer hasta alcanzar quizás cuarenta o cincuenta habilidades antes de cubrir la superficie real de las tareas comunes de Android.
La integración del emulador es buena pero no infalible. Me congelé fuertemente en tres horas de uso. Eso no es un desastre, pero aún no se encuentra en el nivel de confiabilidad en el que confiaría para que funcione sin supervisión durante la noche en una tubería de CI.
El índice de documentación cubre desarrollador.android.com, documentos de Firebase y documentos de Kotlin. Aún no cubre las especificaciones de Material Design, las notas de la versión de AndroidX ni la referencia a los elementos componibles de Jetpack de manera profunda. Esos vendrán. Por ahora, el agente a veces encontrará una consulta de documentos que no devuelve nada útil y tendrá que recurrir a sus datos de entrenamiento.
Ninguno de estos son bloqueadores. Todos ellos son el tipo de problemas que se solucionan en los próximos tres a seis ciclos de lanzamiento. Apuesto a que Google enviará la versión 1.0 de Google I/O 2026 con la mayoría de estas brechas cerradas.
Qué hacer esta semana
Si creas aplicaciones Android y estás leyendo esto, esto es lo que haría esta semana.
Instale la CLI. Tarda cinco minutos. Ejecute android init y permita que instale habilidades en cualquier agente que ya utilice. Pruebe android create en un proyecto desechable: tenga una idea de lo rápido que puede ser el arranque del proyecto cuando el asistente ya no está.
Luego elige una tarea real que hayas estado evitando. Una migración de redacción. Una actualización de Navigation 3. Una limpieza del R8. Cualquier cosa donde el trabajo sea mayoritariamente mecánico pero tedioso. Entrégaselo a su agente con la CLI instalada y observe lo que sucede. La primera vez que un agente realiza con éxito una tarea Android real de principio a fin, algo hace clic en su forma de pensar sobre el resto del trabajo que tiene pendiente.
Luego comience a escribir habilidades para su propio equipo. Elija un patrón arquitectónico que su equipo aplique (sus convenciones DI, su configuración de pruebas, su enfoque de manejo de errores) y escriba una habilidad que le enseñe a un agente a seguirla. Déjalo en tu repositorio. Deja que tus compañeros de equipo android init se opongan. Le habrá dado a su equipo una actualización de la memoria institucional que se agrava cada vez que alguien usa un agente en el código base.
Preguntas frecuentes
¿El Android CLI es gratuito?
Sí. Android CLI es una descarga gratuita desde d.android.com/tools/agents y se envía bajo la misma licencia abierta que el resto de las herramientas de la plataforma Android. En este momento no existe ningún nivel pago ni licencia empresarial.
¿Android CLI funciona con Claude Code?
Sí. Claude Code es uno de los 37 destinos de agentes admitidos. Después de instalar la CLI, ejecute android init --agent=claude-code para instalar las habilidades oficiales en su directorio de habilidades Claude Code.
¿Todavía necesito Android Studio si tengo la CLI?
Para la mayoría de los flujos de trabajo controlados por agentes, no. Aún querrá Android Studio para la depuración visual, el trabajo del generador de perfiles y la inspección de diseños complejos. Pero la creación diaria de proyectos, la gestión de dependencias, el control del emulador y las pruebas de la interfaz de usuario ahora pueden realizarse completamente desde la terminal.
¿En qué se diferencia Android CLI de adb?
adb es un puente de depuración de dispositivos de bajo nivel. Android CLI es una herramienta de flujo de trabajo de nivel superior que incluye adb, sdkmanager, avdmanager, partes de Gradle y el índice de documentación en una única interfaz fácil de usar para los agentes. La CLI utiliza adb internamente para algunas operaciones.
¿Qué hace realmente android init?
Escanea su directorio de inicio en busca de agentes de codificación instalados y luego coloca las habilidades oficiales Android en el directorio de habilidades de cada agente. Esto enseña a todos los agentes de su máquina cómo utilizar la CLI. Pase --agent=<name> para limitar la instalación a un único agente.
La orden aburrida que me hizo cambiar de opinión
De vuelta a donde comencé. android create. Plantilla de actividad vacía. Once segundos.
Sería fácil mirar esa orden y encogerse de hombros. El andamiaje del proyecto no es la parte difícil del desarrollo de Android. Cualquiera puede desarrollar un proyecto. Lo difícil es todo lo que viene después.
Pero la razón por la que ese comando se me quedó grabado (la razón por la que estoy sentado aquí escribiendo tres mil palabras sobre una herramienta de desarrollo un martes) es que me dijo lo que Google había decidido. Han decidido que la fricción al comenzar las cosas es importante. Han decidido que el ecosistema de agentes importa más que la dependencia de los agentes. Han decidido que la próxima generación de desarrolladores de Android dedicará su atención a qué construir, no a cómo iniciar su construcción.
Esa es una apuesta por un tipo de desarrollador diferente al para el que se creó Android Studio. Es una apuesta que estoy feliz de aceptar.
La pregunta para usted es de qué lado de esa apuesta quiere estar. Pasa los cinco minutos. Instale la CLI. Ejecute una tarea real a través del agente de su elección. Vea cómo se sienten once segundos cuando el mago se ha ido. Luego pregúntese: ¿qué más en su flujo de trabajo ha sido un impuesto que olvidó que estaba pagando?
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
