Google Play is enforcing support for 16KB memory page size on newer Android versions. While most apps are unaffected, Android apps that use native code may fail builds or have updates rejected if they are not updated in time.
From November 1st, 2025, all new Android apps and all updates to existing apps submitted to Google Play must support 16KB memory page size. Apps that do not meet this requirement may be rejected during submission, even if they previously worked. This mainly affects apps that include native code.
What Is Memory Page Size and Why Android Is Changing It
Memory page size is the basic unit Android uses to work with memory. For a long time, this size has effectively been 4KB, and most Android apps, especially those with native code — were built around that assumption. Developers rarely think about it because, until now, it mostly “just worked.”
That’s changing as Android starts supporting 16KB memory pages on newer devices. This shift isn’t cosmetic, it’s driven by newer hardware, larger RAM sizes, and the need for more efficient memory handling at the system level. The important part for app owners is that native binaries built with old assumptions may no longer behave the same way unless they’re updated.
Which Apps Are Affected by the 16KB Page Size Change
This 16KB page size change does not affect every Android app. The risk is mainly tied to native code, because many native libraries were originally built with a 4KB page size assumption that may not hold on newer devices.
Usually not affected
Apps built purely with Java or Kotlin
Apps that do not use the NDK
Apps that do not bundle any native SDKs
Needs to be checked
Apps using the NDK or C and C++ code
Apps that include .so libraries
Apps using third party SDKs with native code
Frameworks with native layers such as React Native, Flutter, or game engines
This structure allows teams to quickly identify whether their app is likely affected without digging into low level system details. Being in the “needs to be checked” group does not mean the app is broken, but it does mean native dependencies should be reviewed before the next update.
What App Owners Should Do Next
For most teams, this is not a large migration project. It is a short verification and cleanup process that helps ensure future Android updates are not blocked by native compatibility issues.
Check whether your app includes native code
Start by confirming whether the app contains any native components. This includes NDK code written by your team, bundled .so libraries, and native binaries that come from third-party SDKs or frameworks. Even apps written mostly in Java or Kotlin can still include native code indirectly.
Review native dependencies and ownership
Once native code is identified, list all native artifacts used by the app, including shared libraries and SDKs. At this stage, dependencies are classified into two groups: components the team controls and components provided by third parties. This distinction determines whether an issue can be fixed by rebuilding or requires a vendor update or replacement.
Update or rebuild where needed
Each native dependency is checked against Android’s 16KB compatibility requirements. SDKs and frameworks are updated to versions that support the new page size where available. For self-built native code, C or C++ libraries are rebuilt using appropriate NDK configurations. If a third-party dependency does not yet support 16KB, it is flagged early so alternatives or mitigation options can be considered.
Test and prepare for release
After changes are applied, the app is tested in an environment that reflects 16KB page size behavior. Key user flows are verified to ensure no regressions appear at runtime. Once testing is complete, the app is ready for future updates that comply with Google Play requirements.
Final Notes
The 16KB page size requirement is a platform-level change that mainly impacts apps with native dependencies. The challenge is often not the fix itself, but identifying hidden native risks early enough to avoid blocked updates.
To support teams at different stages, we typically help in three focused ways:
Impact check to confirm whether an app is affected
Native dependency review to identify upgrade or rebuild risks
Targeted fixes and validation to ensure future updates can be published smoothly
If you’re unsure whether your app needs changes, feel free to get in touch for an initial check.