Actualizar a API 36 en Flutter: lo que se rompe solo en release
Google Play ya solo acepta actualizaciones que apunten a Android 16 (API 36). Un desarrollador detalla en qué se le fueron dos días con tres apps Flutter y qué falla únicamente en release.
Desde el 31 de agosto de 2026 Google Play rechaza cualquier actualización de una app existente que no apunte a Android 16, API 36. No solo publicaciones nuevas: cualquier update, incluido el parche de una línea para una app con cien mil instalaciones. Hay una prórroga hasta el 1 de noviembre que compra seis semanas y no cambia el trabajo. Un desarrollador ha contado lo que le costó hacerlo con tres apps Flutter propias —una de horarios de oración, un SaaS para una joyería y un juego de puzles— y la conclusión es que el número del SDK era lo de menos.
Cambiar los dos valores de build.gradle.kts llevó un minuto. Todo lo que vino después le llevó dos días.
Lo que solo falla en release
El primer bloqueo es el que le empujó a escribir. Las notificaciones programadas funcionaban en debug y en release no se disparaban: sin crash, sin traza en el log, sin nada. La app parecía correcta y la gente simplemente dejaba de recibir avisos.
La causa era R8. flutter_local_notifications serializa los datos de las notificaciones programadas con Gson, y Gson necesita información de tipos genéricos en tiempo de ejecución. R8 la eliminaba, zonedSchedule lanzaba un RuntimeException por parámetro de tipo ausente dentro del plugin, y su propio manejo de estado se comía la excepción. Las notificaciones inmediatas seguían funcionando porque show() no pasa por Gson, y esa diferencia es la que volvía el fallo tan difícil de leer.
La solución son tres reglas keep en proguard-rules.pro: las firmas, el paquete del plugin y las clases que extienden TypeToken. Desactivar la minificación también tapa el síntoma y es lo que recomiendan la mayoría de hilos de issues, pero con las reglas puestas y R8 activo el dex bajó de 14,8 MB a 2,0 MB y el APK de 60,2 MB a 55,1 MB.
Plugins, Gradle y el formulario
Cualquier plugin sin mantenimiento desde 2023 es una moneda al aire con el Android Gradle Plugin actual. En dos casos reemplazó la librería en lugar de hacer fork, con el argumento de que un paquete sin commits en tres años volverá a romperse en el siguiente plazo, y hay un plazo cada año. Antes de empezar recomienda pasar flutter pub outdated y tratar los paquetes sin versiones recientes como la lista real de tareas.
Gradle, AGP y Kotlin tienen que subir juntos. Si no, los errores apuntan a otro sitio: un fallo de compilación de Kotlin que en realidad es de versión de AGP, o un daemon de Gradle que muere por un JDK distinto. Conviene fijar la versión de Java en gradle.properties para que la máquina local y el CI coincidan.
Queda la parte administrativa. La app consume SDK más nuevos, y esos SDK recogen más datos, así que el formulario de Data safety rellenado hace dos años ya no describe lo que hace el binario y Play lo comprueba. Los servicios en primer plano necesitan tipo declarado, las notificaciones permiso en tiempo de ejecución y las alarmas exactas otro aparte; en dispositivos Samsung y Xiaomi la optimización de batería seguirá matando el trabajo programado si no se maneja.
Termina con una recomendación práctica: subir primero a un canal de test cerrado y no directo a producción. Y una advertencia que vale para cualquier deadline anual de este tipo: el problema no es el número del SDK, es la arqueología en un proyecto que nadie ha tocado en dos años.
