Google Play requires every app targeting Android 15 (API level 35) or higher to support 16 KB memory page sizes on 64-bit devices, and from 1 February 2027 updates that do not support it can no longer be released. Apps written only in Java or Kotlin already comply. Apps that contain native code, directly through C or C++ and the NDK, or indirectly through a third-party SDK, a game engine or an app builder that ships native libraries, need to be rebuilt with 16 KB alignment. The fix is usually a tooling upgrade, Android Gradle Plugin 8.5.1 or later and NDK r28 or later, plus updated versions of any SDK that bundles shared libraries.
Short answer
Most Android devices historically used 4 KB memory pages. Newer devices can run with 16 KB pages, which Android's documentation describes as improving performance, and native libraries built with 4 KB assumptions may fail to load or crash on them. Google Play therefore requires apps targeting API 35 and above to support 16 KB pages, with the release block for non-compliant updates starting on 1 February 2027, according to Android's page size guide. Check whether your app ships any .so files. If it does not, you are done apart from testing. If it does, upgrade your build tools, update or recompile every native dependency, and test on a 16 KB emulator or device.
Who is affected
The requirement only bites apps with native code, but native code hides in more places than most teams expect.
| Where native code comes from | Typical examples | What to do |
|---|---|---|
| Your own C or C++ code | Audio, image or video processing, crypto, game logic | Rebuild with NDK r28+ or add the 16 KB linker flags |
| Third-party SDKs with .so files | Analytics, ads, maps, video players, face or document scanners | Update to a version the vendor says supports 16 KB |
| Cross-platform frameworks | React Native, Flutter, Unity, some game engines | Update the framework to a 16 KB-compatible release |
| App builders | Platforms that generate apps with on-device native libraries | Ask the builder whether its output is 16 KB aligned |
| Prebuilt libraries you vendored | Old .so files copied into the project years ago | Recompile from source or replace |
Apps that contain only Java and Kotlin code, including their libraries and SDKs, already support 16 KB devices, according to the same guide. The page still recommends testing them, because a single dependency with a native component is enough to change the answer.
How to check your app in ten minutes
You can confirm the situation before touching any code.
Look for native libraries
In Android Studio, open Build > Analyze APK on a release build and look in the lib folder. If there are no .so files, the app has no native code to fix. If there are, note which libraries they belong to; the file names usually identify the SDK.
Check alignment
Android's guide documents several ways to check alignment on an existing build:
- The zipalign tool with the 16 KB option should finish with a successful verification message.
- llvm-objdump on each shared library should show LOAD segments aligned to 2**14 or higher.
- Google provides a check_elf_alignment.sh script that marks each arm64-v8a library as ALIGNED or UNALIGNED.
- For an app bundle, bundletool can confirm that the bundle declares 16 KB page alignment.
Android Studio and Lint also warn about unaligned libraries in recent versions, which makes the problem visible during normal development.
Check Play Console
Play Console reports 16 KB compliance for uploaded bundles. If you have already uploaded a recent build, its status there is the quickest answer to whether Google considers it compliant.
How to fix it
For most teams the fix is a version bump rather than code changes.
Upgrade the build tools
The guide's shortcut is that an app built with Android Gradle Plugin 8.5.1 or higher and NDK r28 or higher, using 16 KB-compatible prebuilt dependencies, is compatible by default. AGP 8.5.1 packages uncompressed shared libraries with 16 KB alignment. NDK r28 compiles 16 KB-aligned libraries by default.
If you cannot upgrade yet, there are fallbacks. On older NDK versions, add the max-page-size and common-page-size linker flags set to 16384. On older AGP versions, packaging native libraries compressed avoids the alignment problem at the cost of a larger install. The guide documents both, along with a warning worth repeating: AGP 8.3 to 8.5 align correctly in local builds, but bundletool does not zipalign APKs, so an app can install fine on your device and fail when Play generates APKs from the bundle.
Update every SDK with native code
This is usually the slow part. Each SDK vendor ships its own compatible version, and some older SDKs will never be updated. Make a list of every .so file, map each to its SDK, and check each vendor's release notes for 16 KB support. An abandoned SDK with native code is now a compliance problem as well as a maintenance one.
Fix code that assumes 4 KB pages
If you maintain native code, search for hardcoded page sizes. Android's guide advises against assuming 4096 or using the PAGE_SIZE constant, which is undefined in 16 KB mode on recent NDK versions, and recommends querying the page size at runtime with getpagesize or sysconf. Review mmap calls and any custom allocators that depend on page-aligned arguments.
How to test on a 16 KB device
Testing is where alignment problems that slipped past the build show up as crashes.
| Environment | How to get it | Notes |
|---|---|---|
| Emulator | Install the Android 15+ system image labelled 16 KB page size in SDK Manager | Fastest option for most teams |
| Pixel devices | Enable "Boot with 16KB page size" in developer options | Supported on Pixel 8 and 9 series and Pixel 9a on recent Android versions |
| Cuttlefish or remote labs | Cloud-based virtual devices or vendor device labs | Useful for CI and wider coverage |
After booting, running getconf PAGE_SIZE through adb should return 16384. Then exercise every feature that touches native code: camera and media, maps, payments SDKs, anything that loads a .so on demand. A library that fails to load on 16 KB often only does so when the feature that uses it is first opened.
Android also has a backcompat mode that can let some 4 KB-aligned apps run on 16 KB devices. The guide is clear that it is a stopgap: apps should still be 16 KB aligned for reliability and stability, and backcompat does not satisfy Play's requirement.
Why this matters for security as well as compliance
The 16 KB change is mainly about compatibility and performance, but the audit it forces has security value. Making a list of every native library in your app is the same exercise as building a software bill of materials for your native dependencies. Teams doing it often find SDKs nobody remembers adding, outdated versions with known issues, or libraries pulled in by a dependency of a dependency.
The OWASP Mobile Application Security Verification Standard includes code quality and supply-chain hygiene among its control groups, and outdated third-party components are a recurring source of mobile vulnerabilities. Native code deserves particular attention because memory-safety bugs in C and C++ libraries can be serious, and because native libraries are harder to inspect than Java or Kotlin code.
A scanner like PTKD.com analyses the built APK or AAB and reports risky third-party components, exposed secrets and insecure configuration by severity, mapped to OWASP MASVS. It does not realign your libraries or fix the 16 KB build, which happens in your toolchain, but it helps with the inventory question the migration raises: what is actually inside the binary you ship.
What the native inventory should record
The list you build for the 16 KB migration is worth keeping. For each .so file, record the library name, the SDK or framework it came from, the version, who maintains it, whether that version is 16 KB aligned, and the last time it was updated. Add the features in your app that load it, so testing can target them.
Kept up to date, that list answers three recurring questions quickly: which SDKs need updating when a platform requirement changes, which components are affected when a vulnerability is announced in a native library, and which vendors have gone quiet. The 16 KB deadline is the reason to build it now; the next requirement will be the reason you are glad it exists.
Planning the migration
A realistic plan for a team with native dependencies:
- This week: analyse the current release build, list every .so file and its source, and check Play Console's compliance status.
- Next sprint: upgrade AGP and the NDK, update the framework if you use React Native, Flutter or a game engine, and update each SDK to its 16 KB-compatible version.
- Same sprint: run the alignment checks on the new build and test on a 16 KB emulator, covering every feature that loads native code.
- Before release: confirm Play Console shows the bundle as compliant, and keep the alignment check in CI so a new dependency cannot quietly reintroduce the problem.
- Replace what cannot be updated: any SDK whose vendor will not ship a compatible version needs a replacement well before February 2027.
Teams using cross-platform frameworks
React Native, Flutter and engine-based apps inherit native libraries from the framework itself as well as from plugins. Upgrading the framework solves the core libraries; each native plugin still needs checking individually. Plugins maintained by a single volunteer are the most likely to lag, so start there.
Teams using app builders
If an app builder generated your Android app, you may not control the build at all. Ask the builder directly whether its current output is 16 KB aligned, and check the generated APK yourself with the analyser. If it is not compliant, you need a clear date from the builder, because the February 2027 deadline applies to your listing, not to theirs.
Common mistakes
Testing only in debug. Debug and release builds can package native libraries differently. Check the release bundle, ideally the APKs Play generates from it.
Trusting local installs. An app installed directly from Android Studio can work on a 16 KB device while the Play-generated APK fails, for the zipalign reason above.
Forgetting on-demand libraries. Some SDKs load native code only when a feature is used. A smoke test that opens the app's home screen proves very little.
Leaving it to the deadline. Vendor updates take time, and the release block applies to updates. An urgent security fix in February 2027 should not be stuck behind a library alignment problem.
Assuming arm64 is the only concern. The requirement targets 64-bit devices, but if you ship x86_64 libraries for emulators or Chromebooks, check those too, since the same alignment rules apply to every 64-bit ABI you package.
What to take away
- Apps targeting Android 15 (API 35) or higher must support 16 KB page sizes on 64-bit devices, and from 1 February 2027 Play blocks updates that do not.
- Only apps with native code need changes, but native code often arrives through SDKs, frameworks and app builders rather than your own C++.
- AGP 8.5.1+ and NDK r28+ with compatible dependencies are 16 KB compatible by default; older toolchains need linker flags or compressed packaging.
- Test release builds on a 16 KB emulator or Pixel device, covering every feature that loads native code, and keep the alignment check in CI.
- Use the migration to inventory what is inside your binary, with a scan from a tool such as PTKD.com alongside the alignment checks.
