Test Android 16KB Page-Size Compatibility for Local AI

Direct answer

A 16 KB page-size check for an Android local-AI app must cover the final package and every native dependency, not only Kotlin source or the top-level runtime name. Android 15 and later can run on devices configured with 16 KB memory pages. If the application or any dependency contains native code, Android guidance says to inspect the native libraries, their ELF segment alignment, and package alignment, then test behavior in a 16 KB environment. A model framework may package shared objects even when the app team wrote no C or C++ itself. Start with the exact release-like APK or the device-specific APKs generated from the release bundle. APK Analyzer can show whether a `lib` directory exists, which ABIs are present, and alignment warnings for the packaged `.so` files. An AAB is not the same object as the final device-specific APK; inspect the artifact users would install or the APKs generated for the installation route under test. Record hashes and build identity for the package and libraries so a result can be reproduced. Check ELF LOAD-segment alignment and APK ZIP alignment separately; neither result substitutes for the other. Also inspect each native library for a GNU_RELRO segment. If one exists, calculate `(VirtAddr + MemSiz) % 0x4000`; a zero remainder is the documented 16 KB boundary check. Android notes that NDK r27 and lower builds without the relevant flags can produce a non-aligned RELRO segment, but do not infer the state of a particular dependency from its version label alone. Use the official APK Analyzer, ELF, RELRO, and `zipalign` checks on the exact artifact instead of inferring support from AGP settings, an emulator that uses 4 KB pages, or an NDK version string. Then run the artifact in an actual 16 KB configuration supported by Android’s documented test choices, such as an appropriate emulator image or a device booted into the documented mode. Verify the environment itself before running the app; the official guide uses `getconf PAGE_SIZE` and expects the environment to report 16384 for a 16 KB test. Keep that value as test-environment evidence, not as a device compatibility claim. Exercise the local-AI user path: cold install, find and verify the model file, initialize the runtime, run a fixed safe fixture, request cancellation through the resolved runtime API, wait for that request’s terminal callback, and confirm no operation remains in flight. Close the runtime only when the resolved API supports it and the current owner is authorized to do so; then create or reopen a session as appropriate and run the fixture again. A cancellation request or a UI state change alone does not prove native work has stopped. Record install failure, linker error, model parse error, backend initialization, task output, fallback, memory failure and recovery separately. Some applications can enter a back-compat mode when libraries are aligned for 4 KB; that is not equivalent to a validated 16 KB build, so test with compatibility mode disabled where the official guide permits and document the mode. Do not publish model speed, memory, battery, broad phone support, or “NPU compatible” conclusions from this test. Cove has no complete raw real-device benchmark dataset; this page therefore describes how to test page-size alignment and user-task behavior, not a pass list for Cove devices. Store a test bundle: application version and commit, dependency/runtime revision, exact APK or AAB and generated splits, ABI, all native library identities, ELF/RELRO/ZIP alignment reports, OS build and page-size evidence, configuration state, artifact revision, fixture, outcome and failure logs. If any dependency is opaque or absent from the inspection, report the matrix as incomplete rather than assuming it is safe. Repeat after updating the runtime, native library, build tools, packaging settings, model loader or release artifact. A valid statement is limited to the inspected package and environment. The method does not guarantee that a different artifact, ABI, manufacturer build, runtime backend or task will behave identically. Workflow: inventory the final package, inspect every native binary, check LOAD segments, GNU_RELRO when present, and ZIP alignment, install into the selected 16 KB environment, verify the environment, run the representative inference lifecycle, preserve every failure and recovery result, and report only the tested scope. Passing alignment checks does not prove runtime/task compatibility. This is a compatibility test method, not an observed Cove benchmark or certification.

A local model loads on a 4 KB emulator but the release must be checked at 16 KB

A developer’s local-AI app builds successfully and runs one test in a default emulator. The release bundle includes native runtime dependencies from a third-party library, and the team has not inspected every device-specific APK or executed the model workflow under a 16 KB page-size environment.

Decision

Freeze the release package and native-library inventory, run the official alignment checks, then exercise install, load, inference, cancellation through native terminal state, owner-authorized close, and recovery in a documented 16 KB test environment.

Expected outcome

The team can report exactly which package and task were tested, or keep the compatibility conclusion open if any library, split or runtime path remains unverified.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Native-library build identities
• Page-size and device record
• Install, load, task, and failure outcomes

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Freeze the package under test. Record the app commit, release variant, runtime dependency, model artifact identity, bundle, generated APK splits and supported ABI list. Do not substitute a debug APK for the release artifact.
2. Inventory native code in every output. Use APK Analyzer on the APKs actually produced for the selected delivery route; identify all `.so` files, their ABI directories, library names and alignment warnings, including transitive runtime dependencies.
3. Check LOAD, RELRO, and ZIP alignment. For each native library, run the documented ELF LOAD-segment inspection and final-APK `zipalign` check. Use `llvm-readelf -Wl` to determine whether GNU_RELRO is present; if present, verify `(VirtAddr + MemSiz) % 0x4000 == 0`. Save the outputs and map every result to its artifact; a pass at any one layer does not prove the others.
4. Verify the 16 KB test environment. Use an Android-supported emulator or device configuration described by the platform guide. Confirm the environment reports a 16 KB page size and record whether compatibility mode is enabled.
5. Exercise the complete inference lifecycle. Install the exact package, open the expected artifact, and run one fixed non-sensitive task. Request cancellation through the resolved runtime API, wait for that request’s terminal callback, and confirm no work remains in flight. Close only if the resolved API and resource owner permit it; then run the task again in a fresh or reopened session. Keep load, linker, parser, task and recovery failures distinct.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The inspected package identity includes the exact release artifact and every device-specific split and native library relevant to the tested ABI.
• Each native library has separate recorded ELF LOAD and, when present, GNU_RELRO checks, and the final APK has a separate ZIP-alignment result.
• The test record proves the environment page size and states compatibility-mode status before interpreting app behavior.
• Published wording is limited to the tested build, runtime, ABI, environment and local-AI task; no broad compatibility or performance claim is inferred.

Decision table

Failure patterns to prevent

• Checking Kotlin code only
• Calling packaging success runtime proof

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove benchmark method
• Android Developers — Support 16 KB page sizes
• Android Studio — Analyze builds with APK Analyzer
• Android NDK — ABI management

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions