Respuesta rápida
Google Play exige que las apps que apuntan a Android 15 (nivel de API 35) o superior admitan páginas de memoria de 16 KB en dispositivos de 64 bits, y desde el 1 de febrero de 2027 no podrás publicar actualizaciones que no lo hagan. Una app escrita solo en Java o Kotlin, incluidas todas sus bibliotecas y SDK, ya cumple. Una app que empaqueta bibliotecas nativas .so falla hasta que cada una se recompile o se reemplace, preferiblemente con Android Gradle Plugin 8.5.1+ y NDK r28+, y hasta que el build pase dos comprobaciones distintas: cada segmento ELF LOAD alineado a 2**14 como mínimo, y el app bundle reportando PAGE_ALIGNMENT_16K. Actualizar tu framework no es una prueba; el artefacto sí lo es. Si resolver esta advertencia frenó una prueba cerrada (closed testing) que ya tenías en marcha, PrimeTestLab mantiene vivo el lado de los testers mientras tú recompilas.
La advertencia es corta, nombra como mucho un archivo, y llega cuando ya dabas el build por terminado. Por eso se repiten los mismos tres desvíos: se confía en una fecha que se movió, se actualiza un framework dando el trabajo por hecho, o se revisa un solo APK local sin mirar nunca el bundle a partir del cual construye Google. Este artículo está organizado como se resuelve el problema de verdad, es decir identificar, atribuir, reparar y probar, y todo lo que hay en él está vigente a 5 de agosto de 2026, verificado contra la guía de tamaños de página de Google el mismo día en que esa página se actualizó por última vez. Cuando la evidencia es el issue tracker de un mantenedor y no una nota de versión oficial, la página lo dice en la tarjeta en lugar de redondearlo a hecho.
El laboratorio de alineación
Doce instrumentos creados para este único error. Nada de esto necesita una cuenta, una subida ni una petición de red: cada herramienta corre en tu navegador con los valores que escribes.
Tabla de contenidos
Soluciónalo en tres pasos
Toda solución real de este error son los mismos tres movimientos en el mismo orden: identificar la biblioteca nativa que no está alineada, actualizar la dependencia que la entrega, y después verificar el artefacto que vas a subir. Saltar directo al paso dos es por lo que tantos desarrolladores actualizan un framework, recompilan y ven volver la advertencia sin cambios.
El requisito en sí es estrecho. La guía de tamaños de página de Google dice que las apps que apuntan a Android 15 (nivel de API 35) o superior deben admitir páginas de memoria de 16 KB en dispositivos de 64 bits, y que desde el 1 de febrero de 2027 no podrás publicar actualizaciones que no lo hagan. Aplica solo al código nativo. Si tu app y cada biblioteca y SDK dentro de ella son Java o Kotlin puro, Google indica que tu app ya admite dispositivos de 16 KB. El problema es que la mayoría de quienes ven esta advertencia creen estar en esa categoría y no lo están.
Identifica el .so que falla
Abre tu APK de producción en Android Studio con Build > Analyze APK..., despliega lib/arm64-v8a y lib/x86_64, y lee la columna Alignment. Anota cada nombre de archivo que señale. Esos nombres son las únicas claves de búsqueda fiables que tienes.
Actualiza lo que la entrega
Un binario que compilaste tú lo arregla tu cadena de herramientas: AGP 8.5.1 o posterior con NDK r28 o posterior. Un binario que llegó dentro de un plugin, SDK, motor o AAR solo lo puede arreglar quien lo construyó, así que la acción es actualizar, reemplazar o pedir un artefacto recompilado a ese paquete.
Encuentra la ruta más corta para tu frameworkVerifica el artefacto, no la actualización
Dos comprobaciones independientes tienen que pasar las dos. Cada segmento ELF LOAD debe estar alineado a 2**14 o más, y bundletool debe reportar PAGE_ALIGNMENT_16K para el bundle de producción. Aprobar una no demuestra nada sobre la otra.
Toda la decisión en una sola pantalla
Antes de cambiar una sola versión de dependencia, recorre esto. Toma unos dos minutos y es la diferencia entre arreglar lo correcto y actualizar once paquetes que nunca fueron el problema.
¿El APK de producción contiene una carpeta lib con archivos .so?
Ya cumple
No hay código nativo en el APK. Google indica que una app solo de Java o Kotlin, incluidas sus bibliotecas y SDK, ya admite dispositivos de 16 KB. Aun así vale una prueba, y vale confirmar que inspeccionaste el mismo build que subiste.
¿APK Analyzer o check_elf_alignment.sh nombran una biblioteca sin alinear?
Atribuir y después actualizar
Averigua qué framework, plugin, SDK o motor entrega ese nombre de archivo exacto y actualiza ese paquete. Tu propio NDK no puede reescribir el binario precompilado de otra persona.
¿Qué reporta bundletool dump config para el bundle de producción?
PAGE_ALIGNMENT_4K
Las bibliotecas están bien pero el empaquetado no. Pásate a AGP 8.5.1 o posterior y recompila, o aplica el rodeo de empaquetado heredado si no puedes actualizar.
PAGE_ALIGNMENT_16K
El empaquetado es correcto. Ahora prueba los APK generados por Play en un entorno real de 16 KB y audita cualquier código en ejecución que asuma un tamaño de página fijo.
La trampa en una línea
Un APK local que pasa todas las comprobaciones de alineación no demuestra que el bundle que subiste sea correcto. Google advierte específicamente de que Android Gradle Plugin 8.3 a 8.5 puede producir un bundle cuyos APK construidos por Play no queden bien alineados en ZIP, incluso cuando el APK de tu máquina se ve perfecto. Ese desajuste es, con diferencia, el motivo más común de que la advertencia sobreviva a una solución "exitosa".
Qué significa realmente la advertencia de Play Console
La consecuencia documentada por Google es precisa: desde el 1 de febrero de 2027 no podrás publicar actualizaciones que apunten a Android 15 (nivel de API 35) o superior sin compatibilidad con 16 KB. Es un bloqueo de publicación sobre las actualizaciones, no una afirmación de que una app ya publicada se retire de la tienda ese día. Hasta entonces, la mayoría de los desarrolladores ve una advertencia de compatibilidad y no un rechazo duro al subir.
La redacción importa, porque la versión alarmista de esta historia viaja más rápido que la exacta. Lee los textos que Google muestra de verdad y el alcance se vuelve estrecho y manejable.
App must support 16 KB memory page sizes
Reconstruido a partir de la captura de Play Console que Google publica en la guía de tamaños de página. Las etiquetas se reproducen en inglés tal como aparecen en esa captura: tu consola puede mostrarlas en español, y el diseño y los botones disponibles pueden variar según la cuenta.
Dos lecturas de esa tarjeta suelen ser incorrectas. Primera: "Action by Feb 1, 2027" no es una cuenta atrás hacia la eliminación; el propio texto de Google en esa misma página describe el resultado como la imposibilidad de publicar esas actualizaciones. Segunda: el texto Extension granted aparece en la captura de Google, pero eso no establece que haya un flujo de solicitud de prórroga abierto para ti ahora mismo. Considera real una prórroga solo si ves la opción dentro de tu propia Play Console.
¿Qué fecha límite leíste en realidad?
Circulan tres fechas y solo una sigue viva. Elige la que viste y esto resuelve su estado frente a la página actual de Google, actualizada por última vez el 5 de agosto de 2026.
Instrumento 01
Resolutor de fechas
Google ha movido esta fecha límite más de una vez. Antes de armar un plan de versión en torno al 1 de febrero de 2027, abre tú mismo la guía de tamaños de página y revisa su marca de "Última actualización" al final. Ese único hábito vale más que cualquier fecha impresa en un artículo, incluido este.
¿El requisito de 16 KB afecta a mi app?
Esto no lo decide tu framework. Lo decide el contenido del APK que generas. Si hay archivos .so bajo lib, estás dentro del alcance aunque nunca hayas abierto un archivo de C++, y si no hay ninguno, la propia guía de Google dice que ya admites dispositivos de 16 KB.
Apps de Java o Kotlin puro
Google es inequívoco aquí: si tu app y todas sus bibliotecas y SDK usan solo Java o Kotlin, tu app ya admite dispositivos de 16 KB. Google recomienda igualmente probar en un entorno de 16 KB para detectar regresiones inesperadas, lo que te cuesta una ejecución de emulador.
La trampa está en la frase "y todas sus bibliotecas y SDK". Una sola dependencia de base de datos, analítica, informes de fallos, multimedia, mapas, aprendizaje automático o seguridad puede añadir binarios nativos a un proyecto cuyo código fuente no contiene más que Kotlin. "No escribí C++" no es evidencia. La carpeta lib sí lo es.
Flutter, React Native, Unity, Kivy y creadores sin código
Estos stacks incluyen por diseño runtimes nativos, binarios de motor y bibliotecas de plugins, así que casi siempre están dentro del alcance. Google nombra explícitamente a los creadores de apps de terceros que usan bibliotecas nativas como una vía por la que una app puede verse afectada aunque su autor nunca haya escrito C ni C++. Lo que varía no es si tienes código nativo sino qué paquete entregó la pieza que falla, y por eso atribuir el nombre de archivo va antes que cualquier actualización.
Cómo comprobarlo, exactamente
Abre el APK de producción, despliega lib, y mira las carpetas de ABI que contiene, normalmente arm64-v8a y x86_64. Cualquier archivo de objeto compartido presente significa que tu app usa código nativo. Ningún archivo .so y ninguna carpeta lib significa que ese APK no usa código nativo en absoluto. La columna Alignment del analizador muestra advertencias para los archivos con problemas de alineación, y es la vía más rápida para pasar de "algo va mal" a un nombre de archivo.
Instrumento 02
Triaje de afectación
01 ¿A qué apunta tu app ahora mismo?
02 Abre el APK de producción en APK Analyzer. ¿Hay una carpeta lib?
03 ¿Qué describe mejor la app?
04 ¿Ejecutaste bundletool dump config sobre el bundle de producción?
Por qué un binario de 4 KB falla en un dispositivo de 16 KB
Una página de memoria es el bloque más pequeño que el kernel mapea de una vez. Android usó históricamente páginas de 4 KB; Android 15 añadió compatibilidad con dispositivos configurados con páginas de 16 KB. Una biblioteca nativa guarda la alineación con la que se enlazaron sus segmentos, y si ese valor es menor que el tamaño de página del dispositivo, el cargador no puede colocar el segmento en un límite de página.
Ese es todo el mecanismo, y explica el único número que vas a ver una y otra vez. La alineación se expresa como potencia de dos: 2**12 son 4096 bytes, 2**14 son 16384 bytes. La regla de Google es que cada segmento LOAD de una biblioteca nativa esté alineado a 2**14 o más. Una biblioteca construida con 2**14 funciona en dispositivos de 4 KB y de 16 KB, porque 16384 es un múltiplo exacto de 4096. Una biblioteca construida con 2**12 solo funciona en el tamaño de página menor. Esa asimetría es por lo que la solución siempre es "subir la alineación" y nunca "detectar el dispositivo".
Instrumento 03
Visualizador de páginas
Elige la alineación que reporta tu biblioteca y mira dónde pueden empezar sus segmentos en un dispositivo que usa páginas de 16 KB.
Pasa
Hay una segunda restricción, completamente aparte, que vive fuera de la biblioteca. Las bibliotecas nativas almacenadas sin comprimir dentro de un APK también deben quedar en un límite de 16 KB dentro del propio archivo ZIP. Eso es una propiedad del empaquetado, se comprueba con zipalign y la configura tu plugin de build, y puede estar mal mientras cada biblioteca de dentro está perfectamente alineada. Mantener esas dos ideas separadas es lo más útil que puedes llevarte de esta sección.
Cómo leer los números
Cuando veas 2**14 en la salida de llvm-objdump, eso pasa. 2**13 o 2**12 falla. No hay puntuación parcial ni "casi suficiente": un solo segmento LOAD sin alinear, en una sola biblioteca, en una sola ABI, basta para mantener la advertencia en tu cuenta.
La solución más corta para cada framework
La preparación de un framework y el cumplimiento de una app son dos cosas distintas. React Native 0.77 y las versiones compatibles de Unity son referencias reales y documentadas. Flutter no tiene un mínimo universal verificable. En todos los casos, la actualización arregla los binarios propios del framework y deja cada plugin de terceros exactamente igual de incumplidor que antes.
Instrumento 04
Buscador de framework
Qué puede seguir fallando después de esto
Todas las referencias en una tabla
| Framework | Referencia documentada | Acción más corta | Confianza |
|---|---|---|---|
| Flutter | Sin mínimo universal verificado; 3.38 es el hito de preparación documentado (NDK r28 por defecto) | Flutter estable actual, actualizar plugins nativos, limpiar, recompilar, inspeccionar cada biblioteca | PARCIAL |
| React Native | 0.77 | Ruta de actualización soportada, después actualizar módulos nativos y SDK de proveedores | VERIFICADO |
| Línea Unity 6.1 | 6000.1 o posterior | Subir el editor, actualizar paquetes y plugins, recompilar | VERIFICADO |
| Unity 6 LTS | 6000.0.38f1 o posterior | Igual que arriba | VERIFICADO |
| Unity 2022 LTS | 2022.3.56f1 o posterior | Igual que arriba | VERIFICADO |
| Unity 2021 | 2021.3.48f1 o posterior, requiere elegibilidad de LTS extendido | Subir si tienes derecho, si no migrar a un editor compatible | VERIFICADO |
| Unity Burst | 1.8.21 o posterior | Subir Burst cuando se nombre lib_burst_generated.so |
VERIFICADO |
| Android nativo | NDK r28+ con AGP 8.5.1+ | Recompilar el código propio, actualizar cada dependencia precompilada | VERIFICADO |
| Atado a un NDK antiguo | r27 o anterior con las dos opciones de enlazado | Añadir max-page-size y common-page-size, recompilar todas las bibliotecas |
FUNCIONA, NO PREFERIDO |
| Kivy o creador con Python | Ninguna versión universal verificada | Actualizar el creador y las recetas, escalar el nombre exacto aguas arriba | DEPENDE DEL PROVEEDOR |
| Creador sin código | Ninguna versión universal verificada | Regenerar sobre el stack de build conforme del proveedor y enviarle el nombre de archivo | DEPENDE DEL PROVEEDOR |
Las etiquetas de confianza significan lo mismo en toda esta página. VERIFICADO quiere decir que una fuente primaria actual lo afirma directamente. PARCIAL quiere decir que una fuente fiable respalda la afirmación central pero no todos los detalles de implementación. REPORTADO quiere decir que la evidencia es el issue tracker de un mantenedor o reportes de desarrolladores y no una nota de versión oficial.
Encuentra la biblioteca exacta que causa el error
El nombre de archivo es toda la investigación. En cuanto sabes que libfoo.so es el binario que falla, la pregunta deja de ser "cómo arreglo la compatibilidad con 16 KB" y pasa a ser "qué paquete entrega libfoo.so, y existe una versión más nueva". Esa segunda pregunta tiene respuesta; la primera no.
Empieza en APK Analyzer
Abre Build > Analyze APK..., carga el APK de producción y despliega lib. Dentro verás una carpeta por ABI, normalmente arm64-v8a y x86_64. La columna Alignment muestra mensajes de advertencia frente a los archivos con problemas de alineación. Las propias advertencias de Android Studio y Lint también resaltan las bibliotecas nativas no conformes, así que puedes ver el mismo hallazgo en más de un sitio.
Anota cada nombre de archivo señalado antes de tocar un solo número de versión. Revisa las dos carpetas de ABI por separado: es totalmente normal que arm64-v8a pase mientras x86_64 falla, o al revés, porque son binarios distintos construidos por pipelines potencialmente distintos.
Decodifica la salida de la línea de comandos
Si prefieres trabajar en una terminal, Google publica check_elf_alignment.sh, que reporta ALIGNED o UNALIGNED para un APK, y puedes inspeccionar una sola biblioteca directamente con llvm-objdump. Los dos necesitan Android SDK Build-Tools 35.0.0 o posterior. Pega abajo lo que impriman y esto te lo leerá de vuelta.
Instrumento 05
Decodificador ELF
Pega la salida de llvm-objdump -p file.so | grep LOAD, check_elf_alignment.sh o zipalign -c -P 16. Todo se analiza en tu navegador; no se sube nada a ningún sitio.
Averigua qué dependencia la entrega
Play Console y APK Analyzer te dan los dos un nombre de archivo y ningún propietario. Escríbelo abajo y esto te dirá lo que se sabe de ese binario, con la calidad de la evidencia adjunta, y te dará los comandos de búsqueda con tu nombre de archivo ya puesto.
Instrumento 06
Búsqueda de propietario de biblioteca
./gradlew app:dependencies te muestra el grafo de dependencias resuelto, que es como encuentras el paquete transitivo que arrastró una biblioteca que nunca añadiste tú. No te dirá directamente qué artefacto contiene un .so concreto, así que combínalo con descomprimir el AAR sospechoso. Son técnicas prácticas de diagnóstico y no pasos obligatorios de Google.
Verifica el app bundle, no solo el APK local
Tu APK local y los APK que Google Play genera desde tu bundle son artefactos distintos. La alineación ELF vive dentro de cada biblioteca; la alineación ZIP es una propiedad de cómo se empaquetó el archivo; y el bundle lleva una configuración que le dice a Play cuál usar. Las tres pueden discrepar, y solo la última decide qué instalan los usuarios.
Este es el mecanismo detrás de la versión más frustrante del problema: el desarrollador actualiza todo, inspecciona el APK local, ve una salida limpia, sube, y la advertencia sigue ahí. Nada de lo que revisó estaba mal. Simplemente nunca revisó lo que Play evalúa.
Lo que inspeccionaste
app-release.apk en tu máquinaConstruido directamente por Gradle en tu hardware, con tu comportamiento de empaquetado. Pasar zipalign aquí demuestra que ese archivo está bien empaquetado.
Lo que Play evalúa
Los APK generados desde app-release.aabConstruidos por Google desde tu bundle, con la alineación que el bundle pide. Si el bundle dice 4 KB, esos APK están mal por muy limpio que estuviera tu APK local.
Así que ejecuta esto contra el bundle que estás a punto de subir, todas las veces:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K es el resultado que quieres. PAGE_ALIGNMENT_4K significa que el bundle le está diciendo a bundletool que empaquete las bibliotecas nativas en límites de 4 KB, así que cada APK que Play construya desde él estará mal. Google advierte específicamente de que Android Gradle Plugin 8.3 a 8.5 puede producir exactamente ese desajuste: el build local se ve alineado, y la app que Play construye desde el bundle no se instalará bien en un dispositivo de 16 KB. La solución preferida es pasar a Android Gradle Plugin 8.5.1 o posterior.
Todos los comandos, con tus propios nombres de archivo
Escribe tus nombres de archivo una vez. Cada comando de abajo se reescribe, y cada pestaña muestra la salida exacta que cuenta como aprobación, así que nunca adivinas si un resultado fue bueno.
Instrumento 07
Laboratorio de comandos
No te quedes en "APK Analyzer dice alineado"
Una inspección de APK aprobada es una de cuatro comprobaciones, no la meta. Confirma la alineación ELF de los segmentos LOAD, la alineación ZIP del APK, la configuración del bundle y el comportamiento en ejecución del artefacto que Play genera de verdad. Que falle cualquiera de ellas basta para que la advertencia siga en tu cuenta después de un build que creías arreglado.
AGP, NDK y la trampa del empaquetado
Dos versiones cargan con casi todo el peso. El NDK r28 o superior compila código nativo alineado a 16 KB por defecto, y Android Gradle Plugin 8.5.1 o superior empaqueta correctamente las bibliotecas nativas sin comprimir en límites ZIP de 16 KB. Ninguno de los dos puede reparar un binario precompilado que llegó dentro de una dependencia.
El terreno peligroso es Android Gradle Plugin 8.3 a 8.5. En ese rango un build local puede verse completamente correcto mientras bundletool no alinea en ZIP los APK que produce desde tu bundle para Play, y la redacción de Google es tajante sobre el resultado: la app construida desde ese bundle no se instalará bien. Si estás en 8.5.0 y tu APK local pasa todas las comprobaciones que se te ocurren, esto es lo primero que hay que descartar.
Instrumento 08
Verificador de cadena de herramientas
Referencia de ajustes de build
| Situación | Ajuste | Notas |
|---|---|---|
| NDK preferido | r28 o superior |
Produce salida nativa alineada a 16 KB por defecto |
| AGP preferido | 8.5.1 o superior |
Maneja bibliotecas nativas sin comprimir en límites ZIP de 16 KB |
| NDK r27 o anterior | -Wl,-z,max-page-size=16384 |
Opción de enlazado obligatoria en cada objetivo nativo |
| NDK r27 o anterior | -Wl,-z,common-page-size=16384 |
Úsala junto con la opción de tamaño máximo de página |
ndk-build |
LOCAL_LDFLAGS += ... |
Aplica las dos opciones a cada objetivo nativo |
| CMake | target_link_options(...) |
Aplica las dos opciones a cada objetivo relevante |
| No puedes actualizar AGP | jniLibs.useLegacyPackaging = true |
Comprime las bibliotecas nativas; aumenta el espacio instalado |
| AGP 8.0 o anterior | android.bundle.enableUncompressedNativeLibs=false |
Propiedad heredada adicional, junto a la opción de arriba |
| Código en ejecución | getpagesize() o sysconf(_SC_PAGESIZE) |
Sustituye los 4096 fijos y los supuestos de PAGE_SIZE constante |
La parte que el empaquetado no puede arreglar
Si tu propio C o C++ asume un tamaño de página, ninguna opción de build te salva. Quita los valores 4096 fijos y cualquier dependencia de una constante PAGE_SIZE fija, consulta el valor real en ejecución con getpagesize() o sysconf(_SC_PAGESIZE), y revisa cada llamada a mmap() junto con cualquier argumento que estés alineando a mano. Esta es la clase de fallo en la que una app se instala limpiamente en un dispositivo de 16 KB, pasa las comprobaciones del bundle y luego se cae la primera vez que toca el mapeo de memoria.
Orden de las operaciones
Arregla el lado del compilador antes que el del empaquetado. Si aplicas primero el rodeo de empaquetado heredado, tu APK empezará a pasar zipalign mientras las bibliotecas de dentro siguen construidas para páginas de 4 KB, y habrás escondido el problema real detrás de un resultado en verde.
Prueba en un entorno real de 16 KB
Un solo comando decide si tu prueba significa algo: adb shell getconf PAGE_SIZE tiene que devolver 16384. Ejecútalo antes de cada sesión. Un emulador que arrancó en silencio en modo 4 KB dejará que un build roto pase todo lo que le eches.
Tienes tres rutas prácticas y dos especializadas. Elige la que de verdad puedas conseguir hoy; para cazar fallos de tamaño de página no hay diferencia de calidad entre ellas.
Instrumento 09
Selector de entorno de prueba
Limitación
Después, cada vez y sin excepción, antes de cualquier prueba
adb shell getconf PAGE_SIZE
No sigas hasta que la salida sea 16384.
Qué hay que ejercitar de verdad
Una vez confirmado el entorno, la pasada de pruebas útil no es "arranca". Los fallos nativos se concentran en las funciones que tocan código nativo, así que úsalas a propósito: arranque en frío, navegación por la app, cámara, lecturas y escrituras de base de datos, reproducción y grabación multimedia, autenticación, trabajo en segundo plano, cualquier función de aprendizaje automático o realidad aumentada, cada superficie de plugin nativo, y todo lo de tu propio código que use mapeo de memoria. Si una función la mueve una de las bibliotecas que acabas de actualizar, esa función es la prueba.
El modo de compatibilidad no es aprobar
Android puede ejecutar algunas apps alineadas a 4 KB en un dispositivo de 16 KB mediante una ruta de compatibilidad, y puede que veas una advertencia en el primer arranque cuando lo hace. Google sigue recomendando una alineación correcta a 16 KB para la mejor fiabilidad y estabilidad. Una app que solo funciona porque intervino el modo de compatibilidad no es una app arreglada, y publicar sobre esa base significa que el fallo real sigue por delante de ti.
Por qué la advertencia sobrevive a una actualización
Casi todos los casos de "si ya lo arreglé" son una de trece situaciones concretas, y once de ellas se pueden demostrar con el artefacto que tienes delante. Elige el síntoma que encaje y normalmente sabrás la causa antes de terminar de leerlo.
Instrumento 10
Triaje de advertencias que no se van
Dos de esos casos merecen una advertencia más que una respuesta segura. Ninguna fuente primaria establece cuánto tarda Google Play en reevaluar un bundle subido, así que si tu advertencia persiste justo después de una subida, lo honesto es confirmar que el nuevo código de versión aparece en tus últimas versiones y app bundles y volver a mirar más tarde, en lugar de fiarse de una cifra concreta que hayas leído sobre tiempos de procesamiento. Y una app que solo funciona porque intervino el modo de compatibilidad no está arreglada, está acomodada.
Bibliotecas de terceros que aparecen una y otra vez
Son ejemplos reportados, no un ranking de lo comunes que son, ni una promesa de que una versión concreta arregle tu build. Un paquete puede añadir, quitar o reemplazar artefactos nativos en cualquier versión. La autoridad final siempre es el binario que está dentro de tu propio bundle de producción.
Úsalo como punto de partida cuando un nombre de archivo te suene, y después verifica contra las versiones actuales y los issues abiertos de ese proyecto. Cuando la evidencia es el issue tracker de un mantenedor y no una nota de versión, la tarjeta lo dice.
Instrumento 11
Índice de bibliotecas reportadas
libobjectbox-jni.so
Bibliotecas nativas de Android más antiguas fallaban en un entorno de 16 KB. Aquí no se pudo confirmar con suficiente solidez una versión corregida concreta como para publicarla. Revisa las notas de versión actuales de ObjectBox para ver cuál añadió la compatibilidad con 16 KB, y después confirma el binario dentro de tu APK construido en lugar de fiarte solo del número de versión.
biblioteca Android incluida
El SDK de Dart de ObjectBox incluye su propia biblioteca de Android. Aquí no se pudo confirmar con suficiente solidez una versión corregida concreta como para publicarla. Revisa las notas de versión actuales de ObjectBox y después verifica el artefacto que tu build resuelve de verdad.
libsqlite3.so
Una dependencia antigua 3.43.0 apareció en empaquetados afectados de Flutter y AWS Amplify. La evidencia de los issues identifica 3.46.1+1 como la versión que añadió la compatibilidad con 16 KiB. Revisa la versión de dependencia resuelta, no solo la que declaraste, porque un paquete de framework puede fijar una más antigua.
sqlcipher-android
El paquete antiguo android-database-sqlcipher está obsoleto aguas arriba en favor del paquete mantenido sqlcipher-android. Aquí no se pudo confirmar con suficiente solidez una versión concreta como mínimo corregido, así que migra al paquete mantenido actual y valida cada ABI en la app construida en lugar de fiarte de un número de versión.
binarios de procesamiento multimedia
El repositorio original de FFmpegKit se retiró, y no se estableció ninguna versión conforme universalmente segura. La calidad de los forks varía. Identifica exactamente qué fork resuelve tu build, inspecciona directamente sus artefactos por ABI, y sopesa mantenimiento y procedencia antes de adoptar uno como solución.
binarios de Realm y JNI
Los reportes se contradicen. Se señaló la versión 20.1.0, y un reporte posterior decía que la 20.2.0 reparó un binario de Realm mientras otro binario JNI seguía dando problemas. No se puede nombrar de forma responsable una única versión segura, así que actualiza y después revisa individualmente cada biblioteca que aporta Realm.
libmediapipe_tasks_vision_jni.so
Reportado con alineación 2**12. En el issue consultado no se estableció ninguna versión corregida, así que trata la compatibilidad como dependiente de la versión: revisa las notas de versión actuales, actualiza y verifica el binario en tu propio build.
artefacto de OpenCV Android
Se reportaron problemas de alineación contra un artefacto de Android de OpenCV 5.0.0. El issue del repositorio hace referencia a un arreglo de CI, pero no se pudo establecer con seguridad ningún artefacto publicado concreto. Descarga el AAR exacto del que dependes, descomprímelo e inspecciona tú mismo las bibliotecas.
lib_burst_generated.so
La propia recomendación de Unity es actualizar el paquete Burst a 1.8.21 o posterior cuando se señale este archivo. Es la única entrada del índice respaldada por documentación oficial del proveedor y no por reportes de issues.
libUnityARCore.so, libquack.so y otros
Los reportes de la comunidad los nombran entre los binarios que sobreviven a una actualización del editor. No hay una versión universal que citar, porque cada uno pertenece a un paquete distinto. Usa el nombre de archivo exacto para decidir a qué paquete perseguir.
Ninguna entrada coincide con ese filtro. Es normal: este índice cubre ejemplos reportados y no todas las bibliotecas del ecosistema. Usa la búsqueda de propietario de biblioteca y rastrea el archivo dentro de tu propio proyecto.
Por qué este índice es corto: el número de issues muestra qué proyectos tienen usuarios ruidosos, no qué bibliotecas se instalan más. Publicar una lista ordenada de "los infractores más comunes" sería inventarse una estadística. Lo que sí generaliza es el método: tomar el nombre de archivo, encontrar el paquete, revisar las versiones actuales de ese paquete y verificar el binario en tu build.
Cómo se relaciona con la fecha límite de API 36 del 31 de agosto de 2026
Son dos requisitos de Google Play independientes que se cruzan en un solo punto. Subir el nivel de API objetivo puede sacar a la luz la advertencia de 16 KB, porque el requisito aplica a las apps que apuntan a Android 15 (nivel de API 35) o superior. No crea el desalineamiento y tampoco puede repararlo.
Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16 (nivel de API 36) desde el 31 de agosto de 2026, con una prórroga disponible hasta el 1 de noviembre de 2026. Eso es un cambio de manifiesto y de comportamiento. La regla de 16 KB, en cambio, es un cambio de compatibilidad binaria. Quien sube targetSdk un lunes y ve una advertencia de 16 KB el martes no rompió nada: las bibliotecas nativas ya estaban compiladas para páginas de 4 KB, y el nivel objetivo más alto simplemente metió la app dentro del alcance de una comprobación que iba a aplicar de todos modos.
Requisito A
Apuntar a API 36- Fecha 31 de agosto de 2026, prórroga hasta el 1 de noviembre de 2026
- Alcance Apps nuevas y actualizaciones
- Vive en Tu manifiesto y tu configuración de build
- Se arregla con Subir el nivel objetivo y atender los cambios de comportamiento de Android 16
Requisito B
Compatibilidad con páginas de 16 KB- Fecha 1 de febrero de 2027
- Alcance Apps que apuntan a API 35+ en dispositivos de 64 bits
- Vive en Los binarios nativos dentro de tu bundle
- Se arregla con Recompilar o reemplazar cada biblioteca mal alineada
En la práctica, trátalos como una sola migración con dos pruebas. De todas formas vas a subir el nivel objetivo: programa la auditoría de bibliotecas nativas en esa misma versión en lugar de descubrirla en plena carrera por la API 36. Para el conjunto completo de niveles por tipo de dispositivo, las excepciones y la mecánica de la prórroga, consulta nuestro artículo sobre la fecha límite de API 36 de Google Play, y para toda la secuencia desde la cuenta hasta producción, nuestro artículo de requisitos de publicación 2026.
El control previo a la subida
Once comprobaciones, cada una con una prueba concreta de aprobación. Recórrelas antes de subir y no después de que Play te diga que algo está mal, y conviertes una sesión de depuración sin límite en una lista finita.
Instrumento 12
Control previo a la subida
0 de 11 superados
Todavía no hay nada demostrado. Empieza por el build que de verdad piensas subir, no por el último que tenías abierto.
Tu progreso se guarda solo en este navegador. No se envía nada a ningún sitio, y borrar los datos del navegador lo borra.
Superar los once puntos demuestra alineación técnica frente a las comprobaciones citadas en esta página. No es una promesa de aprobación. Google Play todavía puede plantear en la misma subida problemas de política, contenido o calidad sin relación con esto, y ninguna lista de verificación puede hablar por ellos.
Dónde choca esto con tu prueba cerrada
Nada de esta página cambia tu requisito de testers, y nada de tus testers cambia tu build. Los dos problemas chocan en un solo eje: el tiempo. Una prueba cerrada de 14 días corre sobre un reloj que no puedes pausar, y una investigación de bibliotecas nativas corre sobre un reloj que nadie sabe predecir.
La secuencia que duele es esta. Una cuenta personal de desarrollador arranca una prueba cerrada, empieza la ventana de 14 días de participación continua, y en algún punto intermedio una subida del nivel objetivo saca a la luz una advertencia de 16 KB. Ahora el desarrollador recompila dependencias nativas mientras un grupo de testers tiene que mantenerse intacto alrededor. Subir una versión nueva al canal de pruebas está perfectamente bien, y Google anima a los desarrolladores a seguir actualizando durante una prueba. Lo que rompe la racha es que el lado de los testers se quede en silencio.
Esa es justo la parte que PrimeTestLab mantiene estable. Aportamos 12 testers reales en dispositivos reales que cubren Android 7 a 17, con participación aceptada y sostenida los 14 días completos, para que tu recompilación ocurra frente a una prueba estable y no frente a una que se desmorona. La prueba arranca en 4-6 horas, y hemos hecho esto en 7,400+ apps de 120+ países con una tasa de éxito del 99.9%.
Reclutar testers tú mismo frente a una prueba gestionada
| El requisito de Google | Reclutar tú mismo | Prueba gestionada |
|---|---|---|
| Al menos 12 testers con participación aceptada | Buscar, explicar y perseguir a personas reales, y luego esperar que ninguna se salga | 12 aportados y sostenidos durante toda la ventana |
| 14 días de forma continua | Un solo tester que se va a mitad rompe la continuidad | El grupo se monitorea para que la ventana siga intacta |
| Dispositivos reales, personas reales | Los emuladores y las cuentas inactivas son el atajo habitual, y el motivo habitual de que una prueba falle | Dispositivos reales de Android 7 a 17 |
| Tiempo hasta la primera participación | Días, según quién te responda | La prueba arranca en 4-6 horas |
| Costo | Tu tiempo, justo la semana en la que ya estás recompilando bibliotecas | Desde $19.99 más un 5% de tarifa de servicio |
| Recompilar a mitad de la prueba | Cada subida nueva es otra ronda de pedirle a la gente que actualice | Publica versiones nuevas con libertad; el grupo mantiene su participación |
Para ser directos con el límite: no recompilamos tus bibliotecas nativas y este artículo no es un argumento de venta para hacerlo. El trabajo de los 16 KB es tuyo, y todo lo que va antes de esta sección está escrito para que sea lo más corto posible. Lo que te quitamos de encima es el requisito de testers que corre en paralelo, para que los dos problemas dejen de competir por la misma quincena.
Consejo de secuencia
Si todavía no arrancaste la prueba cerrada y ya sabes que llevas bibliotecas nativas, pon primero en marcha la ventana de testers y haz el trabajo de alineación dentro de ella. El periodo que califica según Google se mide por la continuidad de la participación de los testers y no por un build congelado, y Google anima a seguir actualizando durante una prueba, así que los dos calendarios pueden solaparse en lugar de apilarse. Mantén el mismo canal de pruebas (segmento de pruebas en la consola en es-419) y el mismo grupo de testers mientras lo haces. Eso suele ser una semana completa de ahorro.
Preguntas frecuentes
¿Google Play ya está rechazando apps incompatibles con 16 KB?
La documentación actual de Google dice que a partir del 1 de febrero de 2027 no podrás publicar actualizaciones que apunten a Android 15 (nivel de API 35) o superior sin compatibilidad con 16 KB en dispositivos de 64 bits. Antes de esa fecha, la mayoría de los desarrolladores ve una advertencia de compatibilidad en Play Console y no un bloqueo duro. La consecuencia documentada en la página de Google citada es la imposibilidad de publicar actualizaciones no conformes, no la retirada automática de una app ya publicada.
¿Por qué Google dice 1 de febrero de 2027 cuando otros artículos dicen 1 de noviembre de 2025?
El 1 de noviembre de 2025 fue la fecha límite anunciada originalmente por Google y el 31 de mayo de 2026 fue una fecha de prórroga histórica posterior. A 5 de agosto de 2026, tanto la página actual de Android Developers como la captura actual de la advertencia en Play Console muestran el 1 de febrero de 2027, así que manda la fuente primaria más reciente. Muchos artículos de blog y respuestas de IA siguen citando las fechas viejas porque se escribieron antes del cambio.
Nunca escribí C++. ¿Por qué está afectada mi app?
Un framework, un SDK, un plugin, un motor de juego, una base de datos, un componente multimedia o un creador de apps puede añadir archivos nativos .so aunque tu propio código fuente sea Dart, JavaScript, Python, Java o Kotlin. Las indicaciones de Google incluyen explícitamente a las apps que usan bibliotecas del NDK de forma indirecta, a través de una dependencia. Abre el APK en Android Studio con Build y luego Analyze APK: cualquier archivo .so bajo lib significa que la app empaquetada usa código nativo.
¿Una app de Kotlin puro necesita algún cambio?
Según Google, una app que solo usa Java o Kotlin, incluidas todas sus bibliotecas y SDK, ya admite dispositivos de 16 KB. Google recomienda igualmente probar en un entorno de 16 KB por si aparecen regresiones inesperadas. Verifica que el APK de producción real no tenga un directorio lib antes de llamar a tu app Kotlin puro, porque una sola dependencia de analítica o de base de datos puede añadir uno.
¿Qué versión de Flutter soluciona la advertencia de tamaño de página de 16 KB?
Ninguna fuente oficial establece una versión de Flutter que garantice que todas las apps y plugins de Flutter cumplen. Las notas de la versión Flutter 3.27 son más estrechas de lo que parecen: cubren la compatibilidad con 16 KB para las plantillas plugin_ffi en concreto y no el motor entero. Flutter 3.38 es el hito documentado más sólido: Flutter presentó explícitamente esa actualización como preparación para el requisito de 16 KB de Play y cambió el NDK por defecto a r28. Lo más seguro es pasar a la versión estable actual de Flutter, actualizar cada plugin nativo, recompilar el bundle de producción e inspeccionar cada archivo .so que salga.
¿Qué versión de React Native admite páginas de 16 KB?
React Native 0.77 es la versión base oficial y sin ambigüedad. Su anuncio de versión indica que React Native está listo para admitir por completo los tamaños de página de 16 KB. Los módulos nativos de la comunidad, el código C++ local y los SDK de terceros todavía pueden traer binarios incompatibles, así que actualiza por la ruta de migración soportada de React Native o Expo y después inspecciona el APK generado.
¿Qué versión de Unity necesito para admitir páginas de 16 KB?
Unity indica 6000.1 o posterior, 6000.0.38f1 o posterior, 2022.3.56f1 o posterior, y 2021.3.48f1 o posterior en LTS extendido para clientes Enterprise o Industry elegibles. Actualiza también tus plugins nativos y sube Burst a 1.8.21 o posterior si Play Console nombra lib_burst_generated.so. Una versión de editor compatible es necesaria pero no suficiente, porque los plugins de terceros traen sus propios binarios.
¿Cómo encuentro el archivo .so exacto que está fallando?
Abre el APK con Build y luego Analyze APK en Android Studio, despliega lib/arm64-v8a y lib/x86_64, y lee la columna Alignment, que muestra advertencias para los archivos con problemas de alineación. Para confirmarlo en la línea de comandos, ejecuta el script check_elf_alignment.sh de Google contra el APK, o inspecciona una biblioteca con llvm-objdump -p file.so canalizado a grep LOAD. Cualquier alineación LOAD por debajo de 2**14 requiere atención.
¿Por qué mi APK pasa pero mi app bundle sigue fallando?
La alineación ELF dentro de una biblioteca y la alineación ZIP dentro del artefacto empaquetado son dos comprobaciones distintas. Ejecuta bundletool dump config --bundle=app.aab y busca alignment: PAGE_ALIGNMENT_16K pasa, mientras que PAGE_ALIGNMENT_4K significa que los APK generados se siguen pidiendo a 4 KB. Google advierte específicamente de que Android Gradle Plugin 8.3 a 8.5 puede verse correcto en local mientras los APK que Play construye desde tu bundle no quedan bien alineados en ZIP, así que pásate a 8.5.1 o posterior.
¿Basta con actualizar al NDK r28 para solucionarlo?
No. El NDK r28 y superior compilan alineado a 16 KB por defecto, pero eso solo afecta al código nativo compilado durante tu build. No puede reescribir un archivo .so precompilado que llega dentro de un AAR, un plugin o un paquete de motor de juego de terceros. Cada dependencia nativa precompilada tiene que actualizarse, reemplazarse o recompilarse y reimportarse por su cuenta.
¿Cómo pruebo la compatibilidad con 16 KB sin tener un teléfono compatible?
Instala una de las imágenes de sistema de 16 KB del emulador de Android de Google desde el SDK Manager, o reserva un dispositivo compatible en Samsung Remote Test Lab. Uses lo que uses, confirma primero el entorno con adb shell getconf PAGE_SIZE: la salida tiene que ser 16384 para que la prueba signifique algo. Un éxito en el emulador demuestra el comportamiento en ejecución, no el empaquetado, así que sigue inspeccionando también el bundle de producción.
¿Arreglar la compatibilidad con 16 KB reinicia o afecta mi prueba cerrada?
Google mide el periodo que califica en torno a que al menos 12 testers mantengan aceptada su participación durante 14 días de forma continua, y no en torno a un build congelado, y anima a los desarrolladores a seguir actualizando el build durante una prueba. Google no publica una garantía explícita que cubra todos los casos de reemplazo de build, así que lo más seguro es mantener estable tu grupo de testers mientras publicas un bundle recompilado y conforme con 16 KB a mitad de la prueba. PrimeTestLab aporta 12 testers reales en dispositivos reales desde $19.99 más un 5% de tarifa de servicio, y sostiene el grupo los 14 días completos.
En resumen
Resumen
Google Play exige que las apps que apuntan a Android 15 (nivel de API 35) o superior admitan páginas de memoria de 16 KB en dispositivos de 64 bits, y desde el 1 de febrero de 2027 no se podrán publicar actualizaciones que no cumplan. El 1 de noviembre de 2025 y el 31 de mayo de 2026 son fechas muertas que todavía posicionan. Las apps de Java o Kotlin puro ya cumplen. Todos los demás siguen los tres mismos pasos: nombrar el .so que falla, actualizar el paquete que lo entrega, y probar el artefacto con dos comprobaciones independientes, cada segmento ELF LOAD alineado a 2**14 o más, y el bundle reportando PAGE_ALIGNMENT_16K. AGP 8.5.1+ con NDK r28+ es la cadena de herramientas por defecto más segura, y ninguna de las dos puede reparar un binario que compiló otra persona. Si esto cae a mitad de una prueba cerrada, el lado de los testers es la parte que puedes delegar. Ver planes y precios →
Fuentes primarias
Qué caducará primero en esta página
- La fecha del 1 de febrero de 2027. Google ya movió este calendario más de una vez. Revisa la marca de "Última actualización" al final de la guía de tamaños de página antes de planificar una versión en torno a ella.
- Los textos de Play Console. Los textos y la navegación de la consola cambian con independencia de las páginas de políticas, así que los títulos exactos que veas pueden diferir de los reproducidos aquí.
- Las versiones base de los frameworks. Flutter publica versiones estables con frecuencia, la política de soporte de React Native evoluciona y la elegibilidad del LTS de Unity cambia. Confirma en las notas de versión actuales y no en un número impreso en un artículo.
- El índice de bibliotecas reportadas. Cualquier paquete puede añadir, reemplazar o hacer retroceder un binario nativo en cualquier versión. Verifica siempre el artefacto de tu propio bundle.
- Los nombres de las imágenes de emulador. Las imágenes etiquetadas como experimentales pueden renombrarse o promocionarse, así que el texto exacto en el SDK Manager puede no coincidir.
Verificado contra la documentación de Google el 9 de agosto de 2026. Revisión mensual hasta al menos un mes después de la entrada en vigor.