Blog Infos
Author
Published
Topics
Published
Topics

 

What “page size” means

Memory in modern operating systems is managed in fixed-size chunks called pages. A page is the basic unit the kernel and the CPU’s MMU use to map virtual addresses to physical RAM, enforce permissions (read/write/execute), and service page faults.

Think of paging as a library using identically sized boxes (pages) to store books on rolling shelves; standardizing the box size makes filing, moving, and securing the books tractable.

Page size is just the capacity of those boxes.

Android 15 makes the platform page size-agnostic and unlocks a shift from the long-standing 4 KB memory page to a 16 KB page on supported devices.

For years, 4 KB was the sweet spot. But as ARM64 devices gained RAM and cores, a larger page reduces bookkeeping: fewer entries in page tables, fewer TLB lookups, and fewer costly page-table walks.

Why 16 KB matters

Why does that size matter? Each app’s code, data, and libraries are mapped page-by-page. The kernel tracks those mappings in page tables, and the CPU caches recent translations in the TLB (Translation Lookaside Buffer).

With larger pages, fewer entries are needed to cover the same address space, which typically means fewer TLB misses and fewer page-table walks. Concretely, mapping 64 MB needs 16,384 pages at 4 KB but only 4,096 pages at 16 KB (one quarter the bookkeeping).

Performance

Less “admin work” for the CPU usually translates into snappier launches and lower overhead during heavy memory activity. Google’s testing on 16 KB devices shows ~3.16% faster app launches on average (up to 30%)~4.56% lower power draw during launch4.5–6.6% faster camera starts, and ~8% quicker boot. Think of it like driving through one big toll instead of four small ones on every trip.

Battery Life

Battery life benefits follow the same logic: every avoided TLB refill or page fault is work the CPU doesn’t have to do, so the device burns a bit less energy in common workflows (cold starts, camera open, multi-app sessions).

The effect is incremental rather than dramatic (a few percent per event), but it adds up over a day of usage, especially on devices juggling many processes.

Larger Page-Size Trade-Offs?

Larger pages increase the minimum allocation unit at the kernel boundary, so tiny mappings get rounded up to the page size. A 5 KB mapping consumes 8 KB on a 4 KB system but 16 KB on a 16 KB system.

That’s internal fragmentation. Well-written code mitigates this by grouping small regions or avoiding patterns that splinter memory into many tiny mappings.

Importantly, the AOSP guidance notes that while 16 KB pages use additional memory in general, a well-optimized system can use less total memory because the page tables themselves are ~¼ the size for the same address space. Net result: a small average RAM cost for many apps, but potential wins when memory layouts are tuned.

The November 1, 2025 deadline (and what you must ship)

Google Play will enforce 16 KB page-size compatibility starting November 1, 2025: any new app or update targeting Android 15+ must support 16 KB pages, or it can be rejected.

This isn’t a “nice-to-have” performance tweak, but it’s a gate for publishing on newer targets. Google’s rationale ties to measurable wins: faster launches, lower power during launch, quicker camera start, and faster boot on devices configured for 16 KB.

What developers need to do (practical, minimal, and verifiable)

If your app is pure Kotlin/Java (no native .so anywhere, including SDKs), you’re typically compatible.

If you ship any native code (directly or via third-party SDKs), you must rebuild and package correctly for 16 KB.

The compatibility check is straightforward. If your app is pure Kotlin/Java, with no native .so files from your team or any third-party SDKs, you are fine. The 16 KB requirement is an issue exclusively for native code.

For apps with native code, the path is clear: recompile all your C/C++ libraries with a modern Android NDK. Crucially, you must also update every third-party SDK to a version its provider has certified as 16 KB compatible. An old, un-updated SDK will cause crashes, even if your own code is perfect.

Don’t guess… verify. You can confirm your app is compliant by testing it in a 16 KB environment. The easiest way is to create an Android 15 emulator in Android Studio and, in its advanced settings, change the “Kernel page size” to 16 KB. An incompatible app will typically crash immediately on launch; a compatible one will run normally.

For more information, please refer to the official guidelines for transitioning to 16 KB, as outlined in the official documentation at the end of this article.

Job Offers

Job Offers

There are currently no vacancies.

OUR VIDEO RECOMMENDATION

No results found.

Jobs

Quick clarifications (recompile? .so? who needs to care?)
Why recompilation is needed

Native libraries are ELF (Executable and Linkable Format) binaries whose segments (code, read-only data, writable data, RELRO, etc.) must be mapped on page boundaries.

If they were built with 4 KB assumptions, a 16 KB device may not be able to map them safely → loader error or crash. Recompiling with a current NDK regenerates the layout (alignment/padding) to fit 16 KB pages.

Analogy: you pre-cut drawers for 40 cm slots; the new kitchen has 160 cm slots — re-cutting = recompiling.

What a “.so” is

.so (shared object) is a native shared library, usually produced from C/C++ (NDK) or Rust by the toolchain (Clang + linker). Gradle packages these under lib/<abi>/*.so in your APK/AAB, and the dynamic linker loads them at runtime.

Who needs to care
  • Pure Kotlin/Java (no .so): Generally no action. Your bytecode runs on ART, which the platform provides for 16 KB. Still, give it a quick test.
  • Kotlin/Java + third-party SDKs: Check your APK. If any SDK bundles a .so, you must update it to a 16 KB–compatible build (even if you don’t write native code yourself).
  • Apps using the NDK (C/C++/Rust): Rebuild your native libraries with a modern NDK and retest on a 16 KB device/emulator.
One-minute sanity check

Those checks will help you a lot to check if you have any .so files in your project, and if yes, validate that your page size is on the desired 16 KB length.

  • Do I have .so files in my project?
    List .sos in your APK: zipinfo app-release.apk | grep '\.so$'
  • Does the page size configuration report 16 KB?
    Device page size: adb shell getconf PAGE_SIZE → expect 16384 on 16 KB devices.
Sources:

Android Open Source Project (AOSP)

Android Developers Blog

Android Developers

This article was previously published on proandroiddev.com.

Menu