Fix React Native 16 KB Page Size Rejection Guide

Home
Blog
How to Fix the “16...

TL;DR

Google Play now enforces 16 KB memory page size alignment for all native libraries (.so files), affecting many React Native apps.
Apps with native modules or third-party SDKs are most at risk; pure JS/Kotlin apps are usually safe.
To fix: upgrade React Native, AGP (8.5.1+), and NDK (r28+), and add linker flags for 16 KB alignment.
Verify with tools like zipalign, llvm-objdump, and test on 16 KB devices/emulators before uploading.
Don’t delay — update now to avoid Google Play rejection and ensure your app is future-proof.

Introduction

If you’ve recently tried to publish your React Native app on Google Play Console only to be met with a rejection citing the dreaded “16 KB page size” error, you’re not alone. Over the past few months, Google has started enforcing stricter requirements on how native libraries are aligned in memory. This change directly impacts apps that include native code (.so files), even if those apps had been publishing smoothly in the past.

What this means is that React Native developers can no longer ignore low-level memory alignment rules — failing to comply now results in outright rejection on Google Play. The challenge is that this issue often comes from deep within native modules, third-party SDKs, or even React Native’s own core libraries, making it confusing for many developers to identify and resolve.

That’s why understanding how the 16 KB page size error works, how to detect problematic libraries, and how to reconfigure your build system properly has become crucial for every React Native project moving forward.

In this guide, I’ll break it all down step by step:

What the 16 KB page size error actually means and why it matters for Android 15+
How to check whether your React Native app is affected
How to update your project setup, Gradle, and NDK configurations to align with Google’s requirements
How to rebuild, test, and reupload your app without facing rejection again
Common pitfalls developers encounter with third-party libraries — and how to work around them

By the end, you’ll not only have a clear path to resolving the Play Console rejection, but also ensure your app is technically future-proof for newer Android versions and devices. And if you’d prefer expert help instead of navigating these technical details alone, you can always partner with a React Native app development company that’s already solving these compliance issues for startups and enterprises.

What Is the 16 KB Page Size Error?

Memory page sizes and native libraries

In operating systems, memory is divided into pages (fixed-size blocks). Until now, Android mostly used 4 KB pages (i.e. 4096 bytes).
On newer Android versions (Android 15 and above), and on some newer hardware, Google is shifting to 16 KB pages (16384 bytes) for performance and memory-safety reasons.
Native libraries (.so files) contain ELF segments with load sections. These segments must be aligned according to the device’s page size. If a library’s segments are aligned on 4 KB but run on a device expecting 16 KB alignment, the OS loader may reject or fail to load it.
Google now requires that all shared libraries in your app support 16 KB alignment when targeting or running on devices with 16 KB pages. Android Developers+1

Which apps are affected

If your app is pure Java / Kotlin / JS without any native (.so) libraries or SDKs, you are mostly safe.
But if your app, or any of its dependencies (SDKs, native modules, libraries) include compiled native code, you are at risk. You need to ensure every .so is properly aligned.
In fact, React Native core native libraries (libreactnative.so, libhermes.so, etc.) have been reported to have alignment issues on 32-bit architectures (armeabi-v7a, x86) in certain RN versions. GitHub
Also, community modules like react-native-screens have been flagged: their 32-bit .so files are aligned to 4 KB instead of 16 KB, producing warnings or failures. GitHub

Step-by-Step Guide: Resolve the “16 KB Page Size” Rejection in React Native Apps

Step 1: Check Whether Your App Is Affected

Before you rewrite or overhaul your project, confirm whether you really need to fix things.

Method A: APK / AAB Analyzer in Android Studio

Open Android Studio → Build → Analyze APK / Analyze Bundle
Examine the lib/ folder in all ABIs (armeabi-v7a, arm64-v8a, x86, x86_64).
If you see .so files, your app uses native code. For each .so, check the Alignment column—if it shows a warning or non-16 KB alignment, that .so is problematic.
Recent Android Studio (or Lint) may also highlight non-aligned .so files. Android Developers

