El ciclo anual de Android

Android no publica cuando le apetece: sigue un reloj bastante regular, y ese reloj es información accionable. Marca cuándo aparece el primer código con el que puedes probar, cuándo la superficie de APIs se congela y deja de moverse bajo tus pies, cuándo llega la versión definitiva a los dispositivos y, sobre todo, cuándo la tienda deja de aceptar tu app si no has hecho los deberes. La mayoría de los equipos ignora ese calendario durante once meses y lo descubre de golpe cuando llega un correo de Play con un plazo. Los que lo conocen hacen exactamente el mismo trabajo, pero repartido, sin urgencias y con margen para reaccionar si algo se rompe. La diferencia entre unos y otros no es esfuerzo: es haber puesto cuatro fechas en el calendario.

El calendario de una versión

Conviene empezar por lo que ese calendario no es: una hoja de ruta de funcionalidades para el usuario. Lo que a ti te importa de cada versión no son las novedades que se anuncian en el escenario, sino la lista de cambios de comportamiento y el momento exacto en que la superficie deja de moverse.

Una versión mayor de Android tarda alrededor de seis meses desde que se puede tocar hasta que llega a los dispositivos, y ese trayecto tiene hitos con nombre propio. Primero llegan las previews para desarrolladores, código temprano donde las APIs todavía cambian de nombre y desaparecen sin aviso: sirven para explorar y opinar, no para migrar. Después vienen las betas, ya instalables por usuarios voluntarios en dispositivos de referencia. En medio de ellas cae el hito clave, la estabilidad de plataforma: a partir de ese momento la superficie de APIs, los comportamientos condicionados por targetSdk y las listas de restricciones quedan congelados. Y unas semanas después llega la publicación en AOSP y en los dispositivos.

flowchart LR
P1[Previews de desarrollador]
B1[Betas publicas]
ST[Estabilidad de plataforma]
RE[Publicacion mayor]
MI[Entrega menor de fin de ano]
P1 --> B1 --> ST --> RE --> MI
style ST fill:#f9e2af,color:#11111b
style RE fill:#a6e3a1,color:#11111b
style MI fill:#89b4fa,color:#11111b

Acceder a cualquiera de esas fases no requiere hardware especial. Las imágenes de sistema de las betas están en el gestor del SDK y se instalan en un emulador en minutos, que es la vía razonable para probar sin sacrificar tu teléfono personal. Los dispositivos de referencia pueden inscribirse en el programa de betas y recibir las actualizaciones por aire, y también existe la vía de grabar la imagen a mano si necesitas una versión concreta.

# Listar las imagenes de sistema disponibles, previews incluidas
sdkmanager --list | grep system-images

# Crear un emulador con la version en preparacion
avdmanager create avd -n beta -k "system-images;android-37;google_apis;arm64-v8a"

Merece la pena subrayar qué congela exactamente ese hito y qué no. Congela la superficie de APIs oficiales, los comportamientos condicionados por targetSdk, las listas de interfaces internas restringidas y los formatos de los ficheros del sistema con los que interactúas. No congela el rendimiento, ni los errores de implementación, ni la interfaz del propio sistema, que siguen puliéndose hasta el final. Traducido a tu trabajo: después de la estabilidad puedes fiarte de que lo que compila hoy compilará el día de la publicación, pero no de que una medición de rendimiento tomada sobre una beta se parezca a la definitiva.

El hito de estabilidad es el que deberías tener marcado, porque cambia la naturaleza del trabajo. Antes de él, probar tu app contra la versión nueva tiene un valor limitado: lo que arregles hoy puede volver a romperse mañana porque la API cambió. Después de él, cualquier fallo que encuentres es un fallo real y definitivo, y tienes semanas de margen para corregirlo antes de que ningún usuario lo sufra. Ese periodo, entre la estabilidad y la publicación, es la ventana de máxima rentabilidad de todo el año para probar.

Hay una tentación que conviene nombrar para evitarla: adoptar en producción una API que aún está en preview. El coste no es el riesgo de que cambie de firma, que también, sino que compilar contra una versión no estable te ata a un canal de herramientas en preparación y contamina el proyecto entero durante meses por una funcionalidad que podrías haber esperado. La disciplina sana es explorar las novedades en una rama aparte y traerlas al tronco cuando la superficie se congela.

Dos entregas al año

Ese calendario, además, ha dejado de ser el que aprendiste si llevas tiempo en esto.

Durante quince años el reloj fue anual y sencillo. Eso cambió en dos pasos. Primero, la publicación mayor se adelantó al segundo trimestre: Android 16 salió en junio de 2025 y Android 17 en junio de 2026, ambas varios meses antes de lo que dictaba la costumbre. Segundo, apareció una entrega menor a final de año con APIs propias, que estrenó en diciembre de 2025 el primer nivel de API fraccionario de la historia de la plataforma, el 36.1.

Ese adelanto tiene una consecuencia de calendario que sorprende la primera vez. Como la publicación cae en junio y el plazo de la tienda cae a finales de agosto del año siguiente, el margen real para adoptar una versión mayor es de catorce meses, no de doce. Es más holgado de lo que la gente supone, y desmiente la idea de que la plataforma va demasiado rápido: lo que va rápido es la llegada de APIs nuevas, no la obligación de adoptarlas.

