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

The short answer: a native shared library inside your app bundle is still built for 4 KB memory pages. The fix is three moves in order: find the failing .so file, update the package that ships it, then verify the artifact Google actually builds from, which is the app bundle rather than the APK sitting in your local build folder. If your app and every library and SDK inside it are pure Java or Kotlin, Google states the app already supports 16 KB devices and there is nothing to rebuild.

Google currently publishes more than one date for this requirement, and older articles still rank with dates that have been superseded. Its Play Console technical quality requirements page lists 16 KB support as a current requirement and states that the requirements on that page are "not optional". The Android page-size guide, last updated 2026-09-16, says that starting 1 February 2027, app updates that do not support 16 KB memory page sizes cannot be released.

This guide covers what Google requires today, which deadline to plan around, how to name the exact library that fails, the shortest fix for each framework, the two verification checks that must both pass, and what to do if the warning appears while your 14-day closed test is already running. Policy claims are cited to Google's own documentation. Where a statement comes from a vendor, a community thread, or our own campaign records, it is labelled as such.

What Google requires today, and which deadline applies

Google requires apps that contain native code to support 16 KB memory page sizes on 64-bit devices, and apps targeting Android 15 (API level 35) or higher are in scope. Google's Play Console technical quality requirements page states it directly: "Apps that contain native code must support devices with 16 KB memory page sizes. Java/Kotlin only apps are compatible by default." The Android page-size guide adds the scope and the release-block date: "all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play" and "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."

The two pages do different jobs. The technical quality requirements page tells you the rule is live now and that it is not optional: "All of the requirements posted in this page are not optional. Not meeting a requirement can affect an app's visibility and publishing capabilities on Google Play." The page-size guide tells you the date from which non-compliant updates are blocked. Treating 16 KB as a future problem is the wrong reading of the first page.

Which deadline should you plan around?

Three dates circulate in search results and in Play Console notifications. Only one appears on Google's current documentation, and Google does not announce date changes with a changelog, so the habit that matters is opening the page-size guide and reading the "Last updated" stamp at the bottom. It read 2026-09-16 when this article was written.

The honest summary: the requirement itself is listed as current, the enforcement date Google currently publishes is 1 February 2027, and Google has moved this timeline before. If your Play Console shows a different date on a warning card, your console is showing you your own account's state, and that wins over any date printed in an article, including this one.

Note also that the page-size rule is only one of the things a current release has to satisfy. Targeting API 36 brings its own set of behaviour changes, from edge-to-edge to predictive back, and that migration is covered separately in Google Play Target API 36 Rule (2026): Dates, Extension, Fix.

Two adjacent requirements most articles miss

The same Google page sets separate deadlines for two form factors, which matters if you ship a Wear OS or TV build from the same project: TV apps must meet the 64-bit and 16 KB requirements as of 1 August 2026, and Wear OS apps as of 15 September 2026. Those dates are already in the past, so a watch or TV build that contains native code is late now, not in 2027.

Does your app actually have native code?

You only need to fix something if your release artifact contains native shared libraries. Google's guide is explicit about the exempt case: "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." The qualification that trips people up is "including all libraries or SDKs". An app whose own source is 100% Kotlin still ships native binaries if an analytics, maps, payments, database, crash-reporting, machine-learning or ad SDK added them. "I never wrote C++" is not evidence. The lib folder is.

How to check, in about a minute

Open the release build in Android Studio, choose Build > Analyze APK..., and open your APK. Expand the lib folder and look at the ABI subfolders, normally arm64-v8a and x86_64. If there is no lib folder, or it holds no .so files, this APK contains no native code. If shared object files are present, the Alignment column flags the ones with alignment problems, and those filenames are your search keys for the next step. You can run the same inspection from the command line with Google's check_elf_alignment.sh script, which prints ALIGNED or UNALIGNED for the 64-bit shared libraries.

The fix in three steps

