Fix 'Your app is affected by Google Play's 16 KB page size requirement' in React Native

If Google Play just told you "Your app is affected by Google Play's 16 KB page size requirement," it means one or more of the native .so libraries inside your AAB are not aligned to a 16 KB boundary, and Play will start blocking those builds for new submissions and updates after 31 May 2026. The fix is almost always the same three moves: find which .so files are misaligned with check_elf_alignment.sh, upgrade your Android NDK and Android Gradle Plugin so the linker pads segments to 16 KB, and rebuild your offending native dependencies. This post walks the diagnosis end to end so you stop guessing and ship a compliant build.

I have done this on a few React Native and Expo apps now, and the pattern is consistent enough that I can usually tell you which dependency is the culprit before I even unzip the AAB. Let me show you how to confirm it yourself.

What does the Google Play 16 KB page size warning actually mean?

It means Android is moving from 4 KB memory pages to 16 KB pages on newer 64-bit devices, and your shared libraries have to be laid out so they load correctly on both. Apps that ship arm64-v8a or x86_64 native code need every ELF segment aligned to 16 KB, otherwise the loader can fail on 16 KB devices.

The short version: this is purely a 64-bit problem. Your 32-bit armeabi-v7a libraries are irrelevant here because those devices never run 16 KB pages. The warning fires when Play inspects the lib/arm64-v8a/ and lib/x86_64/ folders inside your AAB and finds a .so whose LOAD segments are not aligned to 0x4000 (16384 bytes).

Two things are being checked, and people conflate them:

1. ELF segment alignment, the p_align value of LOAD segments, which must be at least 16384.


2. The uncompressed .so being page-aligned and stored uncompressed inside the APK/AAB ZIP, which AGP handles for you with useLegacyPackaging false.

How do I find which .so files are not 16 KB aligned?

Use Google's check_elf_alignment.sh script against your built AAB or APK. It unzips the archive, runs objdump or llvm-readelf over every .so, and prints ALIGNED or UNALIGNED per file so you know exactly which dependency to chase.

First build a release AAB so you are testing the real artifact, not a debug build:

cd android
./gradlew bundleRelease
## output: android/app/build/outputs/bundle/release/app-release.aab

Then grab the script from the Android platform tools and run it:

## Fetch the official script
curl -O https://raw.githubusercontent.com/android/ndk-samples/main/16KbPageSizes/check_elf_alignment.sh
chmod +x check_elf_alignment.sh

## Run it against your AAB
./check_elf_alignment.sh app/build/outputs/bundle/release/app-release.aab

You will get output that looks roughly like this:

=== ELF alignment ===
lib/arm64-v8a/libreactnative.so: 16384 ALIGNED
lib/arm64-v8a/libhermes.so: 16384 ALIGNED
lib/arm64-v8a/libimagepipeline.so: 4096 UNALIGNED (load segment)
lib/arm64-v8a/librnscreens.so: 16384 ALIGNED
lib/arm64-v8a/libsqlite3x.so: 4096 UNALIGNED (load segment)

Found 2 unaligned libs (only arm64-v8a/x86_64 matters).

The two UNALIGNED lines are your entire problem. Note which dependency each .so belongs to. libimagepipeline.so is Fresco, used by older image stacks; libsqlite3x.so would point at a SQLite-based storage library. That mapping is the real diagnostic work, and the next section covers the usual offenders.

If you do not want to fetch the script, you can spot-check a single file by hand:

unzip -o app-release.aab -d /tmp/aab
llvm-readelf -l /tmp/aab/base/lib/arm64-v8a/libsqlite3x.so | grep LOAD
## Look at the Align column. 0x4000 is good. 0x1000 means 4 KB, unaligned.

0x4000 is 16 KB and passes. 0x1000 is 4 KB and fails.

Which React Native native libraries are the usual offenders?

In my experience the misaligned .so files almost never come from React Native core anymore. React Native itself, Hermes, and most of the heavily maintained community modules became 16 KB aligned well before enforcement. The libraries that get apps rejected are older or thinly maintained ones that ship prebuilt binaries compiled with an old NDK.

Here is the cheat sheet I work from when triaging an unaligned AAB.

buildscript {
    ext {
        buildToolsVersion = "35.0.0"
        minSdkVersion = 24
        compileSdkVersion = 35
        targetSdkVersion = 35
        ndkVersion = "28.0.12433566"   // r28 or newer
    }
    dependencies {
        classpath("com.android.tools.build:gradle:8.5.1")
    }
}

android {
    // ...
    defaultConfig {
        externalNativeBuild {
            cmake {
                arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
            }
        }
    }
}

-Wl,-z,max-page-size=16384

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging = false
        }
    }
}

cd android
./gradlew clean
rm -rf ~/.gradle/caches/transforms-*   # nuke cached prebuilt transforms
./gradlew bundleRelease

## After editing node_modules/some-rn-lib/android/build.gradle
npx patch-package some-rn-lib

When all five pass, upload the AAB. The Play Console warning clears once it scans a compliant build, and you are set ahead of the 31 May 2026 enforcement.

One honest caveat: the static script and Play's scanner can disagree at the margins, usually because of how a specific .so declares its segments. If the script says aligned and Play still complains, the 16 KB emulator test plus a careful read of llvm-readelf -l on each library is how I have always found the straggler.

If you are staring at this rejection on a shipping app and the offending library turns out to be something abandoned in your dependency tree, that is exactly the kind of stuck native build I untangle for clients. Reach out through my contact page ↗ and send me the check_elf_alignment.sh output; that one paste tells me most of what I need to scope the fix.