Android 16 KB de página: impacto real y cómo preparar tu app

Si te has cruzado con el mensaje sobre páginas de memoria de 16 KB en Android en el emulador o en Google Play Console, no estás solo. Es un cambio técnico con impacto real en el rendimiento y en la publicación de apps a partir de Android 15, así que conviene entender qué es, por qué se hace y cómo adaptar tus builds.

En pocas palabras, Android abre la puerta a dispositivos configurados con tamaño de página de 16 KB (además de 4 KB), lo que puede traducirse en inicios de app más rápidos, menor consumo y un sistema más ágil. Eso sí, si tu app integra código nativo (.so), tendrás que recompilar y alinear correctamente o te arriesgas a errores de instalación y bloqueos en Google Play.

¿Qué significa el tamaño de página y qué cambia con Android 15?

El tamaño de página es la unidad básica con la que el sistema operativo gestiona la RAM. Históricamente, Android se optimizó para 4 KB porque era lo más común en dispositivos y kernels, mientras que muchas CPU ARM ya soportaban 16 KB. Con Android 15, AOSP incorpora soporte para compilar y ejecutar en dispositivos de 16 KB, y además introduce alineación ELF de 16 KB en espacio de usuario que funciona con kernels de 4 KB y 16 KB (a partir de android14-6.1).

Beneficios de rendimiento medidos por Google

Adoptar 16 KB conlleva un pequeño incremento medio de memoria, pero ofrece mejoras sistémicas y de apps. En pruebas iniciales de Android 15 se observaron:

Arranques de apps más rápidos: de media un 3,16%, con casos puntuales de hasta un 30%.
Menor consumo durante el launch: reducción media del 4,56%.
Cámara más veloz: inicios en caliente un 4,48% más rápidos y en frío un 6,60% de media.
Arranque del sistema: mejora de ~8% (aprox. 950 ms).

Algunos análisis externos hablan de ganancias totales del 5–10% a costa de ~9% más de memoria física, aunque el resultado real variará por dispositivo y app. En cualquier caso, con más RAM disponible en la gama actual, el salto a 16 KB reduce la contabilidad de memoria y ayuda a que todo vaya más fino.

¿Mi app está afectada?

La regla rápida: si tu app es 100% Java/Kotlin (incluidas bibliotecas y SDK), ya es compatible con 16 KB. Aun así, conviene probarla en un entorno de 16 KB por si aparecieran regresiones inesperadas.

Si tu proyecto usa código nativo C/C++ (NDK), enlaza con SDKs que incluyen .so, motores de juego o compiladores externos que incorporen bibliotecas nativas, tendrás que recompilar y alinear para 16 KB. Es el caso típico de apps con SQLCipher, motores como Unity/Unreal, o SDKs nativos de terceros.

Cómo saber si usas nativo y si cumples 16 KB

APK Analyzer en Android Studio

Abre Android Studio y utiliza Build → Analyze APK… para inspeccionar un APK. Navega a lib/ y busca archivos .so; si existen, tu app usa nativo. El panel muestra advertencias de Alineación si alguna biblioteca no cumple 16 KB.

Además, Android Studio incorpora comprobaciones automáticas: Lint marca bibliotecas nativas sin alineación a 16 KB, y las propias herramientas señalan problemas de APKs o prebuilts que no cumplen.

Script oficial para verificar alineación ELF

En Linux o macOS puedes usar el script check_elf_alignment.sh para analizar un APK y etiquetar cada .so como ALIGNED o UNALIGNED (arm64-v8a y x86_64):

./check_elf_alignment.sh APK_NAME.apk

Si alguna biblioteca sale como UNALIGNED, tendrás que actualizar su empaquetado, recompilar tu app y repetir las pruebas. Es una forma rápida y eficaz de detectar incumplimientos antes de subir a Play.

Verificación con herramientas de línea de comandos

Instala Build Tools ≥ 35.0.0 y un NDK reciente desde el SDK Manager. Extrae el APK y localiza los .so en lib/, y para cada uno ejecuta:

readelf -l <SHARED_OBJECT_FILE> | grep LOAD

En la salida, comprueba que los segmentos de carga muestren align 214. Si ves 213, 2**12 o menos, esa biblioteca no está alineada para 16 KB. Por último, ejecuta zipalign sobre tu APK:

zipalign -c -P 16 -v 4 APK_NAME.apk

Si termina con ‘Verification successful’, el APK está zipalineado a 16 KB correctamente, requisito clave para dispositivos de 16 KB cuando distribuyes .so sin comprimir.

Compila y empaqueta para 16 KB

Actualiza el empaquetado: AGP 8.5.1 o superior

En apps con bibliotecas nativas sin comprimir, los dispositivos de 16 KB exigen que el APK esté alineado a un límite ZIP de 16 KB. La vía recomendada es usar Android Gradle Plugin 8.5.1 o posterior, que aplica esta alineación automáticamente. Es la opción más robusta para instalaciones fiables desde Play.