Every genuine fix is the same sequence: identify, attribute, repair, prove. Skipping to the repair is why developers upgrade eleven packages, rebuild, and see the same warning.

Step 1: Identify the failing .so

Take the filenames APK Analyzer flagged, or run check_elf_alignment.sh against your APK. To read the alignment yourself, use the NDK's objdump and look at the LOAD segments of one library:

llvm-objdump -p lib/arm64-v8a/libexample.so | grep LOAD
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14

Alignment is written as a power of two, so the reading is simple: 2**14 is 16,384 bytes and passes; 2**13 and 2**12 are 4 KB territory and fail. There is no partial credit. One unaligned LOAD segment in one library in one ABI is enough to keep the warning on your account. Write down which package shipped each failing file before you change any version number.

Step 2: Update whatever ships that library

If the library is code you compile, your toolchain fixes it. Google's documented path is Android Gradle Plugin 8.5.1 or higher for packaging, and NDK r28 or higher, which compiles 16 KB-aligned by default. If you are stuck on NDK r27 or lower, Google's guide gives the linker flags for your own CMake or ndk-build targets: -Wl,-z,max-page-size=16384 and -Wl,-z,common-page-size=16384. If you cannot move AGP past 8.5, Google's alternative is to switch to compressed shared libraries with packagingOptions { jniLibs { useLegacyPackaging true } }; on AGP 8.0 or lower you must also set android.bundle.enableUncompressedNativeLibs=false.

If the library is prebuilt and arrived inside an SDK, plugin, engine or AAR, no flag in your project can rewrite it. Google's instruction is to "check the website for each SDK provider to determine which version to use with 16 KB", which in practice means upgrading, replacing, or asking the vendor for a rebuilt artifact. This is also why upgrading your framework often changes nothing: the framework's own binaries become compliant while every third-party plugin stays exactly as non-compliant as it was.

One failure mode is worth knowing because it looks like a random crash rather than a Play warning. A RELRO segment whose start address plus memory size is not 16 KB aligned can fault at runtime, which happens to .so files built with NDK r27 or lower without the flags above. Google's check is that (VirtAddr + MemSiz) modulo 0x4000 must equal zero.

Step 3: Verify the artifact, not the upgrade

Two separate checks must both pass, and they test different things: alignment inside the library, and alignment of the library inside the package.

The middle check is the one developers skip, and it explains the classic "it passes on my machine" case. A locally built APK can be perfectly aligned while the bundle you uploaded still instructs Play to generate 4 KB-aligned packages. Run the bundletool check against the .aab you are about to upload, not against a debug build. Google's own advice points the same direction: the May 2025 announcement tells developers to "visit the app bundle explorer page in Play Console to check your app's build compliance", so the console's reading of your uploaded bundle is the reading that counts.

Framework baseline: what each stack needs

Framework readiness and your app's compliance are two different questions. Your framework's version determines which binaries it ships itself; your app's artifacts determine whether the warning clears.

Community reports discuss specific Flutter and Gradle version combinations as sufficient. Treat those as community experience: they describe what worked for other developers, they are not a published requirement, and the artifact checks are the only thing that tells you whether your build passes. Google's blog names Unity and Unreal engine guides on developer.android.com if you ship a game.

Test the fix before you upload

Alignment checks prove packaging. They do not prove the app runs when the page size is different, because code that assumes 4 KB can still break at runtime. Google's guide asks for one run in a real 16 KB environment, and it names four ways to get one: an Android Emulator system image for 16 KB page size (listed under Android VanillaIceCream or higher in the SDK Manager), Cuttlefish images, a physical device with the 16 KB developer option enabled, or Samsung Remote Test Lab on a supported device.

Whatever you use, confirm the environment before you trust the test:

adb shell getconf PAGE_SIZE
16384

