Android supports 16KB memory pages: real impact and what to do

Android jumps to 16KB memory pages And that's not a minor change for the developer. Behind it is a low-level adjustment in how the system manages RAM This can translate into faster app launches, lower power consumption, and more responsive devices, especially on modern hardware with more memory. If you work with NDKs, game engines, or SDKs that include .so files, this move affects you directly.

In the next versions, More and more devices will come configured for 16 KB And Google Play will set the pace with a specific requirement: if your app targets Android 15 or higher, it must be compatible. Here, you'll find, without further ado, what's changing, why it's important, who's affected, how to detect it in your APK or AAB, what to update in AGP and NDK, how to test on emulators and Pixels, compatibility mode, and key release dates.

What is a page of memory and why does Android move to 16 KB?

A page is the unit with which the operating system allocates and manages RAM. Android has historically been optimized for 4KB because it was the usual thing in kernels and devices. ARM CPUs They also support 16KB, and starting with Android 15, AOSP allows the system to be configured to use 16KB pages on arm64, while maintaining compatibility with 4KB or 16KB kernels starting with android14-6.1.

The change has a trade-off: slightly more memory is used on average, but page table accounting is reduced and memory and I/O efficiency is improved. With more RAM in current terminals, the balance is balanced. Furthermore, the 16KB ELF alignment in user space allows the same binary to run on both 4KB and 16KB kernels when properly aligned.

Measured benefits and associated costs

Google's internal testing indicates clear improvements: app launches by 3,16% on average faster, with cases approaching 30% in certain apps. When launching apps, power consumption is reduced by around 4,56%.

Impacts on performance-sensitive system functions have also been observed: The camera starts 4,48% faster when hot and 6,60% faster when cold, and system boot time improves by about 8% (around 950 ms). Other published analyses report overall gains of 5–10% at the cost of about 9% more RAM.

Who does it really affect?

If your app uses native C or C++ code If you are using the NDK, linking with third-party .so libraries, integrating engines like Unity or Unreal, or relying on SDKs that include .so files, you should recompile and align to 16KB. If you suspect high usage, check out how to identify applications that consume a lot of memoryApps written solely in Java or Kotlin, including their dependencies, are now supported, although it's a good idea to test under 16KB to avoid surprises.

Note that Many modern SDKs already offer compatible builds And, according to various media outlets, many popular apps and frameworks like Flutter and React Native have been adapting. Still, it's critical to verify every .so file you package.

How to know if your app uses native and is affected

First, check if the APK or AAB contains .so. APK Analyzer in Android Studio makes it easy: Build → Analyze APK, navigate to lib, and check if there are shared objects in arm64-v8a or x86_64. If there are .so files, there's native. The Alignment column displays warnings when it detects problems with 16KB.

Furthermore, Lint warns of unaligned native libraries within 16KBIt's a quick way to see which dependencies or modules need attention even before compiling a final build.

Check ELF alignment and packaging

The key point is that the LOAD segments of your .so are aligned to 16 KB and the resulting APK is zip-aligned to 16 KB when you don't compress jniLibs.

• Official script check_elf_alignment.sh on Linux or macOS – Analyzes an APK and marks each .so as ALIGNED or UNALIGNED for arm64-v8a and x86_64.
• command line tools: Extract the APK, locate the .so files in lib, and examine the LOAD segments with readelf. Look for align 2**14.
• zipalign: Validates that the APK is 16KB aligned when not compressing shared libraries.

# Comprobar segmentos de carga y su alineación
readelf -l ruta/libmilib.so | grep LOAD
# Ejemplo de salida válida (alineación 16 KB)
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
LOAD off 0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14

# Verificar zipalign del APK en 16 KB
zipalign -c -P 16 -v 4 MiApp.apk
# Debe terminar con Verification successful

If you see align 213, 212 or lower, or if zipalign fails, that library or packaging does not comply. Recompile, fix flags, and recheck before publishing.

Update your toolchain: AGP, NDK and necessary flags

For 16KB devices there are two mandatory fronts: ELF alignment of the .so y APK ZIP alignment when you distribute uncompressed jniLibs.

Android Gradle Plugin 8.5.1 or higher

