Migración a Android 16 y verificación anticipada de Android 17

En resumen: si envías una actualización con un targetSdkVersion inferior al que Google Play exige, se rechaza en el momento de la subida. Eso significa que no podrás publicar actualizaciones en la tienda en absoluto. No se trata de nuevas funcionalidades — es un requisito obligatorio para seguir distribuyendo actualizaciones a los usuarios existentes y mantener tu ficha en la tienda.

Google Play ha estado elevando el targetSdkVersion mínimo en un nivel cada 31 de agosto. Actualmente (desde agosto de 2025 en adelante), todas las actualizaciones por debajo de API 35 (Android 15) son rechazadas.

(Fuente: Requisitos de nivel de API objetivo de Google Play)

Según este patrón, la entrada en vigor de API 36 (Android 16) es más probable alrededor de agosto de 2026. Para completar el cumplimiento antes de que entre en vigor, este artículo delimita el trabajo partiendo de una fecha límite interna de junio de 2026. Android 17 ha alcanzado la estabilidad de plataforma en la Beta 3, así que ejecutar la verificación anticipada en una línea de trabajo paralela ahora significa que no estarás corriendo cuando llegue la versión final.

Orden de prioridad

Primero, pon en orden las herramientas

Ya sea que estés trabajando en el cumplimiento de Android 16 o en la verificación temprana de Android 17, los primeros bloqueos suelen ser problemas con las herramientas de compilación, no con las APIs del sistema operativo. Asegura las herramientas primero.

plugins {
    id("com.android.application") version "9.1.0" apply false
    id("org.jetbrains.kotlin.android") version "2.3.20" apply false
}

Fijar JDK 17 en CI, actualizar AGP y absorber las diferencias de R8 sirve para ambos propósitos — sienta las bases para Android 17 mientras completa el cumplimiento de Android 16.

Nota: Distribución real de versiones de Kotlin y coste de migración

El «Kotlin 2.3.20» de la tabla anterior es la línea base recomendada. En la práctica, muchos proyectos siguen en la línea 1.9.x. Los proyectos financieros, gubernamentales y de gran escala en Japón tienden a ser especialmente conservadores — la mentalidad de «está estable, así que no lo actualices» persiste durante mucho tiempo.

El gráfico a continuación es una estimación de principios de 2026 basada en datos públicos del ecosistema de JetBrains y observaciones de la comunidad.

(Valores estimados. Para datos exactos de cuota por versión, consulta la última Encuesta del ecosistema de desarrolladores de JetBrains)

Al actualizar de 1.9.x a 2.x, rara vez es solo una actualización de Kotlin — normalmente implica una actualización conjunta de Compose, Coroutines y AGP. Cambiar al compilador K2 puede modificar cierto comportamiento de inferencia de tipos, causando errores de compilación. «No necesitamos actualizar nuestra app 1.9.x que funciona bien ahora mismo» es una decisión perfectamente pragmática.

Cambios de comportamiento en Android 17 a los que adelantarse

Los cambios de comportamiento tienen mayor impacto en las apps existentes que las nuevas funcionalidades. Concéntrate primero en los cambios que afectan a todas las apps.

Prioridad de pruebas para soporte simultáneo de Android 16 y 17

Cuando se ejecutan en paralelo el cumplimiento de Android 16 y la verificación temprana de Android 17, es fácil perder de vista qué debe probarse en cada entorno. La siguiente tabla define los elementos requeridos/prioritarios por área de prueba — úsala como punto de control de QA para confirmar cuándo cada área puede considerarse completada.

Riesgos específicos de apps empresariales japonesas

Estos puntos rara vez se cubren en artículos generales de migración de Android de fuentes internacionales, pero las apps financieras, gubernamentales y de plataformas con membresía en Japón tienen sus propios problemas específicos. Para proyectos donde la prioridad es verificar que los flujos clave existentes — inicio de sesión, pagos, notificaciones — no se rompan en lugar de adoptar nuevas funcionalidades de Android 16/17 (cambios en canales de notificación, revisiones del modelo de permisos, nuevos componentes de Compose, etc.), revisa primero los elementos a continuación como lista de verificación.

Orden de acción recomendado

1. Finalizar el plan de lanzamiento asumiendo que la actualización de targetSdkVersion 36 (Android 16) se publica para junio de 2026
2. Alinear las herramientas: Android Studio, AGP, Kotlin, JDK
3. Ejecutar primero las pruebas de flujos clave del usuario y regresión para Android 16
4. En paralelo, crear una rama dedicada para Android 17 e iniciar una línea de verificación con emuladores y dispositivos reales
5. Abordar los cambios de comportamiento en orden: seguridad, multimedia, conectividad
6. Ejecutar un pipeline de CI separado con targetSdk 37