Android App Bundle Native-Library Split Test

Direct answer

An Android App Bundle is a publishing artifact, not the package installed directly on a device. Android’s bundletool documentation explains that the bundle is converted into APKs for device configurations, including ABI-specific configuration APKs, and that bundletool can recreate and install a device-targeted APK set for local testing. Therefore, checking a universal debug APK or the source tree alone does not prove that a device-specific installation contains the native runtime libraries required by the application. Test the generated and installed split set for the exact device configuration. Start from a release-like signed bundle and record build variant, application version, declared ABIs, native libraries expected from direct dependencies, and any optional runtime library configuration. Generate an APK set for a connected device or a saved device specification; inspect the archive and installed package contents rather than assuming the output from another device is representative. The ABI in the device specification must match the installed native code. A missing library, wrong ABI, unresolved dependency, or failed load may surface as a native linking exception before model inference begins. The test needs multiple boundaries: bundle contents, generated APK-set contents, the actual installed split inventory, native library load, runtime initialization, artifact load, and a representative task. Record which stage succeeds and the first failure. A successful install is not proof that optional native libraries were packaged, and a library present in an APK is not proof that the runtime can load it. Conversely, a task failure after engine initialization should not be attributed to split selection without evidence. Use bundletool’s device targeting to exercise the bundle behavior intended for distribution, and preserve the device specification JSON with the run. If testing a second ABI or form factor, create another row rather than reusing the first installation result. Test install/update/uninstall paths that matter to the app, including when split APKs are installed as a set; do not sideload only a base APK and call it representative of a complete split install. Bundletool can install the required set for a connected device and can also generate sets from a device specification. The diagnostic should report exact ABI and split inventory, runtime and app version, whether required libraries were located and loaded, model-load outcome, and task outcome. Do not publish a broad ABI support list or a claim about Play delivery from a local one-device APK set. This is a packaging and runtime boundary test; device or ABI coverage must be backed by exact evidence for each declared configuration. Keep model performance and compatibility statements separate from the fact that a native split was present.

A local model runs in debug but native initialization fails from a bundle install

A developer tests a universal debug APK and sees a successful task. A release-like App Bundle is converted for another device, where the runtime reports a native-library load error before model initialization. The team has not inspected the targeted APK set.

Decision

Use bundletool to generate and install the APK set for the exact device specification, then inspect ABI splits and trace native load independently from model execution.

Expected outcome

The report identifies whether the failure is in bundle targeting, package contents, native loading, engine initialization, or a later task stage.

Evidence to collect

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

• Bundle and split inventory
• Device-targeted install artifacts
• Cold load and representative task results

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Inventory expected native libraries and ABIs. Record the bundle build variant, app version, supported ABI declarations, runtime dependencies, and any optional native-library requirements documented by the runtime. Do not infer release contents from a debug APK or source dependency list.
2. Generate an APK set for the target configuration. Use bundletool with a connected device or captured device-spec JSON. Save the specification and tool/build versions. A different ABI, density, SDK level, or install set is a separate test configuration.
3. Inspect generated and installed splits. List APKs in the APK-set archive and verify the device-targeted native library split or base contents. Install the complete set with bundletool, then inspect the installed package for the expected ABI path and library names.
4. Trace native loading before inference. Load the native runtime and record linker errors, ABI mismatch, missing dependency, or successful initialization separately. Only after this boundary passes should the test proceed to model artifact load and a fixed task.
5. Repeat install lifecycle and scope conclusions. Exercise the relevant clean install or update path with the complete split set, then run one representative non-sensitive task. Report exact device/ABI and stages; do not infer all Play-served configurations from one local install.

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

Acceptance criteria

• A device specification and generated APK-set identity are saved with each run.
• The full targeted split set is installed and native libraries are checked for the target ABI before model-task claims.
• Native linking, runtime initialization, model loading, and task execution are separate outcomes.
• No universal ABI or store-delivery claim is inferred from a debug or single-device bundletool test.

Decision table

Failure patterns to prevent

• Inspecting the universal debug APK only
• Assuming Play delivery includes every ABI

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 bundletool generation and device-targeted APK testing
• Android App Bundle format and configuration APKs

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

Frequently asked questions