Welcome to Haposoft Blog

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.