Nivel de API objetivo 36 en Google Play: prórroga al 1/11/2026 y solución en Expo, Flutter y React Native

El requisito de nivel de API objetivo 36 de Google Play implica que una versión compilada para algo inferior a Android 16 no se puede publicar. En octubre de 2026, Play rechaza toda app nueva y toda actualización que apunte a un nivel más bajo, a menudo con el mensaje Target SDK of artifact is too low. Las apps que recibieron un aviso de política podían pedir más tiempo, pero la prórroga termina el 1 de noviembre de 2026. Esta guía explica qué te da todavía la prórroga, cómo llevar Expo, Flutter y React Native a la API 36 y qué suele romperse cuando lo haces.

¿Qué bloquea realmente el requisito de nivel de API objetivo 36?

Bloquea los envíos. Desde el 31 de agosto de 2026 no puedes subir una app de teléfono nueva ni una actualización a menos que apunte a la API 36. Las apps ya publicadas que apuntan a la API 35 o superior siguen totalmente disponibles, también para usuarios nuevos.

Según los requisitos de nivel de API objetivo de Google, "las apps nuevas y las actualizaciones de apps deben apuntar a Android 16 (nivel de API 36) o superior para poder enviarse a Google Play". Los requisitos varían según el tipo de dispositivo, y la única excepción total son las apps permanentemente privadas destinadas a distribución interna en una sola organización.

Una app existente por debajo de esos niveles "solo estará disponible en dispositivos con una versión de Android igual o inferior al nivel de API objetivo de tu app". Quienes ya la instalaron la siguen usando como antes. Pero a alguien con un teléfono más reciente se le indica que la app "se creó para una versión anterior de Android".

¿Todavía puedes conseguir la prórroga antes del 1 de noviembre de 2026?

Solo si Play envió a tu app un aviso de política y el formulario de solicitud sigue apareciendo en ella. Aun así, la prórroga dura como máximo hasta el 1 de noviembre de 2026, así que son unos pocos días extra para una corrección que ya está casi lista, no un plan nuevo.

Google indica que envía "un enlace al formulario de solicitud de prórroga a través de sus Notificaciones" a las apps afectadas, y que el formulario está "disponible en la página de detalles del aviso o problema en la página Estado de las políticas". Google no muestra el formulario a las apps que ya cumplen.

1. Abre Play Console y selecciona la app.
2. Busca en la Bandeja de entrada o en Notificaciones el mensaje sobre el nivel de API objetivo. Si está ahí, sigue su enlace.
3. Si no, ve a Estado de las políticas, abre el aviso o problema del nivel de API objetivo y busca el formulario de solicitud de prórroga en su página de detalles.
4. Rellena el formulario para cada app afectada. Cada app tiene su propio aviso.
5. Te concedan la prórroga o no, planifica subir una compilación con API 36 antes del 1 de noviembre de 2026. A partir de esa fecha, las actualizaciones necesitan la API 36.

¿Cómo subes Expo, Flutter y React Native a la API 36?

La vía más limpia es actualizar a una versión del framework que ya apunte a la API 36: Expo SDK 54, React Native 0.81 o Flutter 3.38. Si todavía no puedes actualizar, puedes subir el número a mano, pero entonces también tendrás que encargarte tú de los cambios de comportamiento de Android 16.

Expo. El changelog de SDK 54 dice que SDK 54 y React Native 0.81 "ahora apuntan a Android 16". Actualiza con npx expo install expo@^54.0.0 --fix, ejecuta npx expo-doctor@latest y, si usas Continuous Native Generation, "elimina los directorios android e ios si los generaste para una versión anterior del SDK". En SDK 53 puedes probar a poner targetSdkVersion: 36 mediante el plugin expo-build-properties, pero React Native 0.79 sigue gestionando el botón atrás con onBackPressed, así que lee la siguiente sección antes de publicarlo.

Flutter. Las notas de la versión Flutter 3.38 indican como valores por defecto flutter.compileSdkVersion (API 36) y flutter.targetSdkVersion (API 36), y "recomiendan encarecidamente usar en tus archivos de compilación las variables de nivel de API que proporciona el SDK de Flutter". La versión 3.38 también requiere como mínimo Java 17. Si tienes targetSdk = 35 fijado en el módulo de tu app, la actualización de Flutter no lo cambiará, así que revisa el archivo.

React Native bare. Pon compileSdkVersion y targetSdkVersion en 36 en android/build.gradle. En la 0.81 y posteriores, con eso casi has terminado. En versiones anteriores, añade también android:enableOnBackInvokedCallback="false" a <application> en AndroidManifest.xml. Sin ello, el botón atrás físico y el gesto atrás se saltan tu navegación en JavaScript.

¿Qué se rompe cuando una app empieza a apuntar a Android 16?

