effidevFlutter · Edge de Cloudflare · Optimización de costes en la nube

Si Google Play sigue rechazando tu app Flutter después del plazo de mayo de 2026: guía práctica para el requisito de tamaño de página de 16KB

Si Google Play sigue rechazando tu app Flutter después del plazo de mayo de 2026: guía práctica para el requisito de tamaño de página de 16KB

“Esto ya lo arreglé el año pasado, ¿por qué me lo rechazan otra vez?” Esa es la pregunta que no para de repetirse en las últimas semanas en las comunidades de desarrolladores Flutter y en los issue trackers. El requisito de tamaño de página de memoria de 16KB de Google Play entró en vigor originalmente el 1 de noviembre de 2025, con la posibilidad de solicitar una prórroga individual hasta el 31 de mayo de 2026. Hoy es 24 de julio de 2026, así que esa ventana de prórroga también se cerró hace casi dos meses. Y aun así, muchas apps siguen siendo rechazadas al subir una actualización. La razón es casi siempre la misma: el código propio de la app ya cumple el requisito, pero algún plugin nativo de terceros del que depende todavía no está alineado a 16KB.

Este no es otro resumen del anuncio: es una guía práctica para quien esté realmente atascado con este problema ahora mismo.

Resumen clave

  • Google Play exige alineación de página a 16KB para apps nuevas o actualizaciones que apunten a Android 15 (API 35) o superior e incluyan código nativo (archivos .so). Las apps escritas solo en Dart no se ven afectadas.
  • El plazo original era el 1 de noviembre de 2025, ampliable hasta el 31 de mayo de 2026 mediante una solicitud individual de prórroga. Pasada esa fecha, ya no hay margen: se aplica de inmediato.
  • El propio motor de Flutter (libflutter.so, libapp.so) soporta 16KB desde Flutter 3.32.8. El problema real está casi siempre en los archivos .so que empaquetan los plugins de terceros.
  • Puedes verificar la alineación tú mismo de antemano con zipalign, llvm-objdump o el App Bundle Explorer de Play Console.
  • Si no añades una comprobación de alineación al CI, este problema volverá a aparecer.

Por qué existe el requisito de tamaño de página de 16KB y a quién afecta

Tradicionalmente Android ha gestionado la memoria en unidades (páginas) de 4KB. A partir de Android 15, AOSP incorporó soporte para páginas de 16KB, y los dispositivos de gama alta más recientes (sobre todo los que tienen más RAM) cada vez más traen 16KB como valor por defecto. En su documentación oficial (developer.android.com/guide/practices/page-sizes), Google cita las siguientes mejoras de rendimiento a partir de pruebas internas, aunque la propia Google aclara que son “resultados preliminares y pueden variar en dispositivos reales”:

Con estas cifras como base, Google estableció que a partir del 1 de noviembre de 2025, las apps nuevas y las actualizaciones que apunten a Android 15 (API 35) o superior deben soportar tamaños de página de 16KB en dispositivos de 64 bits. Como se ha confirmado en varios hilos de la comunidad de desarrolladores desde entonces (incluido “Clarification on 16 KB page size extension” en la comunidad de desarrolladores de Google Play), solicitar una prórroga individual a través de Play Console permitía retrasar ese plazo hasta el 31 de mayo de 2026. En el momento de escribir esto (julio de 2026), esa ventana de prórroga también se ha cerrado, así que cualquier app que no haya resuelto el problema queda bloqueada de inmediato al subir el archivo.

Lo importante es tener claro que las apps Dart/Flutter puras, sin código nativo, no necesitan hacer nada. El propio blog oficial de Google indica explícitamente que “las apps sin código nativo no requieren cambios y ya son compatibles”. El problema real afecta a la inmensa mayoría de apps Flutter en producción, que incorporan plugins nativos con archivos .so para cámara, animaciones, bases de datos, mapas, SDKs de pago y más.

Cómo comprobar si tu app está afectada: diagnóstico en 3 pasos

Paso 1 — Extrae primero la lista de plugins nativos

Empieza identificando qué dependencias de pubspec.yaml probablemente incluyan código nativo. Los sospechosos habituales son cámara, bases de datos (backends nativos de sqlite, realm, isar), mapas (google_maps_flutter), animación (renderizadores nativos de rive, lottie), procesamiento de imágenes (flutter_image_compress), SDKs de pago/seguridad, reportadores de crashes (sentry_flutter, firebase_crashlytics), WebRTC e inferencia de ML (tflite, onnxruntime).

Paso 2 — Inspecciona directamente los archivos .so dentro del build

Con sospechas no basta: hay que abrir el artefacto de build real y comprobarlo.

# generamos primero un build de release
flutter build appbundle --release

# listamos los .so incluidos en el bundle
unzip -l build/app/outputs/bundle/release/app-release.aab | grep "\.so"

Puedes verificar directamente si cada .so está alineado a 16KB con llvm-objdump (ejemplo de ruta en macOS):

