Google Play exige Android 16 (API 36) el 31 de agosto: guía de migración para apps Flutter

Google Play y Android 16 (API 36): la fecha que no puedes ignorar

Si publicas o mantienes una app en Google Play, tienes una fecha marcada en rojo: 31 de agosto de 2026. A partir de ese día, cualquier app nueva o cualquier actualización que subas a Play tendrá que apuntar (target) a Android 16 (API level 36) o superior. No es opcional y no es solo un número en build.gradle: al subir el targetSdk a 36 tu app hereda un conjunto de cambios de comportamiento que pueden romper la UI o el arranque si no los preparas.

Esta es la guía técnica de cómo lo abordamos nosotros: qué implica de verdad, qué se rompe primero, para quién es urgente y para quién no, y por qué el "opt-out" que verás por ahí es deuda técnica con fecha de caducidad.

Qué exige Google exactamente

Conviene separar dos cosas que se confunden a menudo:

• Apps nuevas y actualizaciones: desde el 31 de agosto de 2026 deben tener targetSdkVersion = 36 (Android 16) o superior para poder enviarse a Google Play.
• Apps ya publicadas que no actualizas: deben apuntar al menos a API 35 (Android 15) para seguir siendo visibles a usuarios nuevos en dispositivos con una versión de Android superior a tu target. Si no llegas, los usuarios que ya la tienen instalada la conservan, pero los nuevos dejan de verla en la búsqueda.
• Prórroga: se puede solicitar una extensión hasta el 1 de noviembre de 2026 desde Play Console, pero es un parche para ganar semanas, no una estrategia.

El matiz importante: subir el targetSdk es una declaración de compatibilidad. Le estás diciendo a Android "he probado mi app contra los comportamientos de esta versión". Por eso el trabajo real no es cambiar el número, es validar los cambios de comportamiento que se activan con él.

El cambio que romperá más apps: edge-to-edge obligatorio

Este es, con diferencia, el que más incidencias genera. En Android 15 (API 35) el modo edge-to-edge ya venía activado, pero podías desactivarlo con R.attr#windowOptOutEdgeToEdgeEnforcement. En apps que apuntan a Android 16, ese atributo queda deprecado y deshabilitado: ya no puedes optar por salir. Tu app dibuja obligatoriamente por detrás de la barra de estado y de la barra de navegación.

Traducción práctica: botones, cabeceras y textos que asumían que el sistema les "reservaba" espacio pueden quedar tapados por las barras del sistema.

La buena noticia para quien trabaja con Flutter es que el framework se adelantó. Desde Flutter 3.27, el SystemUiMode por defecto ya es edge-to-edge en Android 15+. Si tu app está en una versión reciente de Flutter, probablemente ya estás dibujando edge-to-edge y solo tienes que verificar que gestionas bien los insets:

Scaffold(
  body: SafeArea(
    // SafeArea aplica el padding de las barras del sistema
    child: MiContenido(),
  ),
)

Cuando necesitas control fino (por ejemplo, un fondo que sí debe llegar al borde pero con contenido que no), trabaja directamente con los insets:

final padding = MediaQuery.of(context).padding;
Padding(
  padding: EdgeInsets.only(top: padding.top, bottom: padding.bottom),
  child: MiContenido(),
);

Y para el contraste de los iconos de las barras (que ahora se ven sobre tu contenido), define explícitamente el estilo:

SystemChrome.setSystemUIOverlayStyle(
  const SystemUiOverlayStyle(
    statusBarColor: Colors.transparent,
    statusBarIconBrightness: Brightness.dark,
    systemNavigationBarColor: Colors.transparent,
  ),
);

Cuándo NO conviene forzar el opt-out temporal: verás guías que recomiendan crear un res/values-35/styles.xml con windowOptOutEdgeToEdgeEnforcement para "ganar tiempo". Sirve como red de seguridad puntual para evitar crashes en API 35, pero no funciona cuando apuntas a API 36 y Android ya ha anunciado que retirará el mecanismo. Si lo usas, anótalo como deuda técnica con fecha, no como solución.

El segundo golpe silencioso: layouts adaptativos en pantallas grandes

Este cambio pasa desapercibido en el emulador de móvil y luego explota en tablets, plegables y Chromebooks. Para pantallas con ancho mínimo ≥ 600dp, Android 16 ignora las restricciones de orientación y de redimensionado que muchas apps daban por sentadas:

• android:screenOrientation (portrait, landscape y todas las variantes fijas)
• android:resizeableActivity="false"
• android:minAspectRatio / android:maxAspectRatio
• Activity.setRequestedOrientation()

Es decir: aunque tu app "solo funcione en vertical", en una tablet o un plegable ocupará toda la ventana y podrá rotar. Los síntomas típicos son layouts estirados diseñados solo para móvil, animaciones que quedan fuera de pantalla y pérdida de estado por recreaciones de la Activity.

Existe un opt-out temporal:

<application>
  <property
    android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
    android:value="true" />
</application>

