16 KB Page Size on Google Play: Find the Failing .so

Google Play requires apps that target Android 15 (API level 35) and higher to support 16 KB memory page sizes on 64-bit devices, and from February 1, 2027 you will not be able to release updates that do not. When Play Console raises this problem it usually names no owner: somewhere inside your bundle is a native library that was linked for 4 KB pages, and you are expected to find it.

This is the diagnostic half of that job. Below is what Google's rule says today and which deadline is live, which Play Console page actually reports the compliance state, the two independent checks behind the warning, the exact commands that name the failing library, the failure mode that passes every alignment check and still crashes, and a per-stack map of who shipped the binary in the first place.

What Google's 16 KB page size rule says right now

Answer: all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. Google's page-size guide, last updated 2026-09-16, states it in one sentence:

"To ensure your app works correctly on the latest versions of Android, all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. 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."

Two dates are quoted constantly on this subject and both are now wrong. The original announcement in May 2025 set November 1, 2025 as the date new apps and updates must comply. Google then confirmed in its developer community that developers who needed longer could request an extension until May 31, 2026. The live documentation carries neither date: the block on non-compliant updates now reads February 1, 2027.

Date	What Google published	Status today
November 1, 2025	Original requirement: new apps and updates targeting Android 15+ must support 16 KB page sizes	Superseded, still quoted by older articles
May 31, 2026	End of the extension window Google confirmed for developers who needed more time	Closed, historical
August 31, 2026	New apps and app updates must target Android 16 (API level 36); extension available to November 1, 2026	Live. Raises more apps above the API 35 line that scopes the 16 KB rule
February 1, 2027	"If your app updates don't support 16 KB memory page sizes, you won't be able to release these updates"	The date to plan against

The scope line is what catches people off guard, because it is tied to your target API level rather than to whether you have ever opened a C++ file. Since August 31, 2026 new apps and app updates have been required to target Android 16 (API level 36) unless an extension to November 1, 2026 has been granted, so almost every release sits above API 35 and inside the 16 KB scope. Google is explicit about the exemption: "If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices."

That sentence is doing a lot of work. The qualifier is including all libraries or SDKs. A Kotlin app that pulls in a prebuilt SDK shipping a .so file is not exempt, because the SDK's binary was compiled by somebody else's toolchain.

Which Play Console page reports the compliance state

Google's own instruction is short: "Visit the app bundle explorer page in Play Console to check your app's build compliance and get guidance on where your app may need updating." That is the page to open first. The page-size guide also carries a screenshot captioned "Google Play Console compatibility warning", whose description is a warning that app updates must support 16 KB memory page sizes by February 1, 2027.

Google does not publish a transcript of every message the console can display, and the exact wording moves with console versions. The strings below are reported by developers in Google's Play Developer Community forum and on Stack Overflow, so treat them as field reports rather than official text:

Message developers report	What it is telling you	Next step
"Your app does not support 16 KB memory page sizes."	A bundle-level summary with no library named	Run the library-level checks below to get a filename
"Library that does not support 16 KB: base/lib/x86_64/libtensorflowlite_jni.so"	Names the module, the ABI and the file, but not the dependency that shipped it	Identify which package packages that module, then update or replace it
Compatibility warning carrying the February 1, 2027 date	Advisory today; the documented consequence is a release block from that date	Fix it before your next release, not before your app disappears

The last row matters most, because fear is the wrong reading of the warning. Google documents an inability to release non-compliant updates from February 1, 2027. It does not document removal of an app that is already published. A Diamond Product Expert answering in Google's forum says the same for existing apps: they are not removed from the store, though the app may become unavailable on devices it cannot support. That is community guidance, not a policy page, so plan on the official wording.

The two checks behind the warning, and why passing one proves nothing about the other

Most of the confusion on this subject comes from treating 16 KB support as a single setting. There are two separate requirements, evaluated on two different artifacts:

• ELF segment alignment, inside each library. Every LOAD segment in a .so must be linked with an alignment of at least 2**14 (16,384 bytes). This is a property of how the binary was compiled and linked.
• Zip entry alignment, inside the package. When native libraries ship uncompressed, they must start on a 16 KB boundary inside the APK, so the loader can map them directly out of the archive. This is a property of how the bundle was assembled, which is decided by your Android Gradle Plugin.

