Android 16 KB Page Size: What Play Blocks

The Android 16 KB page size requirement means that any app on Google Play targeting Android 15 or higher has to ship native libraries aligned to 16 KB memory pages on 64-bit devices. Google’s current documentation states that starting February 1, 2027, app updates that don’t support 16 KB memory page sizes can’t be released. If your app is written purely in Kotlin or Java, and every library it pulls in is too, you already comply and there’s nothing for you to do. If anything inside your app ships a .so file, which is true of far more apps than their owners realise, this eventually blocks your next release.

Most of what ranks for this either restates Google’s compatibility page for someone who owns the native code, or solves it for one framework inside a migration post. This piece covers that ground and then handles the two cases they leave hanging: the unaligned library belongs to a vendor you can’t chase, and the app runs perfectly on a 16 KB device while still failing the requirement. It also connects this to the target API level deadline you’ve just been through, because the two rules are one piece of work.

What is the Android 16 KB page size requirement?

A memory page is the smallest chunk of memory the operating system hands out at a time, and Android used 4 KB pages for its entire history until recently. Beginning with Android 15, the open source project supports devices configured to use a page size of 16 KB instead, and Google’s requirement is that all apps targeting Android 15 or higher must support those devices on 64-bit hardware.

The reason Google gives is device performance rather than anything about your code quality. Its May 2025 announcement reported app launch improvements from 3% to 30% across various apps, an average battery gain of 4.5%, camera start times 4.5% to 6.6% faster, and system boot roughly 8% faster. Those are Google’s own measurements rather than independently verified results, and they describe what a 16 KB kernel does rather than what recompiling your app does for your users.

Compliance here isn’t a setting you change or a form you fill in. Compiled code carries an alignment value baked in at link time, so a library built years ago stays unaligned no matter what your manifest says today. The fix always means recompiling something, and the useful question is who can recompile it.

Which apps actually have to do something about it?

Any app that ships a shared object file, which means any app containing C or C++ code either directly or through something it depends on. Google states the test three ways: your app uses native code, your app links against third-party native libraries or dependencies such as SDKs that use them, or your app is built by a third-party app builder that puts native libraries on the device.

That third clause catches the teams who believe they’re safe. Flutter, React Native, Unity and .NET MAUI all ship native engines, so an app built with any of them contains native libraries before you add a dependency of your own. Even on a pure Kotlin project, image codecs, database engines, video players, ad networks, crash reporters and payment SDKs routinely arrive with compiled code inside them.

Checking the build beats reasoning about it, so open Android Studio, choose Build then Analyze APK, pick a build and look inside the lib folder. If any .so files are sitting there, your app uses native code and this applies to you.

When does Google Play actually start blocking your updates?

Google’s compatibility documentation currently states that starting February 1, 2027, if your app updates don’t support 16 KB memory page sizes, you won’t be able to release these updates. That’s the date to plan against.

An earlier date is still circulating, so be precise about where it came from. Google’s May 2025 blog post announcing the requirement said that starting November 1, 2025, all new apps and updates submitted to Play and targeting Android 15 or higher had to support 16 KB page sizes. Both dates are genuinely from Google, and teams defend whichever one they read first. Open the live documentation before planning a release around either number.

The date that probably matters more to you right now is a different one. Google’s target SDK requirements say that from August 31, 2026, new apps and app updates must target Android 16 or higher to be submitted to Play, with an extension available to November 1, 2026 for teams that need more time. Anything targeting API level 36 is above API level 35, which is exactly the line that pulls an app into the 16 KB requirement. So the target API bump most teams either finished last week or are currently requesting an extension for is the same change that puts them inside this rule. If you’re still working through that side of it, our breakdown of the Google Play target API level deadline covers what breaks on the way to API 36.

How do you check whether your app already supports 16 KB?

Run the alignment checks against a real build rather than reading your dependency file, because what you shipped and what you intended to ship are frequently different things. The fastest local check uses the zipalign tool from the Android build tools, invoked as zipalign -v -c -P 16 4 against your APK. The last line of its output says verification successful when every shared library inside is aligned correctly.

Google also publishes a script called check_elf_alignment.sh that prints either ALIGNED or UNALIGNED for each arm64-v8a shared library, which beats a single pass or fail because it names the offending files. For one library you can go lower and run llvm-objdump -p against the .so file, filtering for LOAD segments, then confirm no alignment value sits below 2**14.

Two checks need no command line at all. Lint inside Android Studio flags native libraries that aren’t 16 KB aligned as you work, and uploading a bundle to Play Console lets the app bundle explorer report that build’s compliance and where it needs updating. Google also publishes experimental 16 KB emulator system images for ARM and x86, and a 16 KB device answers adb shell getconf PAGE_SIZE with 16384.

How do you fix the native libraries you own?

Fixing your own code takes two changes, one to packaging and one to compilation. Upgrade to Android Gradle Plugin 8.5.1 or higher and ship uncompressed shared libraries, because 16 KB devices need them aligned on a 16 KB zip boundary. On older plugins, AGP 8.5 and below accept a packagingOptions block setting jniLibs.useLegacyPackaging to true, and AGP 8.0 and below need android.bundle.enableUncompressedNativeLibs=false in gradle.properties.

