The Android ecosystem is taking a significant step towards larger memory page sizes. The support for 16 KB pages in Android 15 changes how apps are packaged, aligned, and executed, especially if they include native code. If you develop with NDKs or use SDKs with .so libraries, this change directly affects you.
Beyond the headline, here you'll find a complete and practical explanation. We'll tell you what this change entails, the performance benefits measured by Google , how to know if your app is affected, what to adjust in your toolchain (AGP/NDK), how to test on emulators and devices with 16 KB, what compatibility mode is, and what the new Google Play requirements are, including key dates.
What exactly changes with 16 KB pages
Historically, Android was optimized for 4 KB pages because that was the most common size on devices and kernels . Starting with Android 15, AOSP enables device configurations with 16 KB pages (and even larger ones may be available in the future) to improve performance on modern hardware with more RAM.
This means that if your app uses native libraries (directly via the NDK or indirectly through SDKs or engines), you'll need to recompile and align your binaries to 16 KB , or your app won't install or run on devices configured with 16 KB in future Android versions. 100% Java/Kotlin apps are, in principle, already compatible, although it's advisable to test them in a 16 KB environment.
Additionally, Android 15 introduces 16KB ELF alignment in user space, compatible with 4KB or 16KB kernels (from Android 14-6.1 onwards), preparing OEMs and developers for the transition . This option is not always enabled by default, but can be activated in test environments and on certain devices via developer options.
Benefits and performance improvements you can expect
16 KB pages consume slightly more memory on average, but they offer advantages to the system and apps. Internal tests on Android 15 have shown the following indicative results: app launch times 3,16% faster on average (with improvements of up to 30% in some cases), a 4,56% reduction in power consumption during app launch, faster camera launches (4,48% faster when warm and 6,60% faster when cold), and an 8% improvement in system boot time (around 950 ms).
Other analyses published in the media also mention total gains of 5–10% at the cost of approximately 9% more memory . The exact figures will vary depending on the device and the app, but the pattern is clear: with more RAM available in newer devices, the jump to 16 KB reduces some memory usage and improves the user experience.
Is your app affected? How to check
If your project includes C/C++ (NDK), relies on SDKs that distribute .so files, or is compiled with external tools that include native libraries, then yes, you are affected and must recompile . If you exclusively use Java/Kotlin, you are usually already compliant, although this doesn't exempt you from testing in 16 KB to avoid unexpected regressions, such as support changes in Android 12 without support.
Quick clues to detect it: if when analyzing the APK/AAB you find .so files in lib/ (e.g., lib/arm64-v8a or lib/x86_64), your app uses native code . Android Studio and its Lint also flag libraries not aligned to 16 KB.
Tools to identify native libraries and their alignment
APK Analyzer (Android Studio → Build → Analyze APK…) lets you open an APK, navigate to lib/, and locate .so files. In the Alignment column, you'll see warnings if any libraries are out of compliance. It's a quick way to identify which libraries are mispackaged.
You can also use automatic checks in Android Studio: Lint highlights unaligned native libraries (16 KB) . This will help you know which dependencies to update or which modules to recompile.
Script verification: On Linux or macOS, the script check_elf_alignment.sh (official) parses an APK and marks each .so as ALIGNED or UNALIGNED for arm64-v8a (and x86_64). If you see UNALIGNED, you'll need to modify the packaging of that lib and recompile.
Checking with command-line tools: Install Build Tools ≥ 35.0.0 and the latest NDK using the SDK Manager or sdkmanager. Extract your APK to a temporary directory, locate the .so files in lib/ and use readelf to check the LOAD segments with alignment 2**14 (16 KB):
readelf -l <SHARED_OBJECT_FILE> | grep LOADIn the output look for the load segments to show align 214. If you see values 213, 2**12 or younger, that library does not comply and it must be regenerated. Another packaging check is to use zipalign about the APK:
zipalign -c -P 16 -v 4 <APK_NAME>.apkIf it ends with “ Verification successful ”, the APK is correctly aligned to 16 KB.
Some guides also suggest reviewing headings with readelf -h and check that it appears Page size 16384. Although the most reliable way is to inspect the LOAD segments (2**14), this header check can serve as an additional clue.
Packaging, build system, and NDK: what you should update
To ensure your app installs and runs on devices configured with 16 KB, you need to align both the packaging and the native binaries. There are two main approaches : AGP/zipalign and NDK/linker flags.
AGP 8.5.1 or higher: preferred and recommended
In apps that distribute uncompressed libraries, AGP ≥ 8.5.1 aligns the .so files to 16 KB within the ZIP boundary, as required by the system. Update using the Android Studio Assistant and check your build. With AGP 8.3–8.5, there's a catch: bundletool doesn't zipalign by default , and your APK might appear correct locally, but the App Bundle generated for Play will end up misaligned, causing the installation to fail.
If you can't upgrade to 8.5.1 right now, you have a temporary alternative: package the libraries in a compressed file to avoid the 16 KB ZIP alignment requirement. In Gradle, you can force the "legacy" packaging of jniLibs, which involves compression.
// Groovy
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
// Kotlin DSL
android {
packaging {
jniLibs {
useLegacyPackaging = true
}
}
}Please note the warning: when compressing .so files, the installer extracts and copies the libraries , increasing the space occupied on the device and, consequently, the likelihood of installation failures due to insufficient storage. The best solution remains migrating to AGP ≥ 8.5.1.
Compiling with 16KB ELF alignment: NDK and flags
16 KB devices require that the ELF segments in your .so files be aligned to 16 KB . This depends on the NDK version and how you link:
- NDK r28 or higher: compiles by default with 16 KB alignment. This is the ideal option.
- NDK-r27: Enable 16KB alignment via flags (ndk-build, CMake/Gradle, or the linker). Make sure the final linker passes the appropriate option.
- NDK r26 and earlier: It is not recommended. If there is no other option, adjust ndk-build/CMake with the 16KB flags; for r22 or earlier, it may be necessary to add
common-page-size=16384due to historical bugs in ld/lld (works if the ELF includes.relro_paddingwith LLD 18+). Even so, migrate as soon as possible to r27 or r28.
If you use other build systems or need to force linking, pass the standard linker flag for the maximum page size:
-Wl,-z,max-page-size=16384Remember that precompiled third-party libraries must also be updated. If your app dynamically links to older libc++_shared.so (r26 or earlier versions without alignment), it won't install in 16 KB. Consider migrating to NDK r27/r28, or as a workaround, statically link the standard C++ in your .so file following the STL compatibility recommendations (weighing the pros and cons).
Update compileSdk/targetSdk and automate checks
To prepare your build line, set compileSdkVersion and targetSdkVersion to 35 (Android 15) and uses the latest NDK and Build Tools. Integrate CI steps that run apkanalyzer, readelf y zipalign to verify that all .so files show Page size 16384/align 2**14 and that the APK is zip-aligned to 16 KB.
Fixes code that takes up 4KB and reviews sensitive APIs
Even with aligned binaries, your app could still fail if there are 4 KB assumptions in the code. Avoid using the PAGE_SIZE constant or fixed values like 4096 in sensitive logic; in the RDK r27+, PAGE_SIZE isn't even defined in 16 KB mode.
Instead, get the page size at runtime with getpagesize() o sysconf(_SC_PAGESIZE)This ensures that your app scales to 4KB, 16KB, or future sizes without breaking.
Check calls to mmap() and APIs that require page-aligned argumentsIf you request 1–5 KB in a 16 KB kernel, the system will allocate 16 KB (rounding to page). Where possible, combine regions to minimize waste and consider grouping RW segments to make the most use of a single page.
Test in a 16KB environment: emulator and devices
After recompiling and aligning, it's time to test. Configure Android 15 in the SDK and create a virtual device with a 16KB-based system image. Android Studio Jellyfish (2023.3.1) or later supports this, although Ladybug (2024.2.1) or later is recommended for the best experience.
In SDK Manager, under SDK Platforms, enable “Show Package Details” and, within Android VanillaIceCream (or later), select the 16 KB images : ARM 64 v8a (recommended for emulating compatible Pixel devices) and/or Google APIs Experimental 16 KB Page Size x86_64 Atom. Download them and create your AVD with that image (it appears under “Other Images” if it isn't suggested).
For emulator versions 35.1.5 to 35.1.20 (and before revision 4 of the 16 KB Android 15.0 images), in x86_64 there is an extra step: edit the AVD's config.ini and add:
kernel.parameters = androidboot.page_shift=14Start the emulator and check the environment with adb shell getconf PAGE_SIZE. Must return 16384There is a known debugging issue with LLDB on 16KB images, resolved in NDK r27 (RC1) and Android Studio Koala | 2024.1.2 Canary 5.
If you have a compatible physical device, starting with Android 15 QPR1, some models (for example, Pixel 8/8 Pro/8a , and Pixel 9/9 Pro/9 Pro XL with QPR2 Beta 2 or higher) include a toggle in Developer Options to boot the system in 16 KB. Apply system updates and enable testing mode on real hardware, and control the screen with scrcpy for testing.
16KB backward compatibility mode
When the device runs a 16 KB kernel, the Package Manager may force backward compatibility mode if it detects .so files with 4 KB LOAD segments or if the compressed APK contains uncompressed ELF files aligned to 4 KB. The app will display a warning on first boot indicating that it is running in compatibility mode.
This mode allows certain apps to function, but it's not the recommended solution. For reliability and stability , align your libraries to 16 KB and correct any page size assumptions in your code. You can enable or disable this mode per app from its information screen (Advanced → Run app in page size compatibility mode), visible only on devices configured for 16 KB.
You can also control it globally via system properties:
# Forzar compatibilidad 16 KB en todas las apps
adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false
# Desactivar compatibilidad 16 KB en todas las apps
adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled trueIf you want to pin it from your app, in the AndroidManifest you can use android:pageSizeCompat to enable/disable app-level support, thus preventing startup warnings when explicitly defined.
Google Play Requirement: Key Date and Scope
To prepare for the arrival of new devices, Google Play will require 16KB support (see how Google and Qualcomm guarantee 8 years of updates ): from November 1, 2025, all new apps and updates targeting Android 15 (API 35) or higher must support 16KB pages. If your build doesn't comply, Play may block its publication.
Some developers have received communications indicating a second milestone around May 2026 for tightening restrictions on non-compliant updates. Check your Play Console and emails to confirm the timelines applicable to you, although the main public milestone is November 1, 2025.
Kernel and Userspace Perspective (Advanced)
In destinations arm64, a 16KB kernel is compiled with Kleaf using --page_size=16k or selecting CONFIG_ARM64_16K_PAGES in the kernel configuration (replacing CONFIG_ARM64_4K_PAGES). In user, to enable 16KB on Android, products can define:
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true(elimina PAGE_SIZE and forces the size to be queried at runtime).PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384(guarantees 16KB ELF alignment on platform and facilitates future compatibility).
After selecting the destination (lunch), check that the brands are active in the environment:
$ source build/envsetup.sh
$ lunch <target>
$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
trueEven if the compilation passes, differences may persist at runtime under 16 KB. It is key to thoroughly test and review mmap(), alignments and page size assumptions.
For libraries outside the Android tree, remember to pass to the linker: -Wl,-z,max-page-size=16384. And since Android 16 you can activate PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true to validate prebuilts; temporarily ignore it with ignore_max_page_size: true on Android.bp or LOCAL_IGNORE_MAX_PAGE_SIZE := true on Android.mk. In addition, there is atest elf_alignment_test which verifies ELF alignment on devices launched with Android 15+.
Common mistakes and how to fix them
- Installation from Play fails but local installation seemed to work fine.: This is often a zipalign issue at 16KB when building from the App Bundle (AGP 8.3–8.5). Upgrade to AGP ≥ 8.5.1 or temporarily use legacy (compressed) packaging for jniLibs and check again.
- INSTALL_FAILED_INVALID_APK / unsupported ELF page size: your .so files are 4KB. Update the NDK (e.g., r26+; r27/r28 is better), set the version in your project, clean, and recompile. Check with Reader what do you see
align 2**14. - readelf: ELF header missing or corrupted when inspecting: You have verified that a file has been extracted or compressed incorrectly. Extract the APK with
unzipto a directory, navigate tolib/arm64-v8aand runreadelfabout the correct .so. Do not inspect intermediate artifacts or modified. - Works on emulator, fails on 16 KB device: is usually due to Outdated third-party SDKs. Identify the problematic .so with
adb logcat, update the dependency to a supported version, contact the vendor, or if there is no alternative, temporarily remove it. - Play Console keeps warning after recompiling: There is still some .so files at 4 KB in your AAB. Use
bundletoolTo generate .apks, unzip and launchreadelfto all .so by searching for “Page size 16384” oralign 2**14. Until the last library meets, the notice will not disappear.
Practical compliance checklist
Before publishing, confirm this list for peace of mind. The more you automate in CI, the better.
- AGP ≥ 8.5.1 or, temporarily, jniLibs compressed with
useLegacyPackaging. - NDK r28+ (or r27 with flags); binaries with -Wl,-z,max-page-size=16384 if applicable.
- All .so (including third party) with LOAD segments to 2 ** 14.
- No 4KB assumptions in the code; you use
getpagesize()/sysconf. - Zip-aligned APK:
zipalign -c -P 16 -v 4→ “Verification successful”. - Testing on emulator/device 16 KB:
adb shell getconf PAGE_SIZE= 16384.
How to submit new versions on Google Play with less risk
Release first to test tracks. Open testing is used to validate with testers , followed by closed testing with controlled groups, and once stability is verified, promote to production. Accompany the release with visible version notes: Android 15 compatibility and 16 KB support for greater transparency.
