App Must Support 16 KB Memory Page Sizes: How to Fix It

The warning is short, it names a filename at most, and it arrives after you already thought the build was finished. That is why the same three wrong turns keep happening: developers trust a deadline that moved, upgrade a framework and assume the job is done, or check one local APK and never look at the bundle Google actually builds from. This post is organised the way the problem actually resolves - identify, attribute, repair, prove - and everything on it is current as of August 5, 2026, checked against Google's page-size guide the same day that page was last updated. Where the evidence is a maintainer's issue tracker rather than an official release note, the page says so on the card instead of rounding it up to a fact.

Fix It in Three Steps

The requirement itself is narrow. Google's page-size guide says apps targeting Android 15 (API level 35) or higher must support 16 KB memory page sizes on 64-bit devices, and that from February 1, 2027 you will not be able to release updates that do not. It applies to native code only. If your app and every library and SDK inside it are pure Java or Kotlin, Google states that your app already supports 16 KB devices. The trouble is that most developers who see this warning believe they are in that category and are not.

The whole decision, on one screen

Before you change a single dependency version, walk this. It takes about two minutes and it is the difference between fixing the right thing and upgrading eleven packages that were never the problem.

What the Play Console Warning Actually Means

The wording matters because the panic version of this story travels faster than the accurate one. Read the strings Google actually shows, and the scope becomes narrow and manageable.

Two readings of that card are commonly wrong. First, "Action by Feb 1, 2027" is not a countdown to deletion; Google's own text on the same page describes the outcome as being unable to release those updates. Second, the Extension granted string appears in Google's screenshot, but that does not establish that an extension request flow is currently open to you. Treat an extension as real only if you can see the option inside your own Play Console.

Which deadline did you actually read?

Three dates are circulating and only one is live. Pick whichever one you saw and this resolves its status against Google's current page, which was last updated on August 5, 2026.

Does the 16 KB Requirement Affect My App?

Pure Java or Kotlin apps

Google is unambiguous here: if your app and all of its libraries and SDKs use only Java or Kotlin, your app already supports 16 KB devices. Google still recommends testing in a 16 KB environment to catch unexpected regressions, which costs you one emulator run.

The catch is the phrase "and all of its libraries and SDKs." A single database, analytics, crash reporting, media, maps, machine learning or security dependency can add native binaries to a project whose own source contains nothing but Kotlin. "I did not write C++" is not evidence. The lib folder is.

Flutter, React Native, Unity, Kivy and no-code builders

These stacks ship native runtimes, engine binaries and plugin libraries by design, so they are almost always in scope. Google explicitly names third-party app builders that use native libraries as a way an app can be affected even when its author never wrote C or C++. What varies is not whether you have native code but which package supplied the piece that is failing, which is why attributing the filename comes before any upgrade.

How to check, exactly

Open the release APK, expand lib, and look at the ABI folders inside it, normally arm64-v8a and x86_64. Any shared object files present means your app uses native code. No .so files and no lib folder means this APK does not use native code at all. The Alignment column in the analyzer displays warning messages for the files that have alignment problems, which is the fastest way to go from "something is wrong" to a filename.

Why a 4 KB Binary Fails on a 16 KB Device

That is the whole mechanism, and it explains the one number you will keep seeing. Alignment is expressed as a power of two: 2**12 is 4096 bytes, 2**14 is 16384 bytes. Google's rule is that each LOAD segment in a native library must be aligned to 2**14 or greater. A library built at 2**14 works on both 4 KB and 16 KB devices, because 16384 is a clean multiple of 4096. A library built at 2**12 only works on the smaller page size. That asymmetry is why the fix is always "raise the alignment" and never "detect the device."

There is a second, entirely separate constraint that lives outside the library. Uncompressed native libraries stored inside an APK must also sit on a 16 KB boundary within the ZIP archive itself. That is a packaging property, checked with zipalign and configured by your build plugin, and it can be wrong while every library inside is perfectly aligned. Keeping those two ideas apart is the single most useful thing you can carry out of this section.

The Shortest Fix for Each Framework

Every baseline in one table

Confidence labels carry the same meaning everywhere on this page. VERIFIED means a current primary source states it directly. PARTIAL means a reliable source supports the core claim but not every implementation detail. REPORTED means the evidence is a maintainer's issue tracker or developer reports rather than an official release note.

Find the Exact Library Causing the Error

Start in APK Analyzer

Open Build > Analyze APK..., load the release APK, and expand lib. Inside you will see one folder per ABI, normally arm64-v8a and x86_64. The Alignment column displays warning messages against files that have alignment problems. Android Studio's own warnings and Lint will also highlight noncompliant native libraries, so you may see the same finding surfaced in more than one place.

Record every flagged filename before you touch a single version number. Check both ABI folders separately: it is entirely normal for arm64-v8a to pass while x86_64 fails, or the reverse, because they are different binaries built by potentially different pipelines.

Decode the command line output

If you would rather work in a terminal, Google ships check_elf_alignment.sh, which reports ALIGNED or UNALIGNED for an APK, and you can inspect a single library directly with llvm-objdump. Both need Android SDK Build-Tools 35.0.0 or higher. Paste whatever they print below and this will read it back to you.

Work out which dependency owns it