If the command returns 4096 you have been testing on a 4 KB device and the run proved nothing about 16 KB. On hardware, the developer option to boot in 16 KB mode exists on Pixel 8 and 8 Pro, Pixel 8a and Pixel 9-series devices with the relevant Android 15 QPR release, and Pixel 9a with Android 16 or higher. Then exercise the parts of your app most likely to assume a page size: native memory allocators, anything calling mmap() with page-aligned arguments, engines that cache buffers, and plugin code you do not own.

There is a second reason a passing run on your own phone proves little. On a 16 KB device, an app whose libraries are still 4 KB aligned, or whose packaged libraries are 4 KB zip aligned, runs in a compatibility mode that shows a warning the first time it launches. Google's wording is that this mode "allows some apps to work, but for best reliability and stability, apps should still be 16 KB aligned". An app that merely limps onto a new device is not what the requirement is for.

If the warning lands mid closed test

Rebuilding while a 14-day closed test is running is the situation that generates the most second-guessing, so it is worth stating the mechanics precisely. Google's requirement for new personal developer accounts is a closed test "with a minimum of 12 testers who have been opted in continuously for at least 14 days". That sentence constrains testers and time. It says nothing about which build they installed. A new app bundle added to the same closed track creates a new release, not a new test: your tester list, opt-in statuses and day counter carry over, and testers receive the new version automatically within a few minutes, while Google notes that additional changes can take several hours to become available.

Our recommendation, clearly labelled as ours: keep the same track and the same tester list, raise the version code, and push the rebuilt bundle onto the track that is already running. Do not pause or end the track while you fix the libraries, because ending a test stops updates reaching testers. The mechanics of adding a release to a running track are covered step by step in How to Set Up Closed Testing in Play Console. We would rather run the 14 days with a compliant build landing on day 6 than restart a window to protect a build number.

What Google does not say: Google does not publish a statement that a 16 KB warning blocks uploads to a closed track. It publishes 16 KB support as a current, non-optional technical quality requirement whose failure "can affect an app's visibility and publishing capabilities", and it publishes 1 February 2027 as the release-block date for updates. Anything more specific than that is inference. Our own records are the same: OnTesters has analysed more than 1,500 closed-testing campaigns on physical Samsung, Pixel, Xiaomi and OnePlus devices across Android 11 to 15 and over 80 countries, but those records are not tagged by build-warning type, so we do not quote you a frequency we have not measured.

Two related pages cover the neighbours of this problem. If your console shows an actual rejection rather than a compatibility warning, that is a different track entirely: see Google Play App Rejected: Every Rejection Reason and Fix. And if you want the full reasoning behind the day counter, Does Updating Your App Reset Google Play's 14-Day Test? works through what does and does not restart the window.

Frequently Asked Questions

Will Google Play reject my app for not supporting 16 KB page sizes?

Google does not describe 16 KB non-compliance as a review rejection. It describes it as a technical quality requirement that is not optional, and it states that from 1 February 2027, updates without 16 KB support cannot be released. In practice developers see a compatibility warning on the app bundle in Play Console rather than a policy rejection email. Treat a rejection email as a different problem with a different fix.

Does a pure Kotlin or Java app have to do anything?

Not for its own code. Google states that an app using only Java or Kotlin, including all of its libraries and SDKs, already supports 16 KB devices. The work is confirming that last clause, because one dependency can add native binaries to an otherwise pure Kotlin app. Open the release APK, check for a lib folder, and you have your answer.

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

Plan around the date on Google's current page-size guide, which is 1 February 2027, and re-check it by reading that page's "Last updated" stamp before you commit to a release schedule. The November 2025 date comes from Google's May 2025 announcement and still appears in search results; the May 2026 date appears in community threads about extensions. Google has moved this timeline before, which is exactly why the page, not an article, is the source of record.

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

