Guide · Last updated May 13, 2026

Fix “Not compatible with 16 KB page size devices” on Google Play

If the Play Console shows the warning “Not compatible with 16 KB page size devices” next to your release, your APK or AAB ships native libraries that were built for the old 4 KB memory page layout. As of May 2026, this is no longer a friendly nudge—Play is actively gating uploads that target Android 15 and rejecting non-compliant releases. This guide explains the rule, walks through the fix on stock Android Gradle projects, and points to framework-specific notes for Flutter, React Native, and Unity.

1. What the 16 KB rule actually is

All modern operating systems load executable code in chunks called pages. Until 2024, every Android device used 4 KB pages. Newer phones with more RAM (Pixel 8 and later, plus many flagship Android 15 devices) ship with a kernel built around 16 KB pages. Bigger pages mean fewer page-table lookups, faster app launches, and better battery life—but they require every native segment to be aligned on a 16 KB boundary.

In ELF terms, every PT_LOAD segment in your shared library (.so) has a field called p_align. Older toolchains emit p_align = 0x1000 (4 KB). For a library to be safe on a 16 KB device, every load segment must use p_align ≥ 0x4000 (16,384 bytes). On top of that, the APK zip layout needs to store those .so files uncompressed and 16 KB-aligned, so Android can map them straight from disk without copying them into RAM.

That is the entire rule: 16 KB-aligned ELF segments inside a 16 KB-aligned zip. Almost every other issue you’ll see in the Play Console traces back to one of those two checks.

2. Why Play is rejecting apps now

Google originally announced the 16 KB compatibility requirement in May 2024 and gave a year of runway. Starting in November 2025, the Play Console began surfacing a hard warning for any new app or update targeting Android 15 (API 35) that still ships 4 KB-aligned libraries. Depending on which Play Console screen you’re on, the warning is phrased a few different ways—and all of them describe the same underlying problem:

  • “Not compatible with 16 KB page size devices”

    Shown on the release detail screen. “Some of the native libraries (.so) in your app are not 16 KB aligned. Apps that don’t support 16 KB page sizes may not work on 16 KB devices.”

  • “Your app does not support 16 KB memory page sizes”

    Shown in the App bundle explorer and on policy emails sent after upload.

  • “Your app is affected by Google Play’s requirements on 16 KB page sizes”

    Shown in the Play Console inbox and on the Pre-launch report for releases that already shipped.

All three messages mean the same thing: at least one 64-bit .so file inside your APK or AAB is still built (or packed) for the old 4 KB page layout. The fix is the same regardless of which copy you saw.

The warning has effectively become a release blocker. Some teams can still publish to closed tracks, but production rollouts to Android 15 devices are gated. If you are reading this guide because your release was rejected today—the deadline has passed and there is no extension. The fix takes a few hours for most apps; the bulk of the work is rebuilding any third-party SDK that ships its own .so files.

3. How to detect the problem

You have three good ways to confirm whether a specific APK or AAB is affected, in increasing order of depth:

  1. Drop it into 16kb Checker. You’ll get a table of every 64-bit .so with its p_align, zip storage flag, and a clear pass/fail badge.
  2. Run readelf from the command line. Unzip the APK, then for each library run readelf -lW lib/arm64-v8a/libfoo.so and confirm every LOAD line shows Align 0x4000.
  3. Use APK Analyzer inside Android Studio. It will show you the ABI list, library sizes, and—on the latest builds—a 16 KB compatibility indicator.

Note that 32-bit ABIs (armeabi-v7a, x86) are not subject to the 16 KB check, because 32-bit kernels don’t support 16 KB pages. 16kb Checker labels those entries as “skipped” rather than failing them—which is the same logic Play uses.

4. Fix it on a standard Android Gradle project

4.1 Upgrade the NDK

NDK r27 and later emit 16 KB-aligned PT_LOAD segments by default. For a clean break, target NDK r28 or newer (it became the recommended stable line in February 2026). Update android/build.gradle:

