First determine whether native code is present
Inspect the release APK set for lib/<abi>/ entries. Include native libraries introduced by game engines, database SDKs, image processors and advertising dependencies. Review the AAB-generated APKs when device-specific delivery is involved.
Do not assume a recent target API or a successful debug install proves page-size support. Android's 16 KB guidance covers both build-tool requirements and runtime assumptions.
At this guide's 29 September 2026 review, Android's official compatibility guide states that Google Play apps targeting Android 15 (API 35) and higher must support 16 KB pages on 64-bit devices, and identifies 1 February 2027 as the date after which unsupported updates cannot be released. Confirm the current applicability and submission requirements in the official Android guide before planning a release. A policy deadline and a successful technical compatibility test are separate checks.
Separate ELF alignment from ZIP alignment
Native libraries have internal ELF segment alignment requirements. The APK container also has alignment requirements for directly loaded uncompressed native libraries. Passing one check does not automatically satisfy the other.
A packaging check for the relevant APK can include:
zipalign -c -P 16 -v 4 app-release.apk
This checks archive alignment; it does not replace inspection of ELF load segments or execution on a 16 KB environment. Use the Android-documented ELF inspection tools and checks appropriate to your platform. zipalign reference.
Rebuild rather than patching the final package
Update the NDK/build pipeline and native dependencies according to the official compatibility guidance. If a third-party .so is incompatible, obtain a supported vendor build or replace the dependency. Renaming the library, changing a Gradle number or recompressing the APK does not repair compiled ELF assumptions.
Keep the original and rebuilt artifacts so you can demonstrate which native files changed. Verify signing after packaging with the normal release pipeline.
Test runtime assumptions too
Native code can incorrectly assume a fixed page size in allocation, memory mapping or alignment logic. A binary that appears well packaged may still fail when those code paths execute. Exercise startup, media processing, database access and any feature using the affected library on a documented 16 KB test environment.
Capture the exact device or emulator configuration and the failing native stack when a problem occurs. A vague “works on Android 16” note is insufficient because OS version alone does not identify page size.
Record evidence for each library
Maintain a table of library name, origin, version, ELF check, packaging check and runtime test status. Mark untested dependencies explicitly. APKLint can help identify packaged native components, but its general APK report is not a full 16 KB certification. Recheck current Google Play applicability and deadlines in the official guide before a production submission.
Track a vendor library through the rebuild
Suppose an image feature depends on a vendor library that fails the documented ELF alignment check. Record the library path, ABI and dependency version. Update to a vendor build that supports the required environment, rebuild the same release variant and confirm that the packaged library bytes actually changed. A dependency declaration edited in one module is insufficient if another dependency still supplies the old binary.
Keep separate results for the library's internal layout and its placement in the APK. For example, a reported load-segment alignment of 2**14 corresponds to 16,384 bytes; it is not a statement that the application uses only 16 KB of memory. A successful archive alignment check cannot compensate for an incompatible native binary. Follow the current Android page-size guide for the complete checks supported by your toolchain.
Exercise the operation that loads the library
Use a documented 16 KB device or emulator environment and confirm its page-size configuration. Open the feature that invokes the replaced library, process a small synthetic image, then repeat with an input that takes a different code path, such as a large image or an unsupported format. Record normal completion and the expected error behavior. Merely opening a home screen that never loads the library provides little evidence about compatibility.
Retain the corresponding symbols and native crash output if the candidate fails. Investigate memory mapping, alignment arithmetic and page-size assumptions in the affected component rather than treating every failure as a ZIP packaging problem. A dependency owner may need the exact native binary and failing operation to reproduce it.
Keep the technical compatibility result separate from the store-submission check. The release record should identify the environment and operations tested, while the submission checklist should link to the current applicable Google Play requirement. Policy dates can change; a copied deadline must not replace checking the official guidance at release time.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
