# Android 16 KB pages: check native libraries before the deadline

> Check native libraries, alignment, and 16 KB testing before Google Play’s February 2027 Android update deadline.
> By Dave · 2026-10-11
> Source: https://otf-kit.dev/blog/android-16kb-page-size-feb-2027

Google Play's 16 KB page-size requirement has a firm date: starting February 1, 2027, updates to apps targeting Android 15 (API level 35) or higher must support 16 KB memory pages on 64-bit devices. If you ship an Android app through Google Play, use the time before that cutoff to find out whether its native libraries are compatible, update anything that is not, and test the actual artifact you plan to release.

This is a dependency check as much as a code check. Android says an app may include native code directly, through third-party libraries or SDKs, or through a third-party app builder. A JavaScript interface does not tell you what native code is inside the built package. Inspect the artifact rather than guessing from the source language or framework.

## Start with the app you actually ship

A useful first question is not “Did we write C++?” It is “Does the package we submit contain native shared libraries?” You may have added a library yourself, inherited one through another package, or received it from a service that prepares the app. Each can put native code in the delivered build.

Android’s APK Analyzer can answer that first question. Open the APK in Android Studio and inspect the lib folder. Shared-object files ending in .so indicate native code is present. If there is no lib folder or no shared-object files, Android’s guide says the app does not use native code. If you do find libraries, use the analyzer’s Alignment column and Android Studio lint to identify alignment warnings. Treat this as an inventory, not a pass: a clean scan of one build does not prove that another build, flavor, or release artifact contains the same dependencies.

![Dex checks the app package and native-library components against 16 KB page tiles.](https://cdn.otf-kit.dev/blog/android-16kb-page-size-feb-2027/inbody-native-library-20261011-jordan.png)

Make the inventory repeatable. Keep a copy of the release APK or app bundle you inspected, note the build variant and dependency versions, and identify which team or provider owns each library that needs an update. That makes it possible to compare the next release candidate with the one you tested. It also avoids relying on a source-tree search that can miss prebuilt binaries shipped inside a dependency.

## Separate the two alignment checks

A common source of confusion is that “16 KB alignment” can refer to two different things. The native library’s ELF load segments need suitable alignment so the operating system can load and run them on a 16 KB device. The uncompressed shared libraries inside an APK also need suitable ZIP alignment so the packaged artifact installs correctly. Checking only one layer can leave the other broken.

For libraries, Android documents command-line checks for ELF segments and a zipalign check for the APK. Android Studio’s APK Analyzer and lint can point out many problems earlier. If a tool reports an unaligned library, update or rebuild that library, package it again, and repeat the checks on the resulting artifact. A successful rebuild does not automatically repair a prebuilt dependency that still contains incompatible machine code.

## Update the packaging and native build

Android recommends Android Gradle Plugin version 8.5.1 or later and uncompressed shared libraries for the packaging path. There is an important version detail: with AGP 8.3 through 8.5, alignment may appear correct in an intermediate APK, while bundletool does not zip-align APKs from the bundle by default. A build that seems fine locally can therefore still produce an install problem from an app bundle. Check the generated artifact rather than inferring its final behavior from a local intermediate.

If you cannot move to AGP 8.5.1 or later, Android documents compressed shared libraries as an alternative packaging approach. That can increase the installed app size because libraries are extracted and copied to disk, and the extra disk use can make installation fail on a device with little free space. Treat it as a tradeoff to evaluate and test, not a permanent substitute for upgrading the build tools when that is practical.

The native compiler matters too. Android NDK r28 and later produce 16 KB-aligned shared libraries by default. For NDK r27 and earlier, Android documents linker flags that set both the maximum and common page sizes to 16384. Libraries built elsewhere need the same attention: if your app uses prebuilt shared libraries, those binaries must also be rebuilt for 16 KB alignment and re-imported. Ask the library provider for a compatible build when you do not own the source.

If you maintain native code, search for assumptions that a memory page is always 4096 bytes. Android warns about hard-coded PAGE_SIZE assumptions and page-aligned arguments passed to mmap. Use the runtime page-size APIs where page size matters, then test the affected code. Custom allocators or memory pools deserve a focused review because logic tuned to 4 KB pages can retain memory or behave differently when the system page is larger. These changes apply only where such code exists; do not add allocator work to a project that does not use a custom allocator.

## Test a 16 KB build on a 16 KB system

The point of the work is not just to silence a static warning. Verify the release candidate in an environment that uses 16 KB pages, then exercise the app’s important flows. Android documents Android 15 emulator images configured for 16 KB pages, as well as other testing options. Confirm that the test device is really using the larger page size before interpreting a successful launch as proof.

~~~bash
adb shell getconf PAGE_SIZE
zipalign -c -P 16 -v 4 app-release.apk
~~~

The first command should return 16384 in a 16 KB environment. The second checks ZIP alignment for the APK. Run the alignment check on the artifact you intend to distribute, and keep its output with the release notes or build record. Then test startup, navigation, media or camera use, background work, and any other path that exercises native dependencies in your app. A successful install alone may not expose assumptions that fail later at runtime.

![Byte and Luna review app screens on a phone and laptop during a release test.](https://cdn.otf-kit.dev/blog/android-16kb-page-size-feb-2027/inbody-emulator-check-20261011-jordan.png)

If the app passes but the check fails in a later build, compare the native-library inventory and build configuration before changing application logic. If it fails only on a 16 KB system, use the failure to identify which library or page-size assumption needs attention. Keep the reproduction and the exact artifact version together so a provider or teammate can investigate the same problem.

## Plan the work before the cutoff

A practical sequence is:

1. Select the release APK or bundle and identify its native libraries.
2. Check their ELF alignment and the package’s ZIP alignment.
3. Update the build tools and rebuild libraries you own.
4. Request compatible versions for prebuilt libraries you do not own.
5. Test the exact release candidate in a 16 KB environment and record the result.

For an app with many dependencies, start with the artifact inventory now. This gives external library owners time to prepare compatible builds and gives your team time to test more than a last-minute hotfix. If the app contains only Java or Kotlin code and its libraries are also Java or Kotlin, Android says it already supports 16 KB devices; still run a test to catch unexpected behavior.

Keep this requirement separate from other Play deadlines. The [Google Play API 36 deadline guide](/blog/google-play-target-api-deadline-2026) covers the target API schedule. Supporting 16 KB pages is its own compatibility check: one does not replace the other.

## What to keep in your release record

Record the artifact filename or build identifier, whether native libraries were present, the libraries that needed updates, the build-tool versions used, the alignment-check results, and the 16 KB test environment. That record makes the next release easier to compare and gives you evidence if a library update changes the result.

Avoid a broad claim that an app is “16 KB ready” based only on its source code or on one device launch. Tie the statement to a specific release artifact and to the checks you actually ran. If a dependency has not been verified, keep it on the list rather than assuming that a successful app build proves its compatibility.

The February 1, 2027 cutoff applies to updates targeting Android 15 and higher on 64-bit Google Play devices. Start by inspecting the package, follow the native libraries through build and packaging, and test the final artifact under 16 KB pages. That gives you a concrete list of remaining work before the update restriction takes effect.

## Sources

- [Support 16 KB page sizes](https://developer.android.com/guide/practices/page-sizes) — Android Developers.