Compatibilidad con tamaños de página de 16 KB

Históricamente, Android solo admitió tamaños de página de memoria de 4 KB, lo que optimizó el rendimiento de la memoria del sistema para la cantidad promedio de memoria total que suelen tener los dispositivos Android. A partir de Android 15, el AOSP admite dispositivos configurados para usar un tamaño de página de 16 KB (dispositivos de 16 KB). Si tu app usa alguna biblioteca del NDK, ya sea directamente o a través de un SDK, deberás volver a compilarla para que funcione en estos dispositivos de 16 KB.

A medida que los fabricantes de dispositivos sigan creando dispositivos con mayores cantidades de memoria física (RAM), muchos de estos dispositivos adoptarán tamaños de página de 16 KB (y, con el tiempo, incluso mayores) para optimizar el rendimiento del dispositivo. Agregar compatibilidad con dispositivos con tamaño de página de 16 KB permite que tu app se ejecute en estos dispositivos y se beneficie de las mejoras de rendimiento asociadas. Sin recompilación, las apps no funcionarán en dispositivos de 16 KB en futuras versiones de Android.

Para ayudarte a agregar compatibilidad con tu app, te proporcionamos orientación sobre cómo comprobar si tu app se ve afectada, cómo volver a compilar tu app (si corresponde) y cómo probar tu app en un entorno de 16 KB con emuladores (incluidas las imágenes del sistema de Android 15 para Android Emulator).

Requisito de compatibilidad con Google Play

Para garantizar que tu app funcione correctamente en las versiones más recientes de Android, todas las apps segmentadas para Android 15 (nivel de API 35) y versiones posteriores deben admitir tamaños de página de memoria de 16 KB en dispositivos de 64 bits en Google Play. A partir del 1 de febrero de 2027, si las actualizaciones de tu app no admiten tamaños de página de 16 KB de memoria, no podrás lanzarlas.

Beneficios y mejoras en el rendimiento

Los dispositivos configurados con tamaños de página de 16 KB usan un poco más de memoria en promedio, pero también obtienen varias mejoras de rendimiento para el sistema y las apps:

• Tiempos de inicio de la app más bajos mientras el sistema está bajo presión de memoria: un 3.16% más bajo en promedio, con mejoras más significativas (hasta un 30%) para algunas apps que probamos
• Menor consumo de energía durante el lanzamiento de la app: Reducción promedio del 4.56%
• Inicio más rápido de la cámara: Inicios en caliente un 4.48% más rápidos en promedio y, en promedio, un 6.60% más rápidos en frío
• Mejor tiempo de inicio del sistema: se mejoró en un 8% (aproximadamente 950 milisegundos) en promedio.

Estas mejoras se basan en nuestras pruebas iniciales, y es probable que los resultados en los dispositivos reales difieran. Proporcionaremos análisis adicionales de posibles ganancias para las apps a medida que continuemos con las pruebas.

Verifica si tu app se ve afectada

Si tu app usa código nativo, debes recompilarla para que sea compatible con dispositivos de 16 KB. Si no sabes con seguridad si tu app usa código nativo, puedes usar el Analizador de APK para identificar si hay código nativo presente y, luego, verificar la alineación de los segmentos ELF de las bibliotecas compartidas que encuentres. Android Studio también proporciona funciones que te ayudan a detectar automáticamente problemas de alineación.

Si tu app solo usa código escrito en el lenguaje de programación Java o en Kotlin, incluidas todas las bibliotecas o SDKs, ya es compatible con dispositivos de 16 KB. Sin embargo, te recomendamos que pruebes tu app en un entorno de 16 KB para verificar que no haya regresiones inesperadas en el comportamiento de la app.

¿Tu app usa código nativo?

Tu app usa código nativo si se aplica alguna de las siguientes opciones:

• Tu app usa cualquier código (nativo) C/C++. Si tu app usa el NDK de Android, significa que usa código nativo.
• Tu app se vincula con bibliotecas o dependencias nativas de terceros (como SDKs) que las usan.
• Tu app se compiló con un creador de apps de terceros que usa bibliotecas nativas en el dispositivo.