Lo que más se rompe es la navegación hacia atrás y los diseños para pantallas grandes. Con la API 36 como objetivo, Android deja de llamar a onBackPressed, no te permite excluirte del modo edge-to-edge e ignora los bloqueos de orientación y de redimensionamiento en pantallas de al menos 600dp de ancho.

Los cambios que más afectan a las apps multiplataforma, según los cambios de comportamiento de Android 16 de Google:

• Gesto atrás predictivo: "ya no se llama a onBackPressed ni se envía KeyEvent.KEYCODE_BACK". Configurar android:enableOnBackInvokedCallback="false" es una exclusión temporal.
• Edge-to-edge: windowOptOutEdgeToEdgeEnforcement está "obsoleto y desactivado", así que una cabecera o un botón inferior pueden acabar debajo de la barra de estado o de la barra de gestos.
• Pantallas grandes: en pantallas de 600dp o más, se ignoran screenOrientation, resizableActivity y los límites de relación de aspecto, lo que puede estirar los diseños solo verticales. Los juegos están exentos. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY es una exclusión temporal que "no se aplicará al apuntar al nivel de API 37".
• Texto: se ignora elegantTextHeight, lo que puede cambiar el interlineado en árabe, tailandés, tamil y otras escrituras.
• Sensores de salud: BODY_SENSORS se sustituye por permisos de salud granulares como READ_HEART_RATE.

¿Con qué se toparon otros desarrolladores al pasar a la API 36?

Los informes públicos hasta ahora muestran dos tipos de problemas: un comportamiento del botón atrás que cambia sin ningún error, y librerías que hacen que el nivel objetivo del bundle que recibe Play no coincida con lo que dicen los archivos del proyecto.

Audius (React Native 0.79). En la pull request #14635, el equipo de Audius cuenta que Google Play rechazó las dos subidas de la versión 1.5.186 de Android con Target SDK of artifact is too low. Pasaron compileSdk y targetSdk de 35 a 36, fijaron las build tools en 36.0.0 y añadieron android.suppressUnsupportedCompileSdk=36, porque "RN 0.79 fija AGP 8.8". También configuraron enableOnBackInvokedCallback="false", ya que sin ello el botón atrás "se saltaría React Navigation". Una PR posterior eliminó esa exclusión tras pasar a React Native 0.81, que registra un OnBackPressedCallback por sí mismo.

Una app con Flutter 3.35.2. En el issue #174516 de Flutter, un desarrollador configuró targetSdk 36 en Gradle y en el manifiesto, pero Play Console seguía indicando "Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version". Eliminar la antigua librería com.google.android.play:core:1.10.3 provocó errores de R8 "Missing classes". Al corregirlos apareció "You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles". El bundle se aceptó finalmente después de añadir reglas keep de ProGuard, fijar minSdk de forma explícita y desactivar las divisiones por idioma, densidad y ABI, a costa de una descarga más pesada.

La lección común: cambiar el número en Gradle no termina el trabajo. Audius tuvo que corregir el comportamiento en tiempo de ejecución, y el desarrollador de Flutter tuvo que arreglar una dependencia que alteraba lo que Play leía del bundle. Comprueba el artefacto compilado y prueba en un dispositivo con Android 16, no solo el archivo de configuración.

¿Cómo compruebas una compilación con API 36 antes de subirla?

Lee el nivel objetivo directamente del bundle de release, luego sube el bundle a un canal de prueba interna o cerrada y prueba la navegación hacia atrás, los insets y un diseño para tablet en Android 16. Un rechazo o un fallo en producción cuesta mucho más tiempo que estas comprobaciones.

Ejemplo práctico: una app con Expo SDK 53 que apunta a la API 35 y necesita una actualización más.

1. Ejecuta npx expo install expo@^54.0.0 --fix, luego npx expo-doctor@latest, y corrige lo que indique.
2. Si el proyecto usa Continuous Native Generation, elimina las carpetas android e ios antiguas y vuelve a compilar. Si no, aplica a mano los cambios nativos de la actualización.
3. Compila el AAB de release, por ejemplo con eas build -p android --profile production.
4. Confirma el objetivo con bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. Debería mostrar 36.
5. Súbelo a prueba interna. En un teléfono con Android 16, pulsa atrás en cada pantalla anidada, comprueba que las cabeceras y los botones inferiores no quedan ocultos bajo las barras del sistema y gira una tablet o un emulador redimensionable.
6. Promuévelo a producción con unas notas de la versión que mencionen las correcciones para Android 16.

Para agilizar las pruebas, usa la configuración de testers de nuestra guía de pruebas cerradas en Google Play y toma ideas para el texto de la actualización de nuestros ejemplos de notas de la versión. Si prefieres delegar la publicación, nuestro servicio de envío a App Store cubre Play Console y App Store Connect por $599 para ambas tiendas. Las tarifas de las cuentas de desarrollador van aparte.