Pero Google ya avisa de que no funcionará a partir de API 37. La respuesta correcta no es bloquear la orientación, es hacer la UI adaptativa de verdad con LayoutBuilder y breakpoints. Si tu producto tiene tracción en plegables o tablets, este es el trabajo que más valor aporta a medio plazo, y lo hemos tratado a fondo en nuestra guía de UI adaptativa para plegables y foldables.

Predictive back: revisa tu navegación

Con target 36, las animaciones de predictive back están activadas por defecto y onBackPressed() y KeyEvent.KEYCODE_BACK dejan de invocarse. Si interceptabas el botón de atrás a la vieja usanza (típico para "¿seguro que quieres salir?"), esa lógica deja de ejecutarse.

En Flutter esto significa migrar de WillPopScope a PopScope, que es la API alineada con el sistema de navegación predictiva:

PopScope(
  canPop: false,
  onPopInvokedWithResult: (didPop, result) {
    if (didPop) return;
    _mostrarDialogoDeSalida();
  },
  child: MiPantalla(),
);

Hay un opt-out temporal por manifest (android:enableOnBackInvokedCallback="false"), pero de nuevo: es un puente, no un destino.

HealthTech: permisos de salud más granulares

Si tu app lee ritmo cardíaco o datos de sensores corporales, ojo: en apps que apuntan a Android 16, BODY_SENSORS se sustituye por permisos granulares bajo android.permissions.health (por ejemplo READ_HEART_RATE, y READ_HEALTH_DATA_IN_BACKGROUND para segundo plano). Además, las apps móviles que usan estos permisos deben declarar una activity que muestre la política de privacidad; si no lo haces, el sistema revoca el permiso.

Es un cambio pequeño en líneas de código y grande en impacto para verticales de salud y wearables, donde un permiso revocado silenciosamente significa una funcionalidad rota en producción.

Otros cambios a tener en el radar

No todos aplican a todas las apps, pero conviene revisarlos según tu stack:

Cambio	A quién afecta	Acción
Edge-to-edge sin opt-out	Prácticamente todas	Gestionar insets (SafeArea/MediaQuery)
Orientación/resize ignorados en ≥600dp	Apps con soporte tablet/plegable	UI adaptativa real, no bloquear orientación
Predictive back por defecto	Apps que interceptan "atrás"	Migrar a PopScope / OnBackInvokedCallback
Permisos de salud granulares	HealthTech, wearables	Nuevos permisos + política de privacidad
Programación a tasa fija	Apps con tareas periódicas	Solo se recupera 1 ejecución perdida, no todas
Local Network Permission	Apps con mDNS/SSDP/sockets locales	Preparar NEARBY_WIFI_DEVICES (opt-in aún)
Safer Intents	Apps con intent-filter expuestos	Revisar matching estricto de intents

Cómo lo abordamos nosotros (y qué te recomendamos)

La tentación es cambiar targetSdk = 36, compileSdk = 36, compilar y subir. No lo hagas a ciegas. Este es el orden que seguimos en proyectos de mantenimiento:

1. Actualiza primero el SDK de Flutter a una versión ≥ 3.27 si aún no lo has hecho. Buena parte del trabajo de edge-to-edge ya viene resuelto y evitas reinventar workarounds.
2. Sube compileSdk a 36 antes que targetSdk. Compilar contra la nueva API sin cambiar el target te deja detectar deprecaciones sin activar todavía los cambios de comportamiento.
3. Activa targetSdk = 36 en una build interna y prueba en dispositivos reales, no solo en emulador: un móvil normal, un plegable/tablet (≥600dp) y, si aplica, un wearable.
4. Recorre a mano las pantallas críticas: onboarding, pantallas con barras superiores/inferiores custom, flujos con botón atrás, y cualquier pantalla que asuma orientación fija.
5. Automatiza la regresión visual en tu pipeline. Si ya tienes CI/CD, este es el momento de rentabilizarlo; lo contamos en nuestra guía de CI/CD para apps Flutter con GitHub Actions y en el enfoque de testing en Flutter.

¿Para quién es urgente y para quién no? Si tienes una release planificada antes de finales de agosto, o cualquier hotfix que necesites subir, es urgente: cualquier actualización posterior al 31 de agosto ya exige API 36, así que más vale llegar con la migración validada que descubrir el bloqueo al intentar publicar un fix crítico. Si tu app está congelada y no vas a subir cambios, técnicamente puedes esperar mientras apuntes al menos a API 35, pero estás acumulando trabajo y perdiendo visibilidad ante usuarios nuevos. Nosotros no recomendamos esperar: la migración es más barata hecha con calma que contra reloj junto a una incidencia en producción.

Un aviso honesto: apuntar a API 36 no es "un ticket". En apps grandes, con navegación custom, soporte de tablets y funcionalidad de salud, es un pequeño proyecto de compatibilidad que merece su propia rama, su QA en dispositivos reales y su ventana de release. Subestimarlo es la forma más habitual de acabar con una app fuera del store justo cuando necesitas publicar.

---

Llevamos desde 2011 construyendo y manteniendo apps Flutter en producción, con equipo senior in-house. Si tienes una app en Google Play y quieres llegar al 31 de agosto con la migración a Android 16 validada —sin sorpresas en plegables ni en producción—, hablemos.