If you have come across the message about 16KB memory pages on Android in the emulator or on the Google Play Console, you are not alone. It is a technical change with real impact on the performance and in the publishing apps starting with Android 15, so it's a good idea to understand what it is, why it's done, and how to adapt your builds.
Simply put, Android opens the door to devices configured with 16 KB page size (in addition to 4 KB), which can translate into faster app launches, lower power consumption, and a more responsive system. Of course, if your app integrates native code (.so), you'll need to recompile and align correctly or risk installation errors and crashes on Google Play.
What does page size mean and what's changing with Android 15?
The page size is the basic unit with which the operating system manages RAMHistorically, Android was optimized for 4KB because it was the most common on devices and kernels, while many ARM CPUs already supported 16KB. With Android 15, AOSP adds support for compile and run on 16KB devices, and also introduces 16KB ELF alignment in user space that works with 4KB and 16KB kernels (as of android14-6.1).
This option is not always enabled by default, but is available as developer mode and in emulator for OEMs and developers to prepare for the transition. In the future, as manufacturers add more RAM, it is likely that grow the adoption of 16 KB (and perhaps even larger sizes).
Performance benefits measured by Google
Adopting 16 KB entails a small average increase in memory, but offers systemic and app improvementsInitial tests of Android 15 showed:
- Faster app launches: on average 3,16%, with specific cases of up to 30%.
- Lower consumption during launch: average reduction of 4,56%.
- Faster camera: 4,48% faster hot starts and 6,60% faster cold starts on average.
- System boot: ~8% improvement (approx. 950 ms).
Some external analyses speak of total profits of 5–10% at the cost of ~9% more physical memory, although the actual result will vary by device and app. In any case, with more RAM available in the current range, the jump to 16 KB reduces the memory accounting and helps everything go more smoothly.
Is my app affected?
The quick rule: if your app is 100% Java/Kotlin (including libraries and SDKs), already supports 16KB. However, it is a good idea to test it in a 16KB environment in case any issues arise. unexpected regressions.
If your project uses native C/C++ code (NDK), link with SDKs that include .so, game engines or external compilers that incorporate native libraries, you will have to recompile and align for 16 KB. This is typically the case for apps with SQLCipher, engines like Unity/Unreal, or third-party native SDKs.
How to know if you use native and if you meet 16 KB
APK Analyzer in Android Studio
Open Android Studio and use Build → Analyze APK… To inspect an APK, navigate to lib/ and look for .so files; if they exist, your app native use. The panel displays warnings of Alignment if any library does not comply with 16 KB.
In addition, Android Studio incorporates automatic checks: Lint flags native libraries as unaligned to 16KB, and the tools themselves flag issues with non-compliant APKs or prebuilts.
Official script to check ELF alignment
On Linux or macOS you can use the script check_elf_alignment.sh To parse an APK and label each .so as ALIGNED or UNALIGNED (arm64-v8a and x86_64):
./check_elf_alignment.sh APK_NAME.apkIf any library comes out as UNALIGNED, You will have to update your packaging, recompile your app and repeat the tests. It's a fast and effective way to detect non-compliance before uploading to Play.
Verification with command-line tools
Install Build Tools ≥ 35.0.0 and a recent NDK from the SDK Manager. Extract the APK and locate the .so files in lib /, and for each one execute:
readelf -l <SHARED_OBJECT_FILE> | grep LOADOn output, check that the loading segments show align 214. If you see 213, 2**12 or less, that library is not aligned for 16 KB. Finally, run zipalign on your APK:
zipalign -c -P 16 -v 4 APK_NAME.apkIf it ends with 'Verification successful', the APK is zip aligned to 16 KB correctly, key requirement for 16KB devices when distributing uncompressed .so.
Compiles and packages to 16 KB
Update packaging: AGP 8.5.1 or higher
In apps with uncompressed native libraries, 16KB devices require the APK to be aligned to a 16KB ZIP boundaryThe recommended way is to use the Android Gradle Plugin 8.5.1 or later, which applies this alignment automatically. It is the most robust option for reliable installations from Play.
Be careful with AGP 8.3–8.5: although it seems to be going well locally, bundletool doesn't zipalign by default and the output from App Bundle might be misaligned and fail to install. If you can't upgrade to 8.5.1 yet, there is a temporary workaround: bundling Compressed jniLibs.
// Groovy
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
// Kotlin DSL
android {
packaging {
jniLibs {
useLegacyPackaging = true
}
}
}Please note that when compressing .so, the installer must extract and copy libraries, which increases disk usage and can raise the throughput rate small space failuresThe fundamental solution remains to migrate to AGP ≥ 8.5.1.
ELF alignment to 16 KB: NDK and flags
16KB devices require that the ELF segments of your .so are aligned to 16 KB. The best route is to use NDK r28 or higher, which compiles with 16 KB by default.
With NDK-r27 You need to enable inlining via flags (ndk-build, CMake/Gradle, or by passing the option to the linker). For builds with multiple toolchains, you can force linking with:
-Wl,-z,max-page-size=16384With NDK r26 or earlier support is discouraged; as a last resort, tune ndk-build/CMake with the 16KB options. If you use NDK r22 or previous, it may be necessary to add common-page-size=16384 due to historical bugs in ld/lld; this solution works if the ELF includes .relro_padding (LLD 18+). Even so, it is advisable to migrate as soon as possible to r27/r28.
If you dynamically link to a old libc++_shared.so (r26 or earlier non-aligned 16KB), your app will not install on 16KB. You'll need to migrate to a recent NDK or, as a workaround, statically link the C++ STL following compatibility considerations, weighing the pros and cons.
Avoid 4KB assumptions in your code
Even if you compile and align correctly, your app can still fail if the code assumes PAGE_SIZE = 4096 or use that value rigidly. In NDK r27+ the PAGE_SIZE constant it is not even defined in 16 KB mode.
The correct thing to do is to query the page size at runtime with getpagesize() o sysconf(_SC_PAGESIZE). Review uses of mmap() and other APIs that require page-aligned sizes or addresses, replacing with alternatives where appropriate and combining regions to reduce waste.
Remember that the kernel rounds requests to the nearest page. In 16 KB, requesting 1–5 KB allocates 16 KB; 17 KB allocates 32 KB. Where possible, group two RW regions that were previously 2×4 KB so that, in 16 KB, they remain a single page and avoid duplication.
Check that your SDKs support 16 KB
Many suppliers already distribute compatible builds or allow recompiling, but there are older versions that do not comply. Check the documentation for each SDK, update to the supported version and confirm alignment with the above tools; if there is no support, assess temporarily withdraw that dependency.
16KB Test: Emulator and Devices
Configure the Android 15 SDK and create a virtual device with a 16KB based system image. Android Studio Jellyfish (2023.3.1) or later supports it, although Ladybug (2024.2.1+) is recommended for the best experience.
In SDK Manager → SDK Platforms, check Show Package Details and, under Android VanillaIceCream or later, install the images for Google APIs Experimental 16 KB Page Size (ARM 64 v8a and/or x86_64 Atom). If you're emulating a compatible Pixel, ARM 64 v8a is usually enough.
On some emulator versions (35.1.5 to 35.1.20) and before revision 4 of the 16KB Android 15.0 images for x86_64, add this line in the config.ini of the AVD:
kernel.parameters = androidboot.page_shift=14Start the emulator and check the environment with adb shell getconf PAGE_SIZE; should return 16384. There is a known debugging issue with LLDB on 16KB images, fixed in NDK r27 (RC1) and Android Studio Koala | 2024.1.2 Canary 5.
Test on real hardware
Since Android 15 QPR1, some models include a developer option to boot the device in 16 KB. Specifically, Pixel 8/8 Pro/8a include it in QPR1 or higher, and Pixel 9/9 Pro/9 Pro XL from QPR2 Beta 2 or later. Apply system updates and enable the mode to validate in real conditions.
Check the size with adb shell getconf PAGE_SIZE (should be 16384) and verify that your APK is zip-aligned to 16 KB with:
zipalign -c -P 16 -v 4 APK_NAME.apkThen, do extensive testing, focusing on areas that are sensitive to page sizes and native memory.
16KB backward compatibility mode
When the device runs a 16KB kernel, the Package Manager can trigger a backward compatibility mode if it detects .so files with 4KB aligned LOAD segments or if the compressed APK contains uncompressed ELF files aligned with ZIP at 4KB. The app will display a warning on first startup indicating that it is running on compatibility mode.
This mode helps some apps run smoothly, but it's not ideal for stability. You can enable or disable it for each app in its info (Advanced → Run app in page size compatibility mode) or control it globally with 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 trueYou can also set it in your manifest with the attribute android:pageSizeCompat To avoid the warning at boot when you want to force it explicitly:
<application android:pageSizeCompat='true' />Google Play Requirement: Dates and Scope
To prepare for the launch of new devices, Google Play will require apps targeting Android 15 (API 35) or higher are compatible with 16KB pages. The public key date is the November 1th 2025 for new apps and updates.
Some developers have received additional notices with a milestone around the May 1th 2026 to harden blocks for non-compliant builds. Monitor your Play Console and your communications, but the main reference is November of 2025. It's not just a compliance box: incorporating 16 KB offers performance improvements real.
Android Settings in 16 KB (advanced)
En arm64, if you compile the kernel with Kleaf, use –page_size=16k, or in the Linux kernel configuration select CONFIG_ARM64_16K_PAGES instead of CONFIG_ARM64_4K_PAGES. For user space, define in the product:
- PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true to remove PAGE_SIZE and force query at runtime.
- PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384 to compile ELF with 16KB alignment and facilitate future compatibility.
After selecting the target (lunch), check the build flags:
$ 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 succeeds, differences may persist. execution time in 16 KB, so you have to test thoroughly and review lineups and calls to mmap ().
Efficient programming with 16 KB pages
Most Android code doesn't manage pages directly, but if you deal with memory, change the kernel behavior: Always rounds up to the page size. At 4 KB, allocating 1–4 KB consumes 4 KB; at 16 KB, 1–5 KB consumes 16 KB, and at 17 KB, 32 KB.
Demand round your sizes before calling mmap() and, when possible, consolidate RW regions to take advantage of a single page and reduce waste. Also, in optimized systems, page tables are a quarter of the size for the same memory when using 16 KB pages, which partly compensates for the higher granularity.
Verifying binaries and prebuilts
Beyond testing on 16KB kernel, from Android 16 you can activate PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true to validate prebuilts at build time. If you need to temporarily ignore it, use ignore_max_page_size: true on Android.bp or LOCAL_IGNORE_MAX_PAGE_SIZE := true on Android.mk.
On devices launched with Android 15+, it runs atest elf_alignment_test to verify the ELF lineup on the device itself, and capture results for your CI pipeline.
Common errors and solutions
- Installs locally but fails from Play: Typical 16KB zipalign missing in builds generated from App Bundle (AGP 8.3–8.5). Upload to AGP ≥ 8.5.1 or temporarily pack compressed jniLibs and validate again.
- INSTALL_FAILED_INVALID_APK / unsupported ELF page size: your .so files are 4KB. Update NDK (r27/r28 is best), clean and recompile, and commit with readelf align 2**14.
- readelf fails or displays corrupt header: You're probably inspecting a poorly extracted file. Unzip the APK to a folder, go to lib/arm64-v8a and run readelf on the correct .so.
- Works on emulator but not on device 16 KB: is usually a Outdated third-party SDK. Identify the problematic .so with logcat, update the dependency or remove it if there is no supported version.
- Follow the prompt in Play Console after rebuilding: There is some .so file at 4KB in the AAB. Use bundletool to generate .apks, unzip and pass readelf/zipalign to all .so until the last one complies.
Practical checklist before publishing
- AGP ≥ 8.5.1 or, temporarily, jniLibs compressed with useLegacyPackaging.
- NDK r28+ (or r27 with flags) and, if applicable, -Wl,-z,max-page-size=16384 in the link.
- All the .so with LOAD align 2**14 (arm64-v8a/x86_64) and APK zipaligned to 16 KB.
- Shipping Costs 4KB assumptions in the code; you use getpagesize()/sysconf.
- Testing on 16 KB emulator/device and verification with adb getconf PAGE_SIZE = 16384.
Publishing on Google Play with less risk
Go up first to Open testing to capture early feedback, then to Closed testing with limited groups, and finally promote to Production when you validate stability. In the release notes, communicate that you have added Android 15 support and 16KB pages to provide context for users and reviewers.
With this move, Android aligns its platform with modern hardware and offers a clear path to gaining performance in launches, camera and system startups. If your app uses native, the recipe is straightforward: update AGP/NDK, align ELF and ZIP to 16KB, remove 4KB assumptions, test on emulator and on Pixel with 16KB, and keep an eye on third-party dependencies; if you do this, you'll not only comply with Google Play, you also give your users a smoother experience. Share this information so more people know about the impact of Android 16 KB.