Qué ha cambiado
Google utilizó una publicación del Android Developers Blog, publicada el 6 de agosto de 2026 y firmada por Jose Alcérreca, de Android Developer Relations, para explicar por qué su proyecto oficial Android Skills es deliberadamente pequeño y temporal. El equipo había lanzado las habilidades oficiales en abril y ahora aclara cómo decide qué habilidades merecen existir.
La idea central es sencilla: Google no quiere que los desarrolladores instalen una gran pila de archivos de instrucciones genéricas. Según la compañía, las habilidades oficiales se consideran cuando existe una brecha verificable de conocimiento en los modelos actuales de vanguardia, especialmente en APIs y flujos de Android que avanzan más rápido que los ciclos de entrenamiento de los modelos.
Esto no es tanto un lanzamiento de producto como una actualización metodológica para el desarrollo Android asistido por IA. Google está diciendo a los equipos que traten las habilidades como activos de ingeniería específicos: útiles cuando cierran una brecha medible, costosos cuando solo repiten conocimiento que el modelo ya tiene.
Por qué el conjunto oficial sigue siendo pequeño
Google afirma que hasta ahora ha publicado alrededor de 20 Android Skills oficiales. Los ejemplos que cita son deliberadamente concretos: AGP 9, Navigation 3, APIs avanzadas de Camera y Perfetto SQL. La documentación pública de Android Skills añade flujos relacionados, como migrar diseños XML a Compose, adaptar interfaces al modo edge-to-edge y auditar la configuración de R8.
La razón de esa prudencia es el coste de contexto. Según la publicación, cada habilidad instalada añade entre 100 y 200 tokens al contexto base de cada tarea, y una habilidad activada puede añadir mucho más. En la práctica, las habilidades innecesarias pueden hacer que las sesiones con agentes sean más lentas, más caras y menos enfocadas.
El repositorio público de Android Skills expresa la misma filosofía en términos operativos: el proyecto se centra en flujos donde las evaluaciones muestran que los modelos de lenguaje rinden peor, y no prioriza áreas ya consolidadas donde los modelos suelen ser competentes, como las recomendaciones básicas de Jetpack Compose.
Las habilidades se prueban como software
Google dice que cada habilidad se prueba antes de publicarse con evaluaciones que deberían pasar cuando la habilidad está activa y fallar cuando no lo está. La compañía compara ese papel con el de las pruebas de integración en el código, una analogía útil para los equipos que crean sus propias instrucciones para agentes.
Como mínimo, Google afirma que prueba las habilidades en Android Studio con el último modelo Gemini Flash. Dependiendo de la habilidad, también puede comprobar Gemini Pro, Antigravity y sistemas de terceros. Eso no significa que todos los agentes se comporten igual, pero sí muestra que Google intenta basar las habilidades oficiales en evidencia y no tratarlas como simples fragmentos estáticos de documentación.
La compañía también explica por qué no acepta pull requests directas para nuevas habilidades oficiales: su marco de evaluación depende de infraestructura interna que no puede publicar como código abierto. En su lugar, Google pide que los desarrolladores reporten errores, optimizaciones o solicitudes de nuevas habilidades mediante issues en GitHub.
La documentación sigue importando
Uno de los puntos más prácticos de la publicación es que los desarrolladores Android no deberían usar las habilidades como sustituto de la documentación oficial. Google recomienda Android Knowledge Base y el comando de documentación de Android CLI como una forma más eficiente de dar a los agentes acceso a la documentación de Android, especialmente cuando el objetivo es una base amplia sobre APIs y no un flujo especializado.
La documentación pública dice que Android Skills puede instalarse con Android CLI y usarse con agentes o entornos de desarrollo compatibles con el formato abierto de agent skills. También señala que los equipos pueden crear sus propias habilidades para flujos internos, siempre que empaqueten las instrucciones con claridad y las coloquen donde los agentes compatibles puedan descubrirlas.
Para los equipos Android, la conclusión es separar tres capas: documentación oficial para la verdad amplia sobre APIs, habilidades oficiales para brechas rápidas en flujos de Android e instrucciones internas para arquitectura o prácticas de revisión propias de la empresa.
El objetivo es la deprecación
La parte más interesante de la explicación de Google es el estado final que plantea. A medida que modelos más capaces incorporen APIs y patrones recientes de Android, Google espera que muchas habilidades queden obsoletas. El equipo afirma que vuelve a ejecutar evaluaciones cuando aparecen nuevos modelos y, si un modelo puede aprobar sin una habilidad, esa habilidad puede retirarse tras un periodo de transición.
Es una disciplina útil para cualquier equipo que use agentes de IA. Las instrucciones para agentes no deberían convertirse por defecto en ruido permanente. Necesitan responsables, pruebas y una vía de retirada.
Google también advierte que conviene ser selectivo con las habilidades de la comunidad. La publicación apunta a ejemplos reputados de la comunidad Android, pero recomienda no instalar a ciegas grandes colecciones que podrían no estar probadas, haber sido generadas por IA, contener sesgos o incluso incluir instrucciones maliciosas.
Qué deben vigilar los desarrolladores
Para quienes usan herramientas de IA en proyectos Android, el impacto inmediato es práctico más que espectacular. Instalar todas las habilidades disponibles probablemente no sea el punto de partida adecuado. Es mejor identificar fallos repetidos del agente, añadir la instrucción mínima que los corrige y volver a comprobar periódicamente si sigue siendo necesaria.
Para los equipos de plataforma, el enfoque de Google indica que el soporte para agentes ya forma parte de la relación con desarrolladores. La documentación no se escribe solo para humanos que navegan una web; parte de ella ahora debe empaquetarse, evaluarse y retirarse para herramientas de IA que actúan dentro de bases de código reales.
La noticia confirmada es concreta: Google ha explicado cómo elige, evalúa y termina retirando Android Skills oficiales. La implicación más amplia es que el soporte de calidad para programación con IA dependerá menos de enormes bibliotecas de prompts y más de instrucciones medidas, basadas en fuentes y capaces de desaparecer cuando el modelo ya no las necesite.