Google documents the trap that connects them: "In AGP version 8.3 to 8.5, apps are 16 KB aligned by default. However, bundletool does not zipalign APKs by default. So, the app may appear to work, but when built from a bundle in Play, it won't install." In other words, the APK you installed from Android Studio looks fine while the APK Play generates from your bundle does not.

Check	What it measures	Command	Passing result
ELF LOAD alignment	Inside one .so file	llvm-objdump -p LIB.so | grep LOAD	Every line shows align 2**14 or higher
APK zip alignment	Where libraries sit inside the built APK	zipalign -v -c -P 16 4 app.apk	Last line reads "Verification successful"
Bundle packaging setting	What Play will ask bundletool to build	bundletool dump config --bundle=app.aab | grep alignment	PAGE_ALIGNMENT_16K, not PAGE_ALIGNMENT_4K

Name the failing library: the command sequence

Run these in order. Each one narrows the search, and the first one is usually enough to hand a filename to whoever owns the dependency.

1. List the native libraries with APK Analyzer. Open the project in Android Studio, then Build > Analyze APK... and select your APK. Anything under the lib folder is a shared object, and Google's own instructions note that "The Alignment column displays warning messages for any files that have alignment issues." If there is no lib folder, your app has no native code.
2. Read the alignment of each library. Google's guide gives the exact command and the exact output to expect: llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD, producing lines ending in align 2**14. The rule it sets is simple: "Check the output lines to ensure that the load segments don't have values less than 2**14. If any load segments are 2**13, 2**12, or lower values, you'll need to update the packaging for those libraries."
3. Batch-check an APK with Google's script. check_elf_alignment.sh APK_NAME.apk prints ALIGNED or UNALIGNED for every arm64-v8a shared library, which is faster than walking the list by hand when a bundle carries dozens of SDKs.
4. Check the package, not just the binaries. zipalign -v -c -P 16 4 APK_NAME.apk with Android SDK Build-Tools 35.0.0 or higher. A failure here means your Gradle plugin, not your compiler, is the problem.
5. Check what Play will build. bundletool dump config --bundle=app.aab | grep alignment returns either PAGE_ALIGNMENT_16K or PAGE_ALIGNMENT_4K. This is the setting that decides where the libraries land in the APKs generated from your bundle.

Symptom	Likely cause	Confirm with	Who fixes it
One library reports align 2**12	Prebuilt SDK or plugin compiled with an older NDK	llvm-objdump -p on that file	The vendor, unless you build the source yourself
Every library aligned, zipalign still fails	AGP below 8.5.1 packaging uncompressed libraries without 16 KB alignment	bundletool dump config	Your build files
Local APK passes, Play still warns	Play builds a different APK from your bundle	App bundle explorer plus the config dump	Your build files
Console names no library at all	Bundle-level summary view	APK Analyzer on the installed APK	You, once a filename exists

The check that passes alignment and still crashes

Alignment is not the only way a library can be wrong for a 16 KB device. Google's guide documents a second defect, the RELRO segment, which no LOAD-alignment check will catch:

"A RELRO section having a start address plus segment size (MemSize) that is not 16 KB aligned crashes the app at runtime with a segmentation fault. This happens if the .so file was built with NDK tool chain r27 and lower without enabling the relevant flags."

Google gives the test as arithmetic: take the segment's virtual address, add its memory size, divide by 16 KB (0x4000), and check that the remainder is zero, or (VirtAddr + MemSiz) % 0x4000 == 0. You read the values with llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'.

The guide works one example all the way through, and it is worth reproducing because the margin is so small. For a segment with VirtAddr 0x00000000000dfaf0 and MemSiz 0x01510, the sum is 0xE1000, and 0xE1000 % 0x4000 leaves 0x1000. Google's conclusion is blunt: "Since 0x1000 is not zero, this .so file isn't 16 KB compliant." A remainder of zero passes, and a library with no RELRO segment at all is trivially compliant.

The repair belongs to whoever linked the binary. For NDK r27 or lower Google documents the linker flags -Wl,-z,max-page-size=16384 and -Wl,-z,common-page-size=16384, applied through LOCAL_LDFLAGS in Android.mk or the equivalent CMake options, while NDK r28 and higher compile 16 KB-aligned by default. One caveat travels with this: Google notes that libc++_shared.so from NDKs r26 and lower may itself not be 16 KB aligned, so a project can fix its own libraries and still link a stale C++ runtime. The practical meaning of all this is that a library can be reported as aligned and still die on first launch, so the alignment pass and the runtime test are two different tasks.

Which component shipped the library