Ojo con AGP 8.3–8.5: aunque en local parezca ir bien, bundletool no hace zipalign por defecto y el resultado desde App Bundle podría quedar desalineado y fallar al instalar. Si no puedes subir a 8.5.1 todavía, existe una alternativa temporal: empaquetar jniLibs comprimidos.

// Groovy
android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging true
    }
  }
}

// Kotlin DSL
android {
  packaging {
    jniLibs {
      useLegacyPackaging = true
    }
  }
}

Ten en cuenta que al comprimir .so, el instalador debe extraer y copiar las bibliotecas, lo que aumenta el uso de disco y puede elevar la tasa de fallos por poco espacio. La solución de fondo sigue siendo migrar a AGP ≥ 8.5.1.

Alineación ELF a 16 KB: NDK y flags

Los dispositivos de 16 KB requieren que los segmentos ELF de tus .so estén alineados a 16 KB. La mejor ruta es usar NDK r28 o superior, que compila con 16 KB por defecto.

Con NDK r27 tienes que habilitar la alineación mediante flags (ndk-build, CMake/Gradle o pasando la opción al vinculador). Para builds con toolchains varios, puedes forzar el enlazado con:

-Wl,-z,max-page-size=16384

Con NDK r26 o anteriores el soporte es desaconsejado; como último recurso, ajusta ndk-build/CMake con las opciones de 16 KB. Si usas NDK r22 o previos, puede hacer falta añadir common-page-size=16384 por bugs históricos en ld/lld; esta solución funciona si el ELF incluye .relro_padding (LLD 18+). Aun así, lo recomendable es migrar cuanto antes a r27/r28.

Si enlazas dinámicamente con una libc++_shared.so antigua (r26 o previas sin alineación 16 KB), tu app no se instalará en 16 KB. Toca migrar a NDK reciente o, como workaround, vincular estáticamente la STL de C++ siguiendo las consideraciones de compatibilidad, valorando pros y contras.

Evita suposiciones de 4 KB en tu código

Aunque recompiles y alinees bien, tu app puede fallar si el código asume PAGE_SIZE = 4096 o usa ese valor de forma rígida. En NDK r27+ la constante PAGE_SIZE ni siquiera se define en modo 16 KB.

Lo correcto es consultar el tamaño de página en tiempo de ejecución con getpagesize() o sysconf(_SC_PAGESIZE). Revisa usos de mmap() y otras APIs que exigen tamaños o direcciones alineadas a página, sustituyendo por alternativas cuando proceda y combinando regiones para reducir desperdicios.

Recuerda que el kernel redondea las solicitudes a la página más cercana. En 16 KB, pedir 1–5 KB asigna 16 KB; 17 KB asigna 32 KB. Donde puedas, agrupa dos regiones RW que antes ocupaban 2×4 KB para que, en 16 KB, se mantengan en una única página y evites duplicar.

Comprueba que tus SDKs soportan 16 KB

Muchos proveedores ya distribuyen builds compatibles o permiten recompilar, pero hay versiones antiguas que no cumplen. Revisa la documentación de cada SDK, actualiza a la versión compatible y confirma la alineación con las herramientas anteriores; si no hay soporte, valora retirar temporalmente esa dependencia.

Prueba en 16 KB: emulador y dispositivos

Configura el SDK de Android 15 y crea un dispositivo virtual con una imagen de sistema basada en 16 KB. Android Studio Jellyfish (2023.3.1) o posterior lo soporta, aunque se recomienda Ladybug (2024.2.1+) para la mejor experiencia.

En SDK Manager → SDK Platforms, marca Show Package Details y, dentro de Android VanillaIceCream o posterior, instala las imágenes de Google APIs Experimental 16 KB Page Size (ARM 64 v8a y/o x86_64 Atom). Si vas a emular un Pixel compatible, con la ARM 64 v8a suele bastar.

En algunas versiones del emulador (35.1.5 a 35.1.20) y antes de la revisión 4 de las imágenes 16 KB de Android 15.0 para x86_64, añade esta línea en el config.ini del AVD:

kernel.parameters = androidboot.page_shift=14

Arranca el emulador y verifica el entorno con adb shell getconf PAGE_SIZE; debe devolver 16384. Existe un problema conocido de depuración con LLDB en imágenes 16 KB, solucionado en NDK r27 (RC1) y Android Studio Koala | 2024.1.2 Canary 5.

Probar en hardware real

Desde Android 15 QPR1, algunos modelos incluyen una opción de desarrollador para iniciar el dispositivo en 16 KB. En particular, Pixel 8/8 Pro/8a la incluyen en QPR1 o superior, y Pixel 9/9 Pro/9 Pro XL desde QPR2 Beta 2 o posterior. Aplica las actualizaciones del sistema y activa el modo para validar en condiciones reales.

Comprueba el tamaño con adb shell getconf PAGE_SIZE (debería ser 16384) y verifica que tu APK esté zipalineado a 16 KB con:

zipalign -c -P 16 -v 4 APK_NAME.apk

Después, haz pruebas exhaustivas, centrándote en las áreas sensibles a tamaños de página y memoria nativa.

Modo de compatibilidad (retrocompatibilidad) de 16 KB

