Confirm that the files belong together
For every APK, verify the application ID, version code and signing identity. Check which file is the base and which files provide ABI, density, language or feature content. Keep the source of the set in your test record.
A set extracted from one phone may be tailored to that phone. It may omit an ABI required by another device, and it may not include on-demand modules that were never installed. Bundle delivery model.
Prefer bundletool when you have the AAB
Generate the package set for the intended test device from the original bundle, then use bundletool's install command:
java -jar bundletool.jar install-apks --apks=app-device.apks
This example assumes that app-device.apks is an already generated, compatible archive. Select the intended connected device using the documented options when more than one is available. bundletool installation.
Use ADB for an explicit authorized set
When you already have the correct individual APKs, ADB supports a multiple-package-file install operation:
adb install-multiple base.apk split_config.arm64_v8a.apk split_config.en.apk
The filenames are illustrative. Include the actual required files for the app and device; this is not a universal three-file recipe. Read the package manager's error rather than assuming any failure is a permissions problem. ADB.
Interpret common failures
| Failure family | Likely investigation |
|---|---|
| Missing split | Incomplete configuration or feature set |
| Signature mismatch | Files from different signers or release paths |
| Version conflict | Base and splits from different releases |
| No matching ABI | Native libraries do not support the device |
| Update incompatible | Existing installed identity differs |
Uninstalling can destroy local app data. Do not use it as the first troubleshooting step on a device containing valuable user information.
Verify more than installation
Launch the app, switch relevant language or display configurations and exercise features that depend on native code or optional modules. An app can install successfully while a particular screen fails when it loads a missing resource.
APKLint can help inspect the individual artifacts. Its report for one APK should not be interpreted as validation that the complete split set is installable or functionally equivalent on every device.
Diagnose an incomplete set without guessing
Suppose a package manager reports that a required split is missing. Preserve that exact error and the list of APKs supplied. Compare the list with the known generated or extracted set, checking the base, required feature relationships and configuration selection. Do not treat every file containing the word “split” as optional; its role comes from package metadata and delivery configuration.
Recover the missing piece from the same release source. If the source is an AAB you own, regenerate the APK set for the intended device. If the source is an installed test package, repeat the package-path inventory before copying again. Mixing a base from one extraction with a similarly named configuration APK from a later update makes the problem harder to diagnose.
Test an update with saved application state
Prepare the previous supported release with a small synthetic data set, such as two saved notes and one preference. Install the complete candidate set through the intended update path and verify that the data remains available. Then exercise a feature that depends on a native library and a screen that uses localized resources. This checks more than the success message from the installer.
If the update is rejected because of signing or version compatibility, inspect those facts before uninstalling. A clean installation can be useful as a separate diagnostic, but it erases the update condition you were trying to reproduce. The ADB installation documentation describes the tool interface; your release record should supply the expected identity and migration behavior.
For a device-specific set, record the tested device configuration with the result. Successful installation on that device does not prove the same files support another architecture or resource configuration. Keep the original publishing artifact available so other configurations can be generated coherently instead of building an unofficial library of interchangeable-looking split files.
Sources and further reading
- Android Developers: bundletool
- Android Developers: Android Debug Bridge
- Android Developers: App bundle format
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