Because the library alignment inside a package and the alignment Play requests when it generates APKs from your bundle are separate properties. Run bundletool dump config --bundle=your.aab | grep alignment on the exact bundle you uploaded. If it prints PAGE_ALIGNMENT_4K, the bundle is instructing Play to produce 4 KB-aligned packages no matter how clean your local APK looks, and Google's documented fix for that is AGP 8.5.1 or higher, or compressed shared libraries if you cannot upgrade.

I don't write C++. Do I still need NDK r28?

Only if something in your dependency tree compiles native code. NDK r28 and higher compile 16 KB-aligned by default, which is why it is the default advice for projects that build their own libraries. If your failing .so comes from an SDK, the fix belongs to that SDK's version, not to your NDK. Update the NDK when your project builds native code, and update the vendor package when it does not.

Which SDK shipped the unaligned library?

Start from the filename. Search your project for that .so name across Gradle dependencies, plugin configurations and bundled AARs, then check the vendor's release notes for a 16 KB-compatible version. Google's guide warns that SDK prebuilts vary, so the same app can pass after one package is updated and still fail on the next dependency you add. Re-run the alignment check after every native dependency change.

Does fixing 16 KB support reset my closed testing clock?

No. The clock counts opted-in testers over consecutive days, not builds. Push the compliant bundle to the same closed track with a higher version code, keep your 12 testers opted in, and the counter continues. The full breakdown of what resets the 14-day window covers the edge cases, including a tester opting out and rejoining later.

Sources

• Google: Support 16 KB page sizes - the primary source for the API 35 scope, the 1 February 2027 release-block date, the Java/Kotlin exemption, the APK Analyzer and check_elf_alignment.sh workflow, the AGP 8.5.1 packaging guidance and the compressed-library fallback, NDK r28 defaults and the r27 linker flags, the bundletool and zipalign verification commands, the RELRO alignment formula, the emulator and device testing options, and 16 KB backcompat mode. Last updated 2026-09-16 when consulted.
• Google Play Console Help: Play Console technical quality requirements - the source for the statement that apps containing native code must support 16 KB memory page sizes while Java/Kotlin only apps are compatible by default, for the requirement that these standards are not optional, and for the TV (1 August 2026) and Wear OS (15 September 2026) dates.
• Google Android Developers Blog: Prepare your apps for Google Play's 16 KB page size compatibility requirement - the source for the original 1 November 2025 announcement wording, for the instruction to check build compliance in Play Console's app bundle explorer, and for Google's statement that popular SDK providers including React Native and Flutter already offer compatible versions.
• Google Android Developers Blog: Transition to 16 KB page sizes using Android Studio - the source for the AGP 8.5.1 and NDK r28 toolchain advice, the instruction to remove hard-coded 4096 and PAGE_SIZE assumptions, and the adb shell getconf PAGE_SIZE verification step.
• Google Play Console Help: App testing requirements for new personal developer accounts - the source for the closed test requirement of at least 12 testers opted in continuously for at least 14 days quoted in the closed-testing section.
• Google Play Console Help: Set up an open, closed, or internal test - the source for how a new release reaches testers on a running closed track, the several-hours delay for additional changes, and what pausing or ending a track does to updates.
• React Native 0.77 release notes - the vendor statement that 0.77 is ready to fully support 16 KB page size, used for the React Native row of the framework table.
• Unity manual: Android requirements and compatibility - the vendor documentation for Unity's 16 KB support, the editor warning on 4 KB-aligned plugin libraries, and the instruction to update native plug-ins and rebuild.
• Google Play Developer Community thread on the 16 KB extension - community discussion of extension communications referencing 31 May 2026, cited only as community evidence and not as policy.
• OnTesters campaign records - more than 1,500 closed-testing campaigns on physical Samsung, Pixel, Xiaomi and OnePlus devices, Android 11 to 15, over 80 countries. Used only where labelled as ours; our records are not tagged by build-warning type, so no frequency claim is made from them.

Google revises Play Console Help and the Android developer guides without announcement. Where a quotation in this article and the live Google page disagree, the live page governs.