$ANDROID_HOME/ndk/<NDK_VERSION>/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump \
  -p path/to/librive_text.so | grep LOAD

Si la salida muestra align 2**14 (16384 bytes), todo está bien. Si muestra 2**13 (8192) o menos, es alineación de 4KB y es un problema. bundletool también es útil para revisar todo el AAB de una vez:

bundletool dump config --bundle=app-release.aab | grep alignment
# PAGE_ALIGNMENT_16K está bien, PAGE_ALIGNMENT_4K significa que aún no está corregido

Para un APK individual, usa el modo de verificación de zipalign.

$ANDROID_HOME/build-tools/35.0.0/zipalign -v -c -P 16 4 app-release.apk

Si usas Android Studio, la vía más rápida es File > Profile or Debug APK (o Build > Analyze APK) y revisar la columna Alignment dentro de la carpeta lib/arm64-v8a. El archivo con el icono de advertencia es el culpable.

Paso 3 — Validación previa antes de subir a Play Console

El App Bundle Explorer de Play Console marca automáticamente las librerías no alineadas a 16KB al subir un AAB. Los mensajes de rechazo que se repiten una y otra vez en casos reales tienen esta forma:

Como el mensaje indica el nombre exacto del archivo, solo hace falta rastrear de qué plugin proviene ese .so.

Matriz de compatibilidad de versiones Flutter / NDK / AGP

Componente Mínimo requerido Recomendado Notas
Flutter SDK 3.32.8+ Última estable (3.35 o superior) El propio motor soporta 16KB desde la 3.32.8. Comprueba tu versión actual con flutter doctor -v
Android NDK r27+ Serie r28 A partir de r28, la alineación de 16KB se compila por defecto. r27 requiere añadir manualmente un flag del linker
AGP (Android Gradle Plugin) 8.5.1+ Última 8.7.x o superior 8.3–8.5 generan alineación de 16KB, pero bundletool no hace zipalign automático del APK
Gradle 8.9+ La última compatible con tu versión de AGP Basado en la combinación compatible con AGP 8.5.1
Android SDK Build-Tools 35.0.0+ Última La opción zipalign -P 16 solo está disponible desde esta versión
compileSdk / targetSdk 35 35 o superior Corresponde al nivel de API de Android 15

