Android 16 KB Deadline: A Release Checklist for February 2027

Android developers should now plan around the current official Google Play compatibility wording: apps targeting Android 15, API level 35, and higher must support 16 KB memory pages on 64-bit devices. Starting 1 February 2027, incompatible app updates cannot be released, according to Android’s maintained guide.

The useful task is not simply changing a Gradle version. It is proving that the exact artifact you intend to ship works on a genuine 16 KB environment, including native code hidden inside third-party SDKs. The official Android compatibility guide, updated on 16 September 2026, is the policy and technical reference for this checklist.

Start with the release APK, not assumptions

A team can write its application entirely in Kotlin and still ship native libraries through a camera, database, authentication or other SDK. Ask what is inside the built package, not only which language appears in the main repository.

In Android Studio, use Build, then Analyze APK, and inspect the lib folder for shared-object files ending in .so. The APK Analyzer’s alignment column can identify problematic libraries. Record each library’s name, architecture, dependency owner and version.

If the complete application, including all libraries and SDKs, uses only Java or Kotlin, Android says it already supports 16 KB devices. That removes the native rebuild problem, not the need for regression testing.

Separate three different compatibility checks

• ELF alignment: the native library itself must have correctly aligned load segments.
• ZIP alignment: uncompressed shared libraries must be positioned correctly inside the delivered APK.
• Runtime assumptions: native code must not incorrectly assume every memory page is 4 KB.

Passing one check does not prove the other two. An application may have a properly packaged library that still crashes when a rarely used feature performs memory mapping.

Android recommends AGP 8.5.1 or higher and NDK r28 or higher, together with 16 KB-compatible prebuilt dependencies. These tool versions provide the default alignment path, but upgrading your own NDK does not rebuild a vendor’s precompiled library. Obtain a compatible dependency release or escalate to its maintainer.

A worked release investigation

Imagine a fictional field-service app that launches correctly but crashes when opening its document scanner. Its own Kotlin code is not sufficient evidence of compatibility. The investigation should identify which SDK supplies the scanner’s native libraries, update that dependency in a branch, rebuild, and repeat both artifact checks and the scanner workflow.

Keep the old and new library inventories next to the corresponding build identifiers. If several dependencies ship similar filenames, use the dependency graph to establish ownership rather than replacing files manually inside the package.

For an app bundle, inspect its requested packaging alignment:

bundletool dump config --bundle=app-release.aab | grep alignment

The expected configuration is PAGE_ALIGNMENT_16K. PAGE_ALIGNMENT_4K indicates that the bundle requests 4 KB ZIP alignment. Also inspect the generated APKs you will actually test; a bundle configuration result is not a complete runtime certification.

Prove the device environment before testing

Create an emulator using an available 16 KB system image, or use a supported physical device configured for that mode. Confirm the environment instead of assuming that an Android version alone determines its page size.

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

The first command should return 16384. The second checks the APK’s ZIP alignment. Use the SDK tools and ELF checks described in Android’s guide for native binaries; do not treat zipalign as a substitute for them.

Test cold launch, login, database reads and writes, camera capture, downloads, background work and any SDK-powered feature. Repeat important journeys on a 4 KB environment to catch regressions introduced by dependency changes.

Do not accept compatibility mode as your exit criterion

Android documents a backcompat mode that allows some applications to work, but recommends proper alignment for reliability. A launch that succeeds only through compatibility behaviour is not the same as a verified native-compatible release.

For teams managing real work phones, the shared-phone permission hygiene guide addresses a separate operational check: permissions and data access still need review after compatibility testing.

Close the release ticket only when the artifact identifier, native dependency inventory, alignment results, confirmed device page size and feature-test outcomes are recorded. Treat the February deadline as the outer policy boundary, not the date to start discovering an unmaintained SDK.

Handle an SDK blocker as a release decision

A native dependency with no compatible release deserves a named decision, not a silent workaround. Record the affected feature, its importance to users, the vendor's response and the last tested build. Compare three options: adopting a maintained compatible version, replacing the SDK, or postponing the affected release while the team develops a supported path. Removing a feature also requires checking how existing users' data will behave.

Ask the dependency owner for evidence about the delivered binaries rather than accepting a statement about source-code support. Once a replacement arrives, repeat the packaged-artifact and runtime checks; the promise alone does not close the ticket.

Keep a small regression matrix showing the device environment, build identifier, feature, result and evidence location. Include an ordinary 4 KB run beside the 16 KB run. When a failure returns later, this record helps establish whether a new dependency or packaging change invalidated the earlier result.