Play Console names a file, never an owner. The table below maps the libraries you are most likely to find in a modern bundle to the version baselines their own vendors document, so you know whether to upgrade your toolchain or go looking for a dependency author.

Stack	What you will typically see	Documented baseline	Where to act
Java or Kotlin only	No lib folder	Google: "your app already supports 16 KB devices"	Nothing to rebuild; Google still recommends one 16 KB test run
React Native	React Native's own native libraries, including the Hermes engine, plus every native module you installed	React Native 0.77 shipped "16KB page support"; the release post says the framework "is ready to fully support 16 KB page size"	Upgrade the framework, then audit native modules one at a time
Flutter	The Flutter engine, your compiled Dart code, and any plugin with its own native code	Google's announcement notes that Flutter and React Native "already offer compatible versions"; your Gradle plugin version still decides bundle packaging	AGP 8.5.1 or higher, then update plugins; our Flutter publishing guide covers the release sequence
Unity	Engine libraries plus every native plug-in and package in the project	Google's Unity page states Unity has 16 KB page support for Unity 2021, 2022 and Unity 6; Unity documents 6000.0.38f1, 6000.1, 2022.3.56f1 and 2021.3.48f1 as the supported lines and warns during the build when a plug-in .so is 4 KB aligned	Engine patch level, then native plug-ins
Third-party SDK	Advertising, analytics, mapping, ML or payment SDKs that bundle their own .so	Google: "because some SDK prebuilts or SDK versions aren't 16 KB compatible, you should check the website for each SDK provider"	Upgrade, or replace the SDK; you cannot recompile someone else's binary

Your own toolchain sets the floor for everything above it: Google's guide states that with AGP 8.5.1 or higher, NDK r28 or higher and 16 KB-compatible prebuilt dependencies, "your app is 16 KB compatible by default", and that NDK r28 and higher compile 16 KB-aligned by default. Neither one can repair a binary that somebody else compiled, which is why identifying the file comes before upgrading anything.

Prove the fix in a 16 KB environment before you upload

Static checks tell you the bytes are aligned. A runtime test tells you nothing in your code assumed a 4 KB page. Google supports both paths:

• Emulator. In Android Studio, open Tools > SDK Manager, enable Show Package Details, and install a "Google APIs Experimental 16 KB Page Size" system image for ARM64 or x86_64, then create an Android 15 virtual device on it.
• Physical device. The "Boot with 16KB page size" developer option is available on Pixel 8 and 8 Pro, Pixel 8a (Android 15 QPR1 or higher), Pixel 9, 9 Pro and 9 Pro XL (Android 15 QPR2 Beta 2 or higher) and Pixel 9a (Android 16 or higher).
• Watch for the compatibility warning. Google documents that the package manager runs an app in 16 KB backcompat mode when its .so files have 4 KB LOAD alignment or its uncompressed libraries are 4 KB zip aligned, and that the app "displays a warning when it's first launched". That warning is your signal that the checks above did not all pass.

In our own workflow the order is fixed: APK Analyzer for the library list, llvm-objdump for the file that fails, then the bundle config and zipalign checks once the file is replaced, and only then a run on a 16 KB image. We run closed-testing campaigns on physical Samsung, Pixel, Xiaomi and OnePlus devices across Android 11 to 15 in more than 80 countries, and we have analyzed over 1,500 closed-testing campaigns from our own campaign records. Build-level checks like these are still run on your machine before you upload, because no test track can tell you which library was linked at 4 KB.

If the warning appears in the middle of a closed test

This is where a technical problem turns into a scheduling one, and it is the part Google's documentation does not address. Analysis rather than policy: Google's closed testing requirement is measured on tester opt-ins over 14 continuous days (see the requirement explained), not on a frozen build, so replacing a bundle mid-test does not by itself restart your campaign. What it does cost is time you had not budgeted, and a native library investigation has no predictable end date.

The practical sequence that hurts is a target API bump surfacing the warning on day five of a test, followed by a week of rebuilding native dependencies while a tester group has to stay intact around you. The mitigation is boring but effective: push rebuilt bundles to the same track, keep the same tester group, and separate the build problem from the engagement problem.