android {
  ndkVersion "28.0.13004108"
  compileSdk 35

  defaultConfig {
    minSdk 21
    targetSdk 35
  }
}

4.2 Add the 16 KB linker flags

If you build with CMake or ndk-build, pass the linker flags explicitly so older NDKs (r26 and below) still emit aligned binaries:

# CMakeLists.txt
target_link_options(my_lib PRIVATE
  "-Wl,-z,max-page-size=16384"
  "-Wl,-z,common-page-size=16384"
)

4.3 Store .so files page-aligned in the APK

Even with a perfectly built library, the APK packaging step has to keep it uncompressed and aligned to the 16 KB boundary inside the zip central directory. In modern Android Gradle Plugin (8.5+) this is the default, but double-check the manifest and the packaging block:

<!-- AndroidManifest.xml -->
<application
  android:extractNativeLibs="false"
  ...
/>
// app/build.gradle.kts
android {
  packaging {
    jniLibs {
      useLegacyPackaging = false
    }
  }
}

4.4 Rebuild every prebuilt .so

This is where most teams get stuck. Even after upgrading the NDK, any third-party SDK that ships prebuilt native binaries (analytics SDKs, ad networks, payments, OCR, audio engines, etc.) must be updated to a release built with NDK r27 or later. Check each vendor’s changelog for the phrase “16 KB page size” or “page alignment” and bump to that version.

5. Verify the fix before you re-upload

Don’t guess—prove it. Run any of the following on the freshly built artifact:

# Per-library ELF check
$ readelf -lW app/build/outputs/apk/release/lib/arm64-v8a/libfoo.so \
    | grep LOAD
  LOAD  0x000000 0x00000000 0x00000000 0x12abc 0x12abc R E 0x4000
  LOAD  0x013000 0x00013000 0x00013000 0x004b8 0x004b8 RW  0x4000

# Whole APK zip alignment
$ zipalign -c -P 16 -v 4 app-release.apk
  Verification successful

Or simply re-scan in 16kb Checker—if every 64-bit library shows a green badge and the zip alignment line reads PASS, you’re good to upload to Play Console. We recommend promoting to an internal test track first and confirming the Play Console release detail no longer shows the warning.

6. Framework-specific notes

Flutter

Flutter 3.27 and later compile your Dart code with a 16 KB-aligned engine; the harder problem is plugins with native code. See the focused walk-through in our Flutter 16 KB guide.

React Native

React Native 0.76 and newer use Hermes built with NDK r27. If you’re on 0.74 or earlier with JSC + Reanimated, you’ll likely see a failure on libhermes.so or libreanimated.so. The fix is to upgrade React Native and any third-party native modules to their 16 KB-ready release.

Unity

Unity emits its own native libraries via IL2CPP, which means the toolchain version matters more than your project settings. The walk-through is in our Unity 16 KB guide.

Pure Kotlin / Java apps

If your app has no NDK code of its own, the issue is almost always an SDK you depend on. Run a scan, look at which .so paths fail (the path usually points at the SDK), and update that SDK.

7. Common questions

Does the rule apply to apps that don’t target Android 15?

For now the hard gate is on apps that target API 35 or newer. Even if you’re on targetSdk 34, the Play Console will still surface the warning because Play’s target-version policy will force you onto API 35 within the next release cycle.

Will fixing 16 KB alignment make my APK bigger?

Marginally. Each .so file is padded out to a 16 KB boundary inside the zip, which typically adds a few kilobytes per library. The on-device install size is often identical or smaller because the library no longer needs to be extracted to disk.

What about 32-bit (armeabi-v7a) libraries?

The 16 KB requirement only applies to 64-bit ABIs (arm64-v8a and x86_64). 32-bit binaries can stay 4 KB-aligned, but Play also requires every app with native code to ship a 64-bit variant, so most teams drop the 32-bit build entirely.

8. References


Want to confirm your build right now?

Scan your APK or AAB

Free · No signup · Runs in your browser