Cuando el dispositivo ejecuta un kernel de 16 KB, el Package Manager puede activar un modo de retrocompatibilidad si detecta .so con segmentos LOAD alineados a 4 KB o si el APK comprimido contiene ELF sin comprimir alineados con ZIP a 4 KB. La app mostrará una advertencia en el primer arranque indicando que corre en modo de compatibilidad.

qué apps consumen datos sin que lo sepas

Requisito de Google Play: fechas y alcance

Para preparar el lanzamiento de nuevos dispositivos, Google Play impondrá que las apps que apunten a Android 15 (API 35) o superior sean compatibles con páginas de 16 KB. La fecha clave pública es el 1 de noviembre de 2025 para apps nuevas y actualizaciones.

Algunos desarrolladores han recibido avisos adicionales con un hito alrededor del 1 de mayo de 2026 para endurecer bloqueos de builds no conformes. Vigila tu Play Console y tus comunicaciones, pero la referencia principal es noviembre de 2025. No es solo una casilla de cumplimiento: incorporar 16 KB ofrece mejoras de rendimiento reales.

Configuración de Android en 16 KB (avanzado)

En arm64, si compilas el kernel con Kleaf, usa –page_size=16k, o en la configuración del kernel de Linux selecciona CONFIG_ARM64_16K_PAGES en lugar de CONFIG_ARM64_4K_PAGES. Para el espacio de usuario, define en el producto:

PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true para retirar PAGE_SIZE y forzar a consultar en runtime.
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384 para compilar ELF con alineación 16 KB y facilitar compatibilidad futura.

Tras seleccionar el objetivo (lunch), verifica las banderas de build:

$ source build/envsetup.sh
$ lunch <target>
$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
true

Aunque la compilación pase, pueden persistir diferencias de tiempo de ejecución en 16 KB, así que hay que probar a fondo y revisar alineaciones y llamadas a mmap().

Programación eficiente con páginas de 16 KB

La mayoría del código Android no gestiona páginas directamente, pero si tratas con memoria, cambia el comportamiento del kernel: siempre redondea al tamaño de página. En 4 KB, asignar 1–4 KB consume 4 KB; en 16 KB, 1–5 KB consume 16 KB y 17 KB, 32 KB.

Procura redondear tus tamaños antes de llamar a mmap() y, cuando puedas, consolida regiones RW para aprovechar una única página y reducir desperdicio. Además, en sistemas optimizados, las tablas de páginas son un cuarto del tamaño para la misma memoria al usar páginas de 16 KB, lo que compensa en parte el mayor granulado.

Verificación de binarios y prebuilts

Más allá de probar en kernel de 16 KB, desde Android 16 puedes activar PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true para validar prebuilts en build time. Si necesitas ignorarlo temporalmente, usa ignore_max_page_size: true en Android.bp o LOCAL_IGNORE_MAX_PAGE_SIZE := true en Android.mk.

En dispositivos lanzados con Android 15+, ejecuta atest elf_alignment_test para verificar la alineación de ELF en el propio dispositivo, y captura resultados para tu pipeline de CI.

Errores frecuentes y soluciones

Instala en local pero falla desde Play: típico de zipalign a 16 KB ausente en builds generados desde App Bundle (AGP 8.3–8.5). Sube a AGP ≥ 8.5.1 o, temporalmente, empaqueta jniLibs comprimidas y valida de nuevo.
INSTALL_FAILED_INVALID_APK / unsupported ELF page size: tus .so están a 4 KB. Actualiza NDK (mejor r27/r28), limpia y recompila, y confirma con readelf align 2**14.
readelf falla o muestra cabecera corrupta: probablemente inspeccionas un archivo mal extraído. Extrae el APK con unzip a una carpeta, ve a lib/arm64-v8a y ejecuta readelf sobre el .so correcto.
Funciona en emulador pero no en dispositivo 16 KB: suele ser un SDK de terceros desactualizado. Identifica la .so problemática con logcat, actualiza la dependencia o retírala si no hay versión compatible.
Sigue el aviso en Play Console tras recompilar: queda alguna .so a 4 KB en el AAB. Usa bundletool para generar .apks, descomprime y pasa readelf/zipalign a todas las .so hasta que la última cumpla.

Checklist práctico antes de publicar

AGP ≥ 8.5.1 o, temporalmente, jniLibs comprimidas con useLegacyPackaging.
NDK r28+ (o r27 con flags) y, si procede, -Wl,-z,max-page-size=16384 en el enlace.
Todas las .so con LOAD align 2**14 (arm64-v8a/x86_64) y APK zipalineado a 16 KB.
Sin suposiciones de 4 KB en el código; usas getpagesize()/sysconf.
Pruebas en emulador/dispositivo 16 KB y verificación con adb getconf PAGE_SIZE = 16384.

Publicación en Google Play con menos riesgo

Sube primero a Open testing para captar feedback temprano, luego a Closed testing con grupos acotados, y finalmente promueve a Producción cuando valides estabilidad. En las notas de versión, comunica que has añadido compatibilidad con Android 15 y páginas de 16 KB para dar contexto a usuarios y revisores.