Method B: Google Play Console / Bundle Explorer

Upload your .aab. In the Bundle Explorer, look for a “Memory page size compliance” section. It may show which libraries fail the check or a red alert.
This is the most direct way to see if Play considers your app non-compliant.

Method C: Command Line on Device / Emulator

Run:

adb shell getconf PAGE_SIZE

If the output is 16384, that device is using 16 KB pages. You should test with such devices.

You can also dump the ELF headers of each .so file to check the “LOAD” segment alignment:

llvm-objdump -p libYour.so | grep LOAD

Look for lines like:

LOAD off … align 2**14

2**14 = 16384 is what you want. Anything lower (e.g. 2**12 = 4096) is potentially bad. Android Developers

Step 2: Update / Upgrade Your React Native Project

Because the alignment issue often stems from how native libraries are compiled, you’ll need to ensure your React Native setup and dependencies support 16 KB.

Upgrade React Native & ecosystem

Move to the latest stable RN version (or at least v0.77+), since newer versions are more likely to include fixes or patches for 16 KB alignment.
Upgrade your JS / native dependencies (npm / yarn) accordingly — some modules might depend on older native libs.
Remove or replace libraries that include incompatible .so files that aren’t updated.

Audit which libraries include native code

Use Gradle’s dependency tooling to list what brings in .so files:

./gradlew app:dependencies --configuration releaseRuntimeClasspath

For each suspect .so, trace which module depends on it.
In one Medium blog, the author discovered libtensorflowlite_jni.so and libconceal.so coming from transitive dependencies, and fixed them by upgrading or removing those modules. Medium
For React Native specific issues: people have opened GitHub issues showing that RN core .so files for 32-bit aren’t aligned properly. GitHub

If a library is not maintained or doesn’t plan to support 16 KB, you may need to fork it or remove it.

Step 3: Configure Android Build / Native Build Settings

This is the core part of the fix: making your builds produce 16 KB-aligned libraries and bundling them properly.

Upgrade your Android tooling

Use Android Gradle Plugin (AGP) 8.5.1 or higher — this is required to support uncompressed native libs and align them properly. Android Developers
Use NDK r28 or newer, because from r28 onward, native libraries are compiled with 16 KB alignment by default. Android Developers

Enable flexible page sizes & linker flags

In your native build files (CMakeLists.txt or ndk-build), ensure you set:

-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON
Add a linker flag: -Wl,-z,max-page-size=16384

For example, in CMake:

target_link_options(<your-target> PRIVATE "-Wl,-z,max-page-size=16384")

For ndk-build / Android.mk:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

If you’re still using NDK < r28, this setting becomes essential because default alignment may still be 4 KB. Android Developers+1

Packaging / zip alignment settings

In android/app/build.gradle, add:

android {

    packagingOptions {

        jniLibs {

            useLegacyPackaging = false

        }

    }

}

This ensures that native .so files are not compressed in the APK / AAB, which is required for correct alignment. Android Developers

Also, ensure you aren’t re-zipping or re-compressing .so files in custom scripts after the build.

Handling prebuilt / third-party .so files

If you rely on prebuilt .so files (e.g. from SDKs), those too must be recompiled or aligned with 16 KB. If the SDK maintainers haven’t released a 16 KB-compliant version, your options include:

Asking SDK maintainers to publish a compliant version
Forking the SDK and rebuilding the native portions with correct flags
Excluding certain architectures (if you can safely drop 32-bit support) — but be careful with device coverage
Using fallback libraries or alternative SDKs

Step 4: Clean, Build, and Check Alignment

Once configuration is ready:

Clean everything

1. ./gradlew clean

Build release

2../gradlew bundleRelease

Verify alignment

Use zipalign to test the alignment:

zipalign -c -P 16 -v 4 path/to/app-release.aab