Three options, in the order we would take them, offered as recommendations from our own workflow rather than Google rules. First, time-box the diagnosis: the command sequence above takes minutes, so run it before making any scheduling decision. Second, if one prebuilt library is responsible, fix it and push the rebuilt bundle to the same track without disturbing the tester group, because the requirement as documented turns on testers staying opted in over 14 continuous days rather than on a frozen version code (see the requirement explained). Third, if the fix depends on a vendor release date you do not control, decide whether the current run can finish before the new build is ready or whether to start over later with a compliant build from day one. What to avoid is churn: swapping tracks, deleting the test or rebuilding everything at once trades one unknown for three.

Our related reading covers both sides: the failure patterns that get production access refused and our numbers on Google Play app rejections. If the bump that pulled you into scope was a first release rather than an update, the first-launch roadmap sequences these requirements in order.

Frequently Asked Questions

Does Google Play reject an app for not supporting 16 KB page sizes?

Today you see a compatibility warning in Play Console, and Google's documented consequence starts on February 1, 2027, when non-compliant updates cannot be released. Google's page does not describe removal of an app that is already published. The warning is worth clearing before then anyway, because a 16 KB-aligned build works on both 4 KB and 16 KB devices.

My local build passes every check but Play Console still warns. Why?

Because Play does not install your APK, it generates one from your bundle using bundletool and the packaging settings your Android Gradle Plugin wrote into it. Google documents this failure directly for AGP 8.3 to 8.5: the app "may appear to work, but when built from a bundle in Play, it won't install." Check bundletool dump config for PAGE_ALIGNMENT_16K before trusting a local install.

I do not write C++. Do I still need NDK r28?

Only if you build native code. If your app and every library inside it are Java or Kotlin, Google says it already supports 16 KB devices. In practice most apps reach native code indirectly, through an SDK or a plugin that ships a prebuilt .so, so the APK Analyzer step is how you find out which case you are in.

Which date should I plan around, November 1, 2025 or February 1, 2027?

February 1, 2027. That is the wording on Google's page-size guide as last updated 2026-09-16. November 1, 2025 was the original 2025 announcement and May 31, 2026 was the close of the extension window Google confirmed for developers who needed longer; articles quoting either are describing history.

Does the requirement apply to internal and closed testing tracks?

Google frames the rule as apps "on Google Play" and documents the block in terms of releasing updates, with no track-level exemption published on the page-size guide. Developers do report seeing the warning when uploading to testing tracks, which is community evidence rather than policy. The safe reading is that a bundle destined for any Play track should be compliant.

How do I check a library that comes from an SDK I did not build?

You check it the same way you check your own: extract it and run llvm-objdump -p against it. You cannot recompile someone else's binary, so the options are an updated SDK version that ships a 16 KB build, or replacing the SDK. Google's advice is to check each SDK provider's site for a compatible version.

Will my app disappear from Google Play?

Not because of this rule. The documented outcome from February 1, 2027 is that non-compliant updates cannot be released. Existing published versions are treated separately by Google's own wording, and a Product Expert in Google's developer forum says existing apps are not removed from the store. Treat that forum answer as community guidance and the page-size guide as the controlling source.

Sources

• Support 16 KB page sizes, Android Developers. Google's controlling page for this requirement, last updated 2026-09-16 UTC, read 2026-10-15. Source for the scope sentence, the February 1, 2027 date, the AGP 8.3 to 8.5 warning, the alignment commands, the RELRO rule, the emulator images, the developer option device list and the backcompat conditions.
• Prepare your apps for Google Play's 16 KB page size compatibility requirement, Android Developers Blog, May 2025. Original November 1, 2025 announcement and the instruction to check build compliance in the app bundle explorer.
• Transition to using 16 KB page sizes for Android apps and games using Android Studio, Android Developers Blog, July 2025. AGP 8.5.1 and NDK r28 defaults, emulator targets.
• Clarification of the 16KB page size deadline and information on extensions, Google Play Developer Community, July 2025. Confirmation that the original deadline was November 1, 2025 and that an extension to May 31, 2026 could be requested.
• Target API level requirements for Google Play apps, Play Console Help. The August 31, 2026 requirement to target API 36, the extension to November 1, 2026, and the permanently private app exception.
• Build your game in Unity, Android Developers (last updated 2026-02-26), Unity Android requirements and compatibility, and Unity's 16 KB support thread. Engine version baselines and the build-time warning for 4 KB aligned plug-ins.
• React Native 0.77 release post, January 2025, for the framework's 16 KB page support statement.
• App must support 16 KB memory page sizes and Your app does not support 16 KB memory page sizes, Google Play Developer Community. Developer-reported console wording and answers from a Diamond Product Expert, used as community evidence only.