Play Console and APK Analyzer both give you a filename and no owner. Type it in below and this will tell you what is known about that binary, with the evidence quality attached, and give you the search commands with your filename already in place.

Verify the App Bundle, Not Only the Local APK

This is the mechanism behind the most frustrating version of the problem: the developer upgrades everything, inspects the local APK, sees clean output, uploads, and the warning is still there. Nothing they checked was wrong. They just never checked the thing Play evaluates.

So run this against the bundle you are about to upload, every time:

bundletool dump config --bundle=app-release.aab | grep alignment

PAGE_ALIGNMENT_16K is the result you want. PAGE_ALIGNMENT_4K means the bundle is telling bundletool to package native libraries on 4 KB boundaries, so every APK Play builds from it will be wrong. Google warns specifically that Android Gradle Plugin 8.3 through 8.5 can produce exactly this mismatch: the local build looks aligned, and the app Play builds from the bundle will not install correctly on a 16 KB device. The preferred fix is moving to Android Gradle Plugin 8.5.1 or later.

Every command, with your own filenames in it

Type your filenames once. Every command below rewrites itself, and each tab shows the exact output that counts as a pass, so you are never guessing whether a result was good.

AGP, NDK and the Packaging Trap

The dangerous middle ground is Android Gradle Plugin 8.3 through 8.5. In that range a local build can look completely correct while bundletool does not ZIP align the APKs it produces from your bundle for Play, and Google's wording is blunt about the outcome: the app built from that bundle will not install properly. If you are on 8.5.0 and your local APK passes every check you can think of, this is the first thing to rule out.

Build settings reference

The part that packaging cannot fix

If your own C or C++ assumes a page size, no build flag saves you. Remove hard-coded 4096 values and any reliance on a fixed PAGE_SIZE constant, query the real value at runtime with getpagesize() or sysconf(_SC_PAGESIZE), and review every mmap() call along with any argument you are page-aligning by hand. This is the class of failure where an app installs cleanly on a 16 KB device, passes the bundle checks, and then crashes the first time it touches memory mapping.

Test on a Real 16 KB Environment

You have three practical routes and two specialist ones. Pick whichever you can actually get to today; there is no quality difference between them for the purpose of catching page-size failures.

adb shell getconf PAGE_SIZE

What to actually exercise

Once the environment is confirmed, the useful test pass is not "does it launch". Native failures cluster in the features that touch native code, so drive those deliberately: cold launch, navigation through the app, camera, database reads and writes, media playback and recording, authentication, background work, any machine learning or augmented reality feature, every native plugin surface, and anything in your own code that uses memory mapping. If a feature is powered by one of the libraries you just upgraded, that feature is the test.

Why the Warning Survives an Upgrade

Two of those deserve a caveat rather than a confident answer. No primary source establishes how long Google Play takes to reassess an uploaded bundle, so if your warning persists immediately after an upload, the honest move is to confirm the new version code appears under your latest releases and app bundles and then check again later, rather than to trust any specific number you read about processing times. And an app that runs only because backcompat mode intervened has not been fixed, it has been accommodated.

Third-Party Libraries That Keep Coming Up

Use this as a starting point when a filename looks familiar, then verify against that project's current releases and open issues. Where the evidence is a maintainer's issue tracker rather than a release note, the card says so.

How This Relates to the August 31, 2026 API 36 Deadline

Google Play requires new apps and app updates to target Android 16 (API level 36) from August 31, 2026, with an extension available to November 1, 2026. That is a manifest and behaviour change. The 16 KB rule is a binary compatibility change. A developer who bumps targetSdk on a Monday and sees a 16 KB warning on Tuesday has not broken anything: the native libraries were already built for 4 KB pages, and the higher target level simply brought the app into scope of a check that was always going to apply.

Practically, treat them as one migration with two proofs. You will be raising the target level anyway, so schedule the native library audit into the same release rather than discovering it during the API 36 scramble. For the full set of form factor levels, exceptions and extension mechanics on the target API rule, see our Google Play target API 36 deadline post, and for the whole sequence from account to production our 2026 publishing requirements post.

The Pre-Upload Release Gate

Your progress is stored in this browser only. Nothing is sent anywhere, and clearing your browser data clears it.

Where This Collides With Closed Testing

The sequence that hurts goes like this. A personal developer account starts a closed test, the 14-day continuous opt-in window begins, and somewhere in the middle of it a target level bump surfaces a 16 KB warning. Now the developer is rebuilding native dependencies while a tester group has to stay intact around them. Uploading a new build to the track is fine, and Google encourages developers to keep updating during a test. What breaks the run is the tester side going quiet.

That is the part PrimeTestLab holds steady. We supply 12 real testers on real devices spanning Android 7 to 17, opted in and held for the full 14 days, so your rebuild happens against a stable test rather than a collapsing one. Testing starts in 4-6 hours, and we have run this across 7,400+ apps in 120+ countries with a 99.9% success rate.

Recruiting testers yourself versus a managed run

To be direct about the boundary: we do not rebuild your native libraries and this post is not a sales pitch for doing so. The 16 KB work is yours, and everything above this section is written to make it as short as possible. What we take off your plate is the tester requirement running alongside it, so the two problems stop competing for the same fortnight.

Frequently Asked Questions

Bottom Line