NDK r28 and higher compile 16 KB aligned by default, so the cleanest fix is often moving your NDK version forward. If you can’t move, pass the linker -Wl,-z,max-page-size=16384 and -Wl,-z,common-page-size=16384, which go into LOCAL_LDFLAGS with ndk-build and into a target_link_options call with CMake.

Then there’s the code itself, where the surprises live. Anywhere your C or C++ assumes a 4 KB page is now wrong, so remove hard-coded references to the PAGE_SIZE constant and anything assuming 4096, and call getpagesize() or sysconf(_SC_PAGESIZE) instead. Check every use of mmap() and the other calls needing page-aligned arguments, since those fail at runtime rather than at build time. From NDK r27 onwards PAGE_SIZE is undefined when 16 KB mode is enabled, which usefully turns a silent wrong assumption into a compile error.

What happens when the unaligned library isn’t yours?

This is where most projects stall, and it’s the case the framework migration posts skip. You’ve run the checks, two or three .so files come back unaligned, and none came from code anyone at your company wrote. The library name usually identifies the dependency that owns it, and where it doesn’t, unzipping the build and matching against your dependency tree does.

From there you have four options and they aren’t equally good. Updating the SDK to a version its vendor compiled with NDK r28 or later is the best outcome, costs a version bump and a regression test, and covers most maintained dependencies. If the vendor ships source through a Gradle module you compile yourself, apply the linker flags on your side without waiting for anyone. If it’s a prebuilt binary from a vendor who has gone quiet, you’re choosing between replacing the dependency and dropping the feature it powers. Filing an issue is worth doing alongside any of these and worth nothing by itself, since a library that missed a 2025 deadline rarely has an active maintainer.

Cross-platform projects have an extra layer, because the framework engine and the plugins on top of it are versioned separately. A React Native app can sit on a recent engine while three community modules still ship 4 KB libraries. If your app is several versions behind, the alignment work usually gets absorbed into a larger React Native upgrade rather than done on its own.

Why can an app look fine on a 16 KB device and still fail?

Because Android ships a compatibility layer that hides the problem from you. When a device runs a 16 KB kernel and the package manager sees an app whose ELF files have 4 KB load segment alignment, or whose uncompressed ELF files are 4 KB zip aligned, it can enable 16 KB backcompat mode for that app. The app then runs, and the only signal is a warning shown on first launch saying it’s running in 16 KB backcompat mode.

That warning is the kind of thing a tester dismisses without reading. So a manual check on real hardware, which feels like the most trustworthy test available, is among the least reliable ways to judge compliance. An app in backcompat mode passes a human smoke test and fails the store requirement at once.

Google exposes the behaviour deliberately for testing. The mode toggles per device through adb shell setprop calls against bionic.linker.16kb.app_compat.enabled and pm.16kb.app_compat.disabled, and a single app opts in or out through an android:pageSizeCompat property in its manifest. Google has also documented an Android 17 setting where that property is set to fatal, making incompatible binaries abort instead of falling back. Treat a backcompat warning as a failing result and go back to the alignment checks.

How much work is this really, and who should do it?

For most apps this is a small job wearing a frightening label, and for a minority it’s a genuine project. An app on maintained dependencies with a current toolchain often clears it with an NDK bump, an AGP bump and a regression pass. The cost climbs with every dependency nobody has touched in three years, and fastest where a prebuilt binary needs replacing with something equivalent.

What makes the estimate hard isn’t the alignment work, it’s the testing that follows. Moving your NDK forward several major versions changes the compiler under every line of native code, and that’s how you find undefined behaviour that happened to work for five years. Fix the alignment, then watch your crash reporting against a real user cohort, because the crashes following a toolchain jump tend to be memory bugs rather than obvious breakage. Teams already watching their Android ANR and crash rates catch this quickly, and teams without that instrumentation find out through store reviews.

We won’t quote a fixed price or timeline without looking at your build first, because the answer depends entirely on how many unaligned libraries you have and who owns them. The triage itself takes hours rather than days: run the alignment check, list the unaligned files, and map each one to the dependency that owns it. That list is effectively the whole estimate. If the checks return names nobody recognises, or the app hasn’t shipped in a year and this is the third deadline stacked on top of it, talk to a senior engineer about your app before the release calendar decides for you. RapidLabs does this mobile app stabilization work on codebases the original team left long ago.

Getting both Play deadlines onto one release plan

Both requirements land on the same apps for the same reason, so plan them together rather than twice. Moving to API level 36 satisfies the target API rule and puts you above API level 35, the threshold making 16 KB alignment mandatory. A team that bumps its target API level, ships, then meets the alignment requirement four months later has paid for two dependency audits, two regression cycles and two release windows to do one job.

Run the alignment check before you plan the target API work rather than after it, because you’ll open the same dependency tree either way and knowing which libraries are unaligned changes which versions you upgrade to.

Apps shipping every fortnight absorbed both of these one version at a time and barely noticed. The ones that hurt are apps sitting untouched for two years, where a single release has to clear a target API bump, a toolchain jump, a native alignment fix and whatever else accumulated in the gap. RapidLabs sees that pattern constantly, and it’s always the same shape: each change is small on its own, and doing all of them at once with no recent release history turns them into a quarter of work. Start the triage while February 2027 is still a date on a calendar rather than a blocked upload.