La motivación es directa: alinear la llegada de APIs nuevas con el momento en que los fabricantes lanzan sus dispositivos, y dar a las funcionalidades una segunda ventana anual en lugar de esperar doce meses. Para ti la consecuencia es doble. Por un lado hay dos momentos al año en que aparece superficie nueva, no uno. Por otro —y esto es lo que evita el pánico— solo la entrega mayor arrastra cambios de comportamiento condicionados por targetSdk, que es lo que puede romperte la app. La entrega menor suma APIs; la mayor cambia reglas.

Las obligaciones de Google Play

Hasta aquí el reloj de la plataforma, que es informativo. El de la tienda es distinto porque es vinculante.

La tienda no te obliga a usar lo último, pero sí a no quedarte demasiado atrás. La regla estable es que cada 31 de agosto sube el suelo, y el suelo apunta a la versión mayor publicada aproximadamente un año antes. Conviene distinguir dos exigencias que se confunden: la que afecta a publicar y la que afecta a seguir siendo instalable.

Saber en qué situación estás no requiere entrar en la consola: el valor declarado se puede leer directamente del artefacto que has publicado, lo que permite además comprobarlo de forma automática en la integración continua y fallar la compilación si alguien lo baja por descuido.

# Leer los tres numeros de un APK ya construido
aapt2 dump badging app-release.apk | grep -E "sdkVersion|targetSdkVersion"

# Lo mismo para un Android App Bundle
bundletool dump manifest --bundle app-release.aab | grep -i sdk

Hay excepciones por tipo de dispositivo que casi nadie recuerda y que importan si publicas fuera del móvil: los relojes y los coches van un escalón por detrás, y la televisión y las gafas dos. La lógica es que su base instalada se actualiza más despacio y sus ciclos de hardware son más largos.

Y conviene no reducir las obligaciones de la tienda al targetSdk, porque hay un segundo carril de requisitos que corre en paralelo con su propio calendario: el formato de publicación, la declaración de seguridad de los datos que se muestra en la ficha, las políticas de permisos sensibles, los requisitos de accesibilidad de la información y las verificaciones de identidad del desarrollador. Ninguno de ellos es técnicamente difícil, pero todos comparten la misma trampa: se anuncian con meses de antelación por correo y por la consola, y se descubren tarde porque nadie lee esos avisos. Tratarlos con el mismo ritmo trimestral que los cambios de plataforma es lo que evita la sorpresa.

Un ritmo sostenible

Sobre la prórroga conviene ser explícito, porque se malinterpreta con frecuencia. Existe, se solicita desde la consola y da unas semanas más, pero no es una exención ni se concede como un derecho: es un mecanismo pensado para equipos que ya están migrando y necesitan un margen operativo, no para quien no ha empezado. Planificar contando con ella es planificar con el peor colchón posible, porque llega justo cuando ya no tienes tiempo de reaccionar si algo sale mal.

Todo lo anterior cabe en cuatro citas al año, y con eso basta. En invierno, cuando aparecen las previews, se leen las notas y se anota lo que afecta al producto: una hora. En primavera, con la estabilidad de plataforma, se compila contra la nueva compileSdk, se instala la beta en un dispositivo y se recorren los flujos críticos: un día. En verano, tras la publicación, se sube el targetSdk con el procedimiento de la lección anterior —activar los cambios uno a uno, arreglar, firmar— muy por delante del plazo de agosto: dos o tres días. Y en otoño se revisa la entrega menor por si trae algo que te ahorre trabajo: otra hora. Cuatro citas, unos cuatro días de trabajo repartidos en doce meses.

Ese presupuesto cabe incluso en un proyecto de una sola persona, y ahí está la clave del asunto: el problema de mantenerse al día en Android nunca fue de volumen de trabajo, sino de concentrarlo todo en el peor momento posible.

Para que ese ritmo funcione hace falta una fuente de información que no dependa de tropezarte con la noticia. Conviene reducirla a lo mínimo imprescindible y desconfiar del ruido, porque el ecosistema Android genera una cantidad enorme de comentario secundario que repite lo mismo sin añadir nada.

Nada de eso exige seguir cuentas, ver conferencias enteras ni leer resúmenes de terceros. Con las notas oficiales de dos entregas al año y la consola de la tienda tienes cubierto el noventa por ciento de lo que necesitas saber, y el resto llega solo por el camino.

Ese reparto tiene una propiedad que la carrera de última hora no tiene: margen. Si en primavera descubres que un cambio de comportamiento te obliga a rehacer una pantalla, tienes meses. Si lo descubres en agosto con el plazo encima, tienes un fin de semana y una decisión mala. El coste total del año es el mismo; lo que cambia es si lo pagas con tiempo o con riesgo.

Y hay una última pieza que redondea el ritmo, aunque pertenezca al final del recorrido: los canales escalonados de la tienda. Publicar primero a un grupo interno, después a una fracción pequeña de producción y solo entonces al cien por cien convierte cualquier subida de targetSdk en algo reversible. Con eso, el peor caso de una migración deja de ser una crisis con usuarios afectados y pasa a ser un despliegue detenido a tiempo y una tarde de trabajo.