With uncompressed libraries, 16KB devices require the APK to be zip-aligned to 16KB. AGP 8.5.1 or later does this by default. And it's the recommended route. If you're working with AGP 8.3 to 8.5, there's a known pitfall: bundletool doesn't zip by default, and you might see that everything looks correct locally, but the build distributed from Play fails to install.

If you can't upgrade to 8.5.1 yet, there is a temporary plan B: Package compressed libraries to avoid the 16KB zip-align requirement. In Gradle, you can force legacy packaging of jniLibs.

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

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

Be careful with this approach: When compressing .so the installer must extract and copy them, which increases the footprint and can increase the installation failure rate due to insufficient storage. The solid solution is to upgrade to AGP 8.5.1 or higher.

NDK and linked to 16 KB

• NDK r28 or later: compiles by default with 16 KB alignment. This is the ideal option.
• NDK-r27: Allow 16KB by adding the appropriate flags in ndk-build, CMake or directly to the linker.
• NDK r26 and earlier: Not recommended. It can be forced, but support is not guaranteed. In R22 and earlier, common-page-size=16384 may be required due to historical bugs in ld and lld, and due to the ELF including .relro_padding with LLD 18 or higher.

# Flag estándar de vinculador para máximo tamaño de página
-Wl,-z,max-page-size=16384

If your app dynamically links with old libc++_shared.so If you're using NDK r26 or earlier, you run the risk of the installation failing on 16KB devices. The recommendation is to migrate to NDK r27 or r28; as a temporary alternative, you can statically link the STL into your library, weighing the pros and cons of maintenance and size.

Fix 4KB assumptions in your code

Even if you align correctly, you may experience crashes or leaks if you assume PAGE_SIZE is 4096. Avoid relying on PAGE_SIZE rigidly; in NDK r27 and later, below 16KB it is not even defined to prevent misuse.

Get the actual size at runtime with getpagesize or sysconf, and check mmap calls and APIs that require page-aligned arguments. If you request 1–5 KB, the kernel will still allocate 16 KB for 16 KB; when feasible, combines regions RW to take advantage of a single page and reduce waste.

// Ejemplos en C/C++
long sz = getpagesize();
// o
long sz2 = sysconf(_SC_PAGESIZE);
// Usa sz en lugar de valores fijos al calcular offsets, tamaños y alineaciones

Testing in 16 KB environment

After recompiling, it is time to validate thoroughly. Configure Android 15 in the SDK and creates a 16KB image-based AVD. Android Studio Jellyfish 2023.3.1 or higher supports it; for the best experience, Ladybug 2024.2.1 or higher is recommended.

In SDK Manager, under SDK Platforms, show details and, under Android VanillaIceCream or later, select the 16 KB images you need: ARM 64 v8a Google APIs Experimental or x86_64 Google APIs Experimental 16 KB Page Size. If you're emulating a compatible Pixel, ARM 64 v8a is sufficient.

Note on emulator and debugging

Between emulator versions 35.1.5 and 35.1.20 and before revision 4 of the 16KB Android 15 images, on x86_64 there is an extra step: edit config.ini of the AVD and include the kernel parameter.

# Edita config.ini del AVD
añade esta línea y guarda
kernel.parameters = androidboot.page_shift=14

# Verifica el entorno de 16 KB
a db shell getconf PAGE_SIZE
16384

There is a known issue with LLDB in 16 KB images, which has been addressed in NDK r27 RC1 and Android Studio Koala 2024.1.2 Canary 5. Keep your tools up to date for frictionless debugging.

Testing on real hardware and developer options

Starting with Android 15 QPR1, select devices include a toggle to boot at 16KB. Pixel 8, 8 Pro and 8a with 15 QPR1, and Pixel 9, 9 Pro, and 9 Pro XL running QPR2 Beta 15 or higher, can be enabled from Developer Options. Make sure to apply system updates before testing.

# Comprueba el tamaño de página del dispositivo
adb shell getconf PAGE_SIZE
# Espera ver 16384

16KB Compatibility Mode

When the device runs a 16KB kernel, the Package Manager can activate a backward compatibility mode If it detects a .so file with 4KB LOAD segments or an APK with an uncompressed ELF file aligned to 4KB, the app will display a warning on first launch indicating that it's running in compatibility mode.