The -P 16 flag means “16 KB pages.” If it reports alignment problems, something is still off.
(Optional) Use the check_elf_alignment.sh script or llvm-objdump approach (as described in official Android docs) to check each .so’s LOAD segment alignment. Android Developers

If the build reports no warnings and zipalign passes, it’s a good sign your app is now aligned.

Step 5: Test in a 16 KB Environment

It’s not enough to build successfully — you must run the app on devices (emulator or physical) that use 16 KB pages, and verify nothing breaks.

Using emulator with 16-KB system image

Android Studio’s SDK Manager lets you download Android 15 / higher 16 KB page size system images. Android Developers+1
Create an emulator using that image.

In certain emulator / config.ini files, you may need to add:

kernel.parameters = androidboot.page_shift=14

(That sets page shift to 14 → 2^14 = 16384). Android Developers
Note: Some versions of Android Studio / emulator had bugs where AAB alignment checks weren’t consistent; updating to newer versions (e.g. 2025.1.3) has resolved such discrepancies for some users. Stack Overflow

On real devices

For devices that support 16 KB, run:

adb shell getconf PAGE_SIZE

It should return 16384.
Use the app in full: login, navigation, third-party SDK features, animations, etc. Ensure no native crashes or missing functionality.
Use logging (native, JNI, crash reporters) to capture any errors in library loading, missing symbols, or segmentation faults.

Step 6: Upload & Verify in Google Play Console

Once the build is aligned and tested:

Upload the .aab to Google Play Console.
In Bundle Explorer, check the “Memory page size compliance” section — it should show ✅ (compliant).
If there are still warnings:
- Review what specific .so files or ABIs are flagged.
- Use the dependency / module map to trace them.
- Possibly exclude problematic architectures temporarily (not always ideal).
- Contact SDK authors / maintainers if a library remains noncompliant.

Some developers reported that Android Studio version mismatches caused discrepancies—APK analysis might show no error, but the AAB did. Updating Android Studio solved that. Stack Overflow

Common Pitfalls & Troubleshooting

Problem	Potential Cause	Remedy
Play Console still rejects	Some .so files are still misaligned (especially 32-bit)	Check each library via objdump or alignment script
Third-party SDK not updated	SDK maintainers haven’t shipped 16 KB build	Fork and rebuild or replace SDK
Android Studio / AAB tool bug	Analyzer mismatches	Update Android Studio / Gradle / bundletool to latest
Relying on hard-coded PAGE_SIZE = 4096	Code assumes 4 KB page size	Use sysconf(_SC_PAGESIZE) or dynamic query instead
Using mmap() or pointer arithmetic tied to page size	Buggy memory logic	Adjust to support variable page size
Dropping 32-bit architectures	Reduces device coverage	Weigh tradeoffs carefully, test fallback

Also, be aware:

The increase in binary size is small and acceptable; Android’s package manager handles it. Android Developers
Some apps might be allowed to run in a “16 KB backcompat mode” if they have mixed alignment — but don’t rely on this for long term stability. Android Developers

Conclusion

The “16 KB page size” rejection may seem like a sudden, frustrating hurdle, but it’s ultimately a necessary step as Android evolves toward greater performance and memory safety. The good news is that with the right approach, this problem is entirely fixable.

By carefully following the process — checking whether your app is affected, upgrading React Native and its dependencies, configuring your build system and NDK for 16 KB alignment, rebuilding and validating your binaries, testing on actual 16 KB devices, and finally re-uploading to Play Console — you’ll be in a strong position to pass compliance checks and future-proof your app.

⚡ Pro tip: Don’t wait until the official enforcement deadline in November 2025. Begin making these updates now, so you’ll have enough time to address unexpected issues with third-party libraries or SDKs.

And if you’d rather not deal with the technical deep-dive yourself, consider working with experienced React Native developers who can handle the alignment, build configuration, and compliance process for you — letting you focus on growing your app instead of troubleshooting rejections.

👉 We’re offering a free 30-minute consultation to help you understand your app’s current status and the exact steps needed to get it Play Store–ready.

React Native