Identifica bibliotecas nativas con el Analizador de APK

El Analizador de APK es una herramienta que te permite evaluar varios aspectos de un APK compilado. Para verificar si tu app usa código nativo (independientemente de si es compatible con 16 KB), sigue estos pasos:

1. Abre Android Studio, haz clic en File > Open y elige cualquier proyecto.

2. En la barra de menú, haz clic en Build > Analyze APK…

   

3. Elige el APK que quieras analizar.

4. Busca en la carpeta lib, que aloja archivos de objetos compartidos (.so) si hay alguno. Si hay archivos de objetos compartidos, tu app usa código nativo. En la columna Alineación, se muestran mensajes de advertencia para los archivos que tienen problemas de alineación. Si no hay archivos de objetos compartidos o no hay una carpeta lib, tu app no usa código nativo.

   

Detecta problemas de alineación con verificaciones automáticas

Android Studio te advierte de forma proactiva si tus bibliotecas o APKs compilados previamente no son compatibles con 16 KB. Usa la herramienta Analizador de APK para revisar qué bibliotecas se deben actualizar o si se requieren cambios en el código.

Lint en Android Studio también destaca las bibliotecas nativas que no están alineadas con 16 KB.

Verifica la alineación de los segmentos ELF para las bibliotecas compartidas

En el caso de las bibliotecas compartidas, verifica que los segmentos ELF de las bibliotecas compartidas estén alineados correctamente con una alineación ELF de 16 KB. Si desarrollas en Linux o macOS, puedes usar la secuencia de comandos check_elf_alignment.sh como se describe en la siguiente sección. También puedes usar las herramientas de línea de comandos directamente.

Usa el script check_elf_alignment.sh (Linux o macOS)

Sigue estos pasos para verificar la alineación de los segmentos ELF con la secuencia de comandos check_elf_alignment.sh:

1. Guarda la secuencia de comandos check_elf_alignment.sh en un archivo.

2. Ejecuta la secuencia de comandos en el archivo APK de tu app:

   check_elf_alignment.sh APK_NAME.apk
   

   La secuencia de comandos genera ALIGNED o UNALIGNED para todas las bibliotecas compartidas arm64-v8a.

3. Si alguna biblioteca compartida arm64-v8a o x86_64 es UNALIGNED, deberás actualizar el empaquetado de esas bibliotecas, volver a compilar la app y volver a realizar la prueba siguiendo los pasos de esta sección.

Usa herramientas de línea de comandos directamente

Sigue estos pasos para verificar la alineación de los segmentos ELF con las herramientas de línea de comandos directamente:

1. Asegúrate de que SDK Build-Tools de Android versión 35.0.0 o posterior y NDK de Android estén instalados con SDK Manager en Android Studio o la herramienta de línea de comandos sdkmanager.

2. Extrae el archivo APK de tu app:

   Linux o macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. En el directorio temporal en el que extrajiste el archivo APK, verifica el contenido del directorio lib para ver los archivos de objetos compartidos (.so). Estos son los mismos archivos de objetos compartidos que habrías visto cuando identificaste bibliotecas nativas con el Analizador de APK. Ejecuta el siguiente comando en cada archivo de objeto compartido:

   Linux o macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Donde SDK_ROOT_LOCATION es la ruta de acceso al directorio en el que instalaste el SDK de Android, SHARED_OBJECT_FILE es el nombre del archivo de objeto compartido que estás verificando y NDK_VERSION es la versión del NDK de Android que tienes instalada (por ejemplo, 28.0.12433566). El resultado será similar al siguiente para cada archivo que verifiques:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Verifica las líneas de salida para asegurarte de que los segmentos de carga no tengan valores inferiores a 2**14. Si algún segmento de carga tiene valores 2**13, 2**12 o inferiores, deberás actualizar el empaquetado de esas bibliotecas, volver a compilar la app y volver a realizar la prueba siguiendo los pasos de esta sección.

