Desde hoy, 31 de agosto de 2026, Google Play exige que cualquier app nueva o actualización apunte a Android 16 (API level 36) para poder subirse. Si no llegas a tiempo, tienes dos salidas: pedir una prórroga hasta el 1 de noviembre de 2026 desde la Play Console, o aceptar que tu app deje de aparecer a usuarios nuevos en dispositivos con versiones de Android superiores a tu targetSdk. La buena noticia para quien trabaja con Flutter: el motor no es el problema. El problema, casi siempre, está en tus plugins.

Qué ha pasado

Google mantiene desde hace años una política de targetSdk obligatorio, y este año el corte cae hoy. Según la documentación oficial de la Play Console, a partir del 31 de agosto de 2026 las apps nuevas y las actualizaciones deben apuntar a API level 36 (Android 16) o superior (con excepciones para Wear OS, Android TV y Android XR, que van un peldaño por detrás).

Dos matices que conviene tener claros:

  • No es un apagón. Las apps existentes que ya están publicadas siguen funcionando y los usuarios que ya las tienen instaladas no notan nada. Lo que se restringe es la visibilidad para usuarios nuevos en dispositivos con Android más reciente que tu targetSdk.
  • Hay prórroga. Si no llegas, puedes solicitar una extensión hasta el 1 de noviembre de 2026 desde la página de estado de políticas de la Play Console.

Y hay un cambio menos comentado que llegó en la actualización de políticas del 15 de julio: las integraciones de IA de terceros pasan a estar bajo la User Data policy. Si tu app envía datos del usuario a un LLM externo (una API de Anthropic, OpenAI, Google…), eres responsable de la divulgación, el consentimiento y el uso limitado de esos datos. No es parte del targetSdk, pero cae en la misma ventana y afecta a casi cualquier app con features de IA embebidas.

Qué implica de verdad para tu app Flutter

Aquí es donde el titular engaña. Subir targetSdk a 36 es una línea en build.gradle. El trabajo real son los behavior changes que se activan solo cuando apuntas a Android 16. Los tres que rompen cosas en apps Flutter reales:

1. Páginas de memoria de 16 KB (el que más duele). Desde noviembre de 2025 los binarios nativos deben soportar páginas de 16 KB en dispositivos de 64 bits. El motor de Flutter (libflutter.so) ya lo soporta desde hace varias versiones, así que tu código Dart está a salvo. El riesgo son los plugins con librerías .so propias: SDKs de vídeo, criptografía, PDF, ML on-device, lectores de códigos, wrappers de C/C++… Si alguno no se recompiló con NDK r28+ y AGP 8.5+, la Play Console te avisa o te bloquea, y en dispositivos con páginas de 16 KB la app puede llegar a crashear. Este es el punto que hay que auditar plugin a plugin, no de un vistazo.

2. Predictive back por defecto. Al apuntar a Android 16, las animaciones de "back" predictivo se activan solas y onBackPressed deja de llamarse: KEYCODE_BACK ya no se despacha. Si interceptas el botón atrás con lógica antigua (diálogos de confirmación, navegación custom), tienes que migrar a las APIs soportadas o, como parche temporal, poner android:enableOnBackInvokedCallback="false" en el manifest. En Flutter esto suele aparecer en apps con WillPopScope heredado o navegación anidada hecha a mano.

3. Edge-to-edge forzado. El modo edge-to-edge deja de ser opcional. Si tus pantallas no gestionan bien los insets, verás contenido bajo la barra de estado o la de navegación. En Flutter se resuelve con SafeArea y SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge), pero hay que revisarlo pantalla por pantalla: es el clásico bug que solo se ve en el dispositivo, no en el diseño.

Nuestra recomendación

No es blanco o negro. Depende de tu superficie de plugins nativos:

  • Si tu app es mayoritariamente Dart con pocos plugins nativos (o plugins mantenidos y al día): actualiza hoy. Bumpear targetSdk a 36, revisar back y edge-to-edge, pasar una batería de regresión y publicar es cuestión de horas, no de días. No hay motivo para pedir prórroga.

  • Si arrastras plugins nativos pesados o abandonados y no te da tiempo a auditar el 16 KB con garantías antes de que cierre la ventana: pide la prórroga hasta el 1 de noviembre y no fuerces un release arriesgado. Publicar una versión que crashea en la mitad de los dispositivos nuevos, solo por cumplir una fecha blanda, es peor que esperar seis semanas con la app actual intacta. Nosotros no subiríamos a producción una build de la que no controlamos el comportamiento nativo.

La fecha importa, pero no es una emergencia que justifique romper cosas. Es un targetSdk anual: el mismo baile que el año que viene con API 37. Merece la pena montar el pipeline para que deje de ser un sprint de última hora.

Qué miramos nosotros en una auditoría de targetSdk

Cuando tocamos esto en una app en producción, el checklist es siempre el mismo:

  1. Inventario de librerías .so y verificación de alineación a 16 KB (Flutter 3.22+, NDK r28+, AGP 8.5.1+). Los sospechosos habituales son los plugins con backend en C/C++.
  2. Búsqueda de interceptaciones de back (WillPopScope, onBackPressed, PopScope) y migración al modelo predictivo.
  3. Repaso de insets pantalla a pantalla con edge-to-edge activo, en dispositivo real y con gesto de navegación.
  4. Auditoría de la divulgación de datos si hay IA de terceros: qué sale del dispositivo, hacia qué proveedor y con qué consentimiento, para cuadrar con la nueva User Data policy.

Como Google Developer Agency Partner de Flutter desde 2017, es exactamente el tipo de mantenimiento poco glamuroso que evita que un cliente desaparezca del store sin enterarse. Si ya vas con Flutter 3.47, el motor te acompaña; el trabajo está en el borde.

¿Dudas sobre si tu app llega limpia a API 36 o si te conviene pedir la prórroga? Cuéntanos qué stack tienes y te decimos en qué punto estás. Y si vienes de una versión antigua, primero conviene mirar cuándo actualizar a Flutter estable sin romper nada.