Hay una trampa que conviene vigilar. A fecha de julio de 2026, el plugin de Gradle flutter_tools de Flutter usa por defecto la versión de NDK 27.0.12077973 (confirmado en el issue #175022 de flutter/flutter). r27 cumple técnicamente el mínimo, pero no compila con alineación de 16KB por defecto, así que para ir sobre seguro hay que añadir el flag del linker a mano o subir el NDK a la serie r28. Se especifica así en android/app/build.gradle (o .kts):

android {
    ndkVersion "28.2.13676358" // comprueba la página de descargas para obtener la última r28.x y sustitúyela aquí

    defaultConfig {
        externalNativeBuild {
            cmake {
                // si necesitas quedarte con r27, añade este flag
                arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
            }
        }
    }
}

Si tienes un proyecto legacy con AGP 8.0 o inferior, también necesitas esta línea en gradle.properties:

android.bundle.enableUncompressedNativeLibs=false

Hay otro bug que se reporta con frecuencia en la práctica. En ciertas combinaciones de Flutter 3.32.8/3.35.1 con AGP, subir minSdkVersion a 23 o más hace que aparezca una advertencia de 16KB en el App Bundle Explorer incluso en un proyecto recién generado (issue #173949 de flutter/flutter). Bajar minSdkVersion a 21 o menos hace desaparecer la advertencia, pero eso es un rodeo, no una solución de fondo; es preferible priorizar actualizar Flutter/AGP a sus últimas versiones estables.

Cuando te topas con un plugin de terceros sin corregir: casos reales y estrategias

La situación más frustrante es cuando tu propio código ya está arreglado, pero el proveedor de un plugin del que dependes todavía no ha recompilado su .so. Veamos dos casos reales que vale la pena revisar.

Caso 1 — Animaciones Rive. El paquete rive clásico (la serie 0.13.x) empaqueta librive_text.so compilado con alineación de 4KB, así que Play Console lo rechaza directamente. En el repositorio rive-app/rive-flutter esta petición lleva registrada más de un año, repetidamente, en los issues #458, #488, #524, #539, #547 y #553. La solución real no es aferrarse al paquete rive antiguo, sino migrar a su sucesor, rive_native. Desde la versión 0.0.3, el changelog de rive_native indica explícitamente “Android: support 16 KB page sizes”, en referencia al issue #479.

Caso 2 — SQLite. sqlite3_flutter_libs resolvió esto en la versión 0.5.25, con el changelog anunciando “Support 16KiB page sizes on Android 15”. Sin embargo, a día de hoy (0.6.0+eol) el propio paquete está deprecado, y su changelog indica que “sqlite3_flutter_libs ya no es necesario a partir de sqlite3 3.x”. Es decir, en proyectos antiguos, simplemente actualizar a las versiones actuales suele ser ya la solución.

De estos dos casos se desprende un orden práctico de actuación:

  1. Primero, intenta actualizar a la última versión. La mayoría de los paquetes populares ya han publicado una versión corregida o están trabajando en ello. Busca primero en el changelog las palabras clave “16KB”, “page size” o “alignment”.

  2. Usa dependency_overrides para forzar la versión de una dependencia transitiva concreta. Es útil cuando el paquete de nivel superior no se ha actualizado, pero el paquete de bindings nativos que hay dentro sí tiene una versión más nueva disponible.

    dependency_overrides:
  rive_native: ^0.0.5

  3. exclude de Gradle más especificar directamente el AAR más reciente. Si el proveedor ha publicado los nuevos .so como un artefacto Maven independiente, puedes excluir el aar antiguo que arrastra el plugin y añadir la versión nueva como dependencia directa.

    implementation("com.example:some-native-sdk:2.3.0") {
    exclude group: "com.example", module: "some-native-sdk-legacy"
}

  4. Sustituye tú mismo el .so mediante un source set jniLibs. Si has conseguido un binario recompilado a 16KB por la comunidad, o lo has recompilado tú con el NDK, añade un source set que tenga prioridad sobre el aar del proveedor.

    android {
    sourceSets {
        main {
            jniLibs.srcDirs += ["src/main/jniLibs16k"]
        }
    }
    packagingOptions {
        pickFirst "lib/arm64-v8a/librive_text.so"
    }
}

  5. Si nada de esto funciona, haz un fork. Si el plugin es de código abierto, hacer un fork del repositorio, subir solo la versión del NDK a r28, recompilar y apuntar pubspec.yaml a tu fork por git es una solución temporal razonable.

    dependencies:
  rive:
    git:
      url: https://github.com/<your-org>/rive-flutter.git
      ref: fix/16kb-alignment

  6. Como último recurso, evalúa una librería alternativa. Si no hay fecha prevista para que el proveedor lo solucione, cambiar a otro paquete con funcionalidad similar también es una opción (por ejemplo, considerar una alternativa basada en Lottie en lugar de una librería de animación desactualizada).

Conviene dejar algo claro: el “modo de compatibilidad 16KB hacia atrás” a nivel de dispositivo (adb shell setprop bionic.linker.16kb.app_compat.enabled true) está pensado para facilitar las pruebas durante el desarrollo, no es un mecanismo para pasar la revisión de Play Console. Es un ajuste del dispositivo del usuario, no una propiedad del build que distribuyes.

Añadir verificación automática de alineación a 16KB en el pipeline de CI

Arreglarlo una vez no es el final de la historia. Si se baja la versión de un plugin, o un nuevo miembro del equipo añade un SDK sin alinear, el problema reaparece. Verificar automáticamente la alineación en cada build de release en CI, haciendo fallar el pipeline antes de que llegue a Play Console, es la clave para evitar que se repita. Aquí tienes un ejemplo con GitHub Actions:

name: android-release-check

on:
  push:
    branches: [main]

jobs:
  check-16kb-alignment:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          channel: "stable"

      - name: Build App Bundle
        run: flutter build appbundle --release

      - name: Download bundletool
        run: |
          BUNDLETOOL_URL=$(curl -s https://api.github.com/repos/google/bundletool/releases/latest \
            | grep "browser_download_url.*jar" | cut -d '"' -f 4)
          curl -sL -o bundletool.jar "$BUNDLETOOL_URL"

      - name: Extract universal APK
        run: |
          java -jar bundletool.jar build-apks \
            --bundle=build/app/outputs/bundle/release/app-release.aab \
            --output=out.apks --mode=universal
          unzip -o out.apks -d out_apks

      - name: Verify 16KB page alignment
        run: |
          ZIPALIGN=$ANDROID_HOME/build-tools/35.0.0/zipalign
          $ZIPALIGN -v -c -P 16 4 out_apks/universal.apk || \
            (echo "::error::Fallo de alineación de página a 16KB — revisa tus archivos .so" && exit 1)

Si este paso falla, la propia salida de zipalign indica qué .so es el problema, así que puedes rastrear de inmediato ese nombre de archivo hasta el plugin responsable. Si trabajas en un equipo grande, hacer que Renovate o Dependabot abran automáticamente PRs de actualización para paquetes nativos que ya han dado problemas antes —rive_native, sqlite3, google_maps_flutter, sentry_flutter— también ayuda a evitar que esto se repita.

Checklist final

Si ahora mismo estás atascado con este problema, la causa casi nunca es tu propio código, sino una dependencia nativa de terceros desactualizada. Repasando el orden anterior paso a paso, normalmente se puede identificar la causa en menos de un día.