5. A continuación, ejecuta la herramienta de línea de comandos de zipalign en el archivo APK de tu app:

   Linux o macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   Donde SDK_ROOT_LOCATION es la ruta de acceso al directorio en el que instalaste el SDK de Android y APK_NAME es el nombre del archivo APK de tu app. La última línea del resultado dirá "Verification successful" si todas las bibliotecas compartidas están alineadas correctamente.

   Si la verificación falló, algunas bibliotecas compartidas deben realinearse, por lo que deberás actualizar el empaquetado de esas bibliotecas, volver a compilar la app y volver a probarla siguiendo los pasos de esta sección.

Cómo verificar la marca de seguridad RELRO

Para mitigar las vulnerabilidades de seguridad, los vinculadores modernos usan la marca Relocation Read-Only (RELRO) para que las secciones de reubicación del archivo de objeto compartido sean de solo lectura después de la carga. Habilita la marca RELRO en tu compilación.

Una sección RELRO que tiene una dirección de inicio más un tamaño de segmento (MemSize) que no está alineado con 16 KB provoca que la app falle durante el tiempo de ejecución con un error de segmentación. Esto sucede si el archivo .so se compiló con la cadena de herramientas del NDK r27 y versiones anteriores sin habilitar las marcas pertinentes.

Ejecuta el siguiente comando en cada archivo de objeto compartido (Linux o macOS):

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

La cadena GNU_RELRO se imprime si hay un segmento RELRO.

A continuación, verifica la alineación del segmento RELRO sumando su dirección de desplazamiento virtual (VirtAddr) con el tamaño de la memoria del segmento (MemSiz) y dividiendo por 16 KB (0x4000). Si el resto (módulo) es cero, el segmento RELRO está alineado con 16 KB.

Este es un ejemplo de un archivo .so no alineado:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

Fórmula: (VirtAddr + MemSiz) % 0x4000 == 0

Resultado: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

Como 0x1000 no es cero, este archivo .so no es compatible con 16 KB. El rango de protección de RELRO de DC000 (el salto de página anterior) a E4000 es de solo lectura, pero el vinculador de Android espera que el subrango de E1000 a E4000 sea de escritura, lo que genera un error de segmentación. En este caso, vuelve a compilar el archivo .so como se describe en la sección Cómo compilar tu app con la alineación de ELF de 16 KB.

A continuación, se muestra un ejemplo de un archivo .so alineado, con un segmento RELRO:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

A continuación, se muestra un ejemplo de un archivo .so sin un segmento RELRO:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align

Este es un archivo .so trivialmente compatible con 16 KB sin ningún segmento de RELRO.

A continuación, se muestra un ejemplo de un archivo .so alineado en el que GNU_RELRO se encuentra en su propio segmento LOAD:

Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000680 0x000680 R E 0x4000
LOAD           0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 RW  0x4000
GNU_RELRO      0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 R   0x1

Fórmula: (VirtAddr + MemSiz) % 0x4000 == 0

Resultado: (0x4680 + 0x0980) % 0x4000 = 0x5000 % 0x4000 == 0x1000

Aunque 0x1000 no es cero, este archivo .so sigue cumpliendo con los requisitos de 16 KB.

La fórmula de módulo se aplica cuando GNU_RELRO comparte un segmento LOAD con datos de escritura posteriores (como .data o .bss).

Para verificar si GNU_RELRO está en su propio segmento LOAD, inspecciona los encabezados del programa ejecutando llvm-readelf -Wl y filtrando con grep 'LOAD\|RELRO\|Type'. Compara el VirtAddr y el MemSiz de GNU_RELRO con el segmento LOAD que lo contiene. En este ejemplo, ambos tienen VirtAddr 0x4680 y MemSiz 0x0980.

Debido a que todo el segmento LOAD contiene solo datos de RELRO, no hay datos que se puedan escribir en el rango secundario de 0x5000 a 0x8000. Además, cualquier segmento LOAD de escritura posterior comienza en un límite de página de 16 KB independiente (en 0x8000 o más allá). La protección de solo lectura del vinculador no se superpondrá con ningún dato de escritura, por lo que no se producirá ningún error de segmentación.

Compila tu app para que sea compatible con dispositivos de 16 KB

Si tu app usa código nativo, completa los pasos que se describen en las siguientes secciones para asegurarte de que admita dispositivos de 16 KB:

1. Actualiza el empaquetado de tus bibliotecas compartidas
2. Compila tu app con la alineación de ELF de 16 KB
3. Corrige el código y resuelve los problemas de tiempo de ejecución
4. Optimiza los asignadores de memoria personalizados (si corresponde)
5. Cómo verificar si los SDKs admiten 16 KB

Actualiza el empaquetado de tus bibliotecas compartidas

Actualiza a la versión 8.5.1 o posterior del AGP y usa bibliotecas compartidas sin comprimir.

Usa bundletool para verificar la alineación del archivo ZIP

Para ver la alineación de tu paquete, usa lo siguiente:

bundletool dump config --bundle=<my .aab>  | grep alignment

Si ves PAGE_ALIGNMENT_16K, significa que tu paquete solicita una alineación de ZIP de 16 KB. Si ves PAGE_ALIGNMENT_4K, esto indica que el APK compilado a partir de este AAB debe tener archivos .so alineados de 4 KB en el archivo ZIP.

AGP versión 8.5.1 o posterior

Los dispositivos de 16 KB requieren que las apps que se envían con bibliotecas compartidas sin comprimir las alineen en un límite alineado en zip de 16 KB. Para ello, debes actualizar al complemento de Android para Gradle (AGP) versión 8.5.1 o posterior. Consulta la sección Asistente de actualización del complemento de Android para Gradle para obtener detalles sobre el proceso de actualización.

AGP versión 8.5 o anterior

Si no puedes actualizar AGP a la versión 8.5.1 o posterior, la alternativa es cambiar a bibliotecas compartidas comprimidas. Actualiza tu configuración de Gradle para que este comprima tus bibliotecas compartidas cuando empaquete tu app y, así, evitar problemas de instalación de la app con bibliotecas compartidas no alineadas.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP versión 8.0 o anterior

Si usas una versión de AGP igual o anterior a la 8.0, también debes inhabilitar la opción de biblioteca nativa sin comprimir para los paquetes de aplicaciones en tu archivo gradle.properties:

android.bundle.enableUncompressedNativeLibs=false

Compila tu app con la alineación de ELF de 16 KB

Los dispositivos de 16 KB requieren que los segmentos ELF de las bibliotecas compartidas estén alineados correctamente con la alineación ELF de 16 KB para que se ejecute tu app.

Si eres desarrollador de juegos y tu juego se ejecuta sobre el motor de juegos de Unity, consulta la guía de Unity. Si tu juego se ejecuta sobre el motor de juegos de Unreal, consulta la guía de Unreal.Si usas motores de juegos nativos, continúa con esta guía.

Para compilar tu app con la alineación de ELF de 16 KB, completa los pasos de una de las siguientes secciones según la versión del NDK de Android que uses.

NDK de Android r28 y versiones posteriores

Las versiones r28 y posteriores del NDK compilan con una alineación de 16 KB de forma predeterminada.

NDK de Android r27 y versiones anteriores

Para admitir la compilación de bibliotecas compartidas alineadas con 16 KB con la versión r27 o anterior del NDK de Android, usa las siguientes marcas de vinculador:

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

Sigue estos pasos para actualizar los archivos de configuración del sistema de compilación:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

Corregir código y resolver problemas de tiempo de ejecución

Incluso si tu app está alineada con 16 KB, puede tener errores si hay partes del código que suponen que un dispositivo usa un tamaño de página específico. Para evitarlo, completa los siguientes pasos:

1. Quita las dependencias hard-coded que hagan referencia a la constante PAGE_SIZE o a las instancias de la lógica de tu código que supongan que el tamaño de página de un dispositivo es de 4 KB (4096).

   En su lugar, usa getpagesize() o sysconf(_SC_PAGESIZE).

2. Busca usos de mmap() y otras APIs que requieran argumentos alineados con la página, y reemplázalos por alternativas cuando sea necesario.

En algunos casos, si tu app usa PAGE_SIZE como un valor conveniente que no está vinculado al tamaño de página subyacente, esto no provocará que la app falle cuando se use en el modo de 16 KB. Sin embargo, si este valor se pasa al kernel con mmap sin MAP_FIXED, el kernel sigue usando una página completa, lo que desperdicia algo de memoria. Por estos motivos, PAGE_SIZE no se define cuando el modo de 16 KB está habilitado en el NDK r27 y versiones posteriores.

Si tu app usa PAGE_SIZE de esta manera y nunca pasa este valor directamente al kernel, en lugar de usar PAGE_SIZE, crea una variable nueva con un nombre nuevo para reflejar que se usa con otros fines y no refleja una página de memoria real.

Optimiza los asignadores de memoria personalizados

En los sistemas de 16 KB, la unidad más pequeña de memoria física que asigna el sistema operativo es cuatro veces más grande que en los sistemas de 4 KB. Si se diseñó un asignador personalizado en función de suposiciones de 4 KB, puede dispersar objetos pequeños en varias páginas de 16 KB y retener memoria vacía de forma innecesaria. Esto puede aumentar de forma considerable el uso de memoria física (RSS) y degradar la eficiencia del intercambio comprimido (ZRAM).

Si tu código administra sus propios grupos de memoria, sigue estas recomendaciones:

1. Evita los umbrales de bytes hard-coded para liberar memoria

Muchos asignadores usan límites de bytes fijos para decidir cuándo liberar memoria de vuelta al SO con madvise(MADV_DONTNEED) (por ejemplo, solo liberar memoria si los objetos activos ocupan menos de 8 KB).

En un sistema de 16 KB, incluso un solo objeto activo de 16 bytes fija una página completa de 16 KB (que es mayor que 8 KB). Como resultado, nunca se alcanza el umbral de liberación y el asignador nunca devuelve la memoria no utilizada circundante al kernel.

Qué hacer: Nunca uses constantes de bytes hard-coded para la heurística de liberación de páginas. Escala los umbrales de liberación de forma dinámica en el entorno de ejecución según el tamaño real de la página con sysconf(_SC_PAGESIZE).

2. Completar primero las páginas ya utilizadas (asignación de densidad primero)

Si un asignador distribuye la memoria en orden primero en entrar, primero en salir (FIFO) o por turnos, las asignaciones nuevas se dispersan en muchas páginas de 16 KB parcialmente completas. Un solo objeto en una página mantiene los 16 KB residentes en la RAM física.

Qué hacer: Asigna siempre objetos nuevos de la página o losa más llena (más densa) antes de tocar páginas vacías o poco usadas. Concentrar las asignaciones nuevas en páginas que ya están sucias permite que las páginas que se usan poco se vacíen de forma natural hasta que no tengan objetos activos, de modo que se pueda liberar toda la página de 16 KB para el SO.

3. Alinea los grupos de memoria con 16 KB y mantén los tamaños de los grupos moderados

Los tramos de varias páginas diseñados para sistemas de 4 KB pueden contener un exceso de memoria no liberada en kernels de 16 KB. Además, las clases de tamaño que no se dividen de manera uniforme en 16 KB causan fragmentación al final de cada página.

Qué hacer:

• Asegúrate de que todos los grupos de memoria, los límites de slab y las alineaciones de búfer sean múltiplos exactos del tamaño de la página del entorno de ejecución.
• Vuelve a evaluar los tamaños de los intervalos de varias páginas para las clases de objetos pequeños para evitar asignar slabs demasiado grandes que atrapen la memoria inactiva.

4. Libera la memoria física de los búferes grandes almacenados en caché de inmediato

Los asignadores personalizados suelen almacenar en caché búferes grandes (> 64 KB) en un grupo en la memoria para que se puedan volver a usar sin pagar la sobrecarga de las llamadas al sistema mmap o munmap. Sin embargo, mantener estos búferes sucios en la memoria desperdicia megabytes de RAM física mientras se espera un temporizador de expulsión.

Qué hacer: Mantén el rango de direcciones de memoria virtual reservado para una reutilización rápida, pero llama a madvise(..., MADV_DONTNEED) o madvise(..., MADV_FREE) de inmediato cuando devuelvas un búfer a la caché. El sistema operativo reclama la RAM física de inmediato, mientras que tu app puede reutilizar la dirección virtual al instante sin reasignarla.

5. Se puso en cero la memoria en la liberación en lugar de en la asignación para la compresión de ZRAM.

Android usa el espacio de intercambio comprimido (ZRAM) para mantener las apps en segundo plano en la memoria. En los dispositivos de 16 KB, si una página contiene incluso un objeto activo, toda la página de 16 KB permanece residente o se intercambia a ZRAM. Los datos basura restantes (como punteros y cadenas obsoletos) en partes liberadas previamente de esa página se comprimen de forma deficiente.

Si tu asignador pone en cero la memoria (por ejemplo, para asignaciones de seguridad o inicializadas en cero), considera poner en cero la memoria al liberar la asignación (free()) en lugar de al asignarla:

• Las páginas fijadas cuestan menos: La memoria inactiva en las páginas de 16 KB parcialmente llenas se comprime casi por completo en ZRAM, por lo que las páginas fijadas no desperdician espacio de intercambio físico.
• Sobrecarga de caché mínima: En el momento en que se llama a free(), la memoria ya está activa en la caché de la CPU, lo que evita errores de caché adicionales más adelante.

Resumen de recomendaciones

Verifica si los SDKs admiten 16 KB

Muchos SDKs son compatibles con tamaños de página de 16 KB, en especial si los compilas tú mismo o obtienes compilaciones previas recientes. Sin embargo, como algunas versiones o compilaciones previas de SDK no son compatibles con 16 KB, debes consultar el sitio web de cada proveedor de SDK para determinar qué versión usar con 16 KB.

Prueba tu app en un entorno de 16 KB

Después de compilar tu app con compatibilidad para dispositivos de 16 KB, te recomendamos que la pruebes en un entorno de 16 KB para ver si experimenta alguna regresión. Para hacerlo, sigue estos pasos:

1. Configura el SDK de Android 15 o una versión posterior.

2. Configura uno de los siguientes entornos de pruebas:

   • Configura Android Emulator con una imagen del sistema de Android 15 basada en 16 KB
   • Cómo usar Cuttlefish con un tamaño de página de 16 KB en ARM64
   • Cómo simular Cuttlefish con un tamaño de página de 16 KB en x86-64
   • Cómo habilitar el modo de 16 KB en un dispositivo con las opciones para desarrolladores
   • Usa Samsung Remote Test Lab en 16 KB dispositivos compatibles

3. Inicia el dispositivo de prueba y, luego, ejecuta el siguiente comando para verificar que use un entorno de 16 KB:

   adb shell getconf PAGE_SIZE
   

   El comando debería devolver un valor de 16384.

4. Ejecuta el siguiente comando zipalign para verificar que tu app esté alineada en bloques de 16 KB, donde APK_NAME es el nombre del archivo APK de tu app:

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

5. Prueba tu app de forma exhaustiva y enfócate en las áreas que podrían verse afectadas por el cambio de instancias de código que hacen referencia a tamaños de página específicos.

Configura Android Emulator con una imagen del sistema basada en 16 KB

Para configurar un entorno de 16 KB con Android Emulator, sigue estos pasos:

1. En Android Studio, haz clic en Tools > SDK Manager.