This mode allows some apps to work, but it is not the recommended option. For reliability and stability, align everything to 16 KBYou can enable or disable compatibility per app from the app's information, under Advanced, under Run app in page size compatibility mode, visible only on devices configured with 16 KB.

# Control global de compatibilidad en el dispositivo
adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

# Forzar desactivación global
adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

# A nivel de app en el manifest
android:pageSizeCompat

Google Play Dates and Requirements

To prepare the new devices, from November 1, 2025 All new apps and updates targeting Android 15 or higher must support 16KB pages on Google Play. Without this support, publishing may be blocked.

Several developers have received additional communications on Play Console placing a milestone around May 1, 2026 to tighten the blocking of non-compliant updates. Check your console and communications from Play to confirm which deadlines apply to you.

How to pack and check before boarding

Before publishing, make sure your APK or AAB is in order. Build, analyze and validate always in CI and locally.

• Build with AGP 8.5.1 or higher and NDK r28 whenever possible. If you're using r27, add 16KB flags when linking.
• Scan with APK Analyzer and Lint to find .so and alignment warnings.
• Use readelf to confirm align 2**14 in LOAD segments of all .so files.
• Validate zipalign at 16 KB with zipalign -c -P 16 -v 4.
• Install and test on an emulator or on a Pixel with 16KB enabled. Make sure PAGE_SIZE = 16384.

Common mistakes and how to solve them

• Installation from Play fails but it worked locally: This is usually due to a missed zipalign when generating from a bundle with AGP 8.3–8.5. Upgrade to AGP 8.5.1 or temporarily use compressed jniLibs and validate again.
• INSTALL_FAILED_INVALID_APK or unsupported ELF page size: : there is .so at 4 KB. Fix NDK r27 or r28, add -Wl,-z,max-page-size=16384 if applicable, clean and recompile.
• Works on emulator and fails on 16 KB device- Suspect outdated third-party SDKs. Identify the problematic .so file in logcat, update the dependency, or request a compatible build.
• The Play Console alert persists: There are some .so files remaining at 4KB in your AAB. Generate .apks with bundletool, extract them, and run readelf on all the .so files until you're sure they all show alignment 2**14.

For platform and OEM devices: kernel and user space

On arm64, you can compile the kernel in 16KB with Kleaf using the appropriate option or enabling CONFIG_ARM64_16K_PAGES instead of CONFIG_ARM64_4K_PAGES. In Android userspace, these product flags help enable 16 KB and future-proof:

PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384

After selecting the target with lunch, check the variables with get_build_var and confirm that they return 16384 and true respectively. Even if the compilation passes, runtime differences of up to 16KB can persist, so it is advisable to thoroughly test mmap, alignments, and assumptions on critical components.

Additional controls for prebuilts and tests

To reduce surprises with external binaries, you can enable PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE Since Android 16, this feature is used to validate prebuilts in builds. It can be temporarily ignored with ignore_max_page_size in Android.bp or LOCAL_IGNORE_MAX_PAGE_SIZE in Android.mk.

PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true
# Ignorar temporalmente en Android.bp
ignore_max_page_size: true
# Ignorar temporalmente en Android.mk
LOCAL_IGNORE_MAX_PAGE_SIZE := true

# Test de alineación en dispositivos lanzados con Android 15+
atest elf_alignment_test

Express compliance checklist

• AGP 8.5.1+ or compressed jniLibs as a temporary measure.
• NDK r28+ (or r27 with flags) and all .so with align 2**14.
• No 4KB assumptions in code; use getpagesize or sysconf.
• zipalign in 16 KB validated and tested on emulator and Pixel 16 KB.
• Native dependencies verified and updated to compatible builds.

Anyone developing apps with native should set aside some time for this adjustment, but the gain in performance and the guarantee of installation on new devices are worth the effort. With updated tools, systematic .so verification, correcting code assumptions, and testing at 16 KB, the same binary will work at both 4 KB and 16 KB.

Preparing your app now saves you publishing blocks on Play and allows you to offer faster launches, smoother transitions, and more targeted consumption on a daily basis. Share this information so that more users know about this topic..