2. En la pestaña SDK Platforms, selecciona Show Package Details, luego expande la sección Android VanillaIceCream o una posterior y selecciona una o ambas de las siguientes imágenes del sistema del emulador, según los dispositivos virtuales que quieras crear:

   • Imagen del sistema ARM 64 v8a con tamaño de página de 16 KB experimental de las APIs de Google
   • Imagen del sistema Intel x86_64 Atom con tamaño de página de 16 KB experimental de las APIs de Google

   

3. Haz clic en Aplicar > Aceptar para descargar las imágenes del sistema que seleccionaste.

4. Sigue los pasos para configurar un dispositivo virtual para Android 15 y, cuando se te solicite que selecciones una imagen del sistema, elige la imagen del sistema de 16 KB que descargaste. Si no se recomienda automáticamente, puedes encontrar la imagen del sistema de 16 KB en la pestaña Otras imágenes.

   

Inicia el emulador

Después de configurar Android Emulator y los dispositivos virtuales, inicia el emulador desde el menú del dispositivo de destino o desde la línea de comandos.

Habilita el modo de 16 KB en un dispositivo con las opciones para desarrolladores

Activa la opción para desarrolladores Iniciar con tamaño de página de 16 KB para iniciar un dispositivo en el modo de 16 KB.

En las versiones de QPR de Android 15, puedes usar la opción para desarrolladores disponible en ciertos dispositivos para iniciar el dispositivo en modo de 16 KB y realizar pruebas en el dispositivo. Antes de usar la opción para desarrolladores, ve a Configuración > Sistema > Actualizaciones de software y aplica las actualizaciones disponibles.

Esta opción para desarrolladores está disponible en los siguientes dispositivos:

• Pixel 8 y 8 Pro (con Android 15 QPR1 o versiones posteriores)

• Pixel 8a (con Android 15 QPR1 o versiones posteriores)

• Pixel 9, 9 Pro y 9 Pro XL (con Android 15 QPR2 o versiones posteriores)

• Pixel 9a (con Android 16 o versiones posteriores)

Modo de retrocompatibilidad de 16 KB

Advertencia en el modo de compatibilidad de tamaño de página

La opción de retrocompatibilidad de 16 KB está disponible cuando un dispositivo se ejecuta con un kernel de 16 KB. El administrador de paquetes ejecuta una app en el modo de retrocompatibilidad de 16 KB cuando se cumplen las siguientes condiciones:

• Si la app tiene archivos ELF (con una extensión .so) con una alineación de segmento LOAD de 4 KB
• Si el APK comprimido tiene archivos ELF sin comprimir que están alineados con ZIP de 4 KB

Si el administrador de paquetes habilitó el modo de retrocompatibilidad de 16 KB para una app, esta mostrará una advertencia cuando se inicie por primera vez indicando que se está ejecutando en el modo de retrocompatibilidad de 16 KB.

El modo de retrocompatibilidad de 16 KB permite que funcionen algunas apps, pero, para obtener la mejor confiabilidad y estabilidad, las apps deben seguir alineadas con 16 KB.

En la página de información de la app, en Avanzado, activa o desactiva el parámetro de configuración Ejecutar app en modo de compatibilidad de tamaño de página para habilitar o inhabilitar el modo de retrocompatibilidad de 16 KB para una app específica. Este parámetro de configuración solo se muestra cuando el dispositivo se ejecuta con un tamaño de página de 16 KB.

Parámetro de configuración del modo de compatibilidad con el tamaño de página

Para forzar la retrocompatibilidad de 16 KB en todas las apps del dispositivo, haz lo siguiente:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

Para forzar la desactivación de la retrocompatibilidad de 16 KB para todas las apps del dispositivo, haz lo siguiente:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

En Android 17, también puedes forzar la desactivación de la retrocompatibilidad de 16 KB para cada app y hacer que cualquier archivo binario incompatible se anule de inmediato:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

Establece la propiedad android:pageSizeCompat como habilitada o inhabilitada para activar o desactivar el modo de retrocompatibilidad de una app específica en su AndroidManifest.xml. Cuando se establece esta propiedad, la app no mostrará advertencias sobre el modo de compatibilidad con versiones anteriores cuando se inicie.