Capture a real test-device specification
Connect an authorized test device and confirm that ADB sees the intended device. Then use bundletool:
java -jar bundletool.jar get-device-spec --output=device-spec.json
When several devices are connected, select the device with the documented device-ID option. Save the specification with the release test record; do not rely on a filename such as my-phone.json without identifying what it represents. Official command reference.
Generate and extract against the same specification
A typical workflow is:
java -jar bundletool.jar build-apks \
--bundle=app-release.aab \
--output=release.apks
java -jar bundletool.jar extract-apks \
--apks=release.apks \
--device-spec=device-spec.json \
--output-dir=device-apks
Provide appropriate signing parameters during generation when the test requires a particular identity. The output set is a local generation result, not evidence of the exact certificate or server behavior of a Play installation.
Know what the specification does not model
The specification guides package selection using characteristics such as supported ABIs, screen density, locales and SDK version. It is not a simulation of network quality, OEM background restrictions, available storage, graphics-driver bugs or user permission decisions.
A package selected for a device can still crash because of application logic. Use the specification to control delivery variables, then test runtime behavior separately.
Use a small matrix instead of one universal device
Choose representative low- and high-SDK devices, required architectures and relevant resource configurations. For each, record which APK files were selected and which critical tasks were exercised.
A useful regression check compares both the package inventory and the behavior. If a release unexpectedly gains an additional native split or loses a language resource, investigate the build change even when the initial launch still succeeds.
Avoid misleading size claims
Size estimates derived from a specification should be labelled with that configuration. Do not present a single arm64-English result as the download size for every global user. A universal APK is a different comparison point and can include resources a specific device will never receive.
APKLint's AAB Analyzer can help inspect the publishing artifact before generation. bundletool and device tests remain necessary to establish which packages are selected and whether that selected set actually works.
Compare two specifications without changing the build
Take one fixed AAB and two saved specifications from authorized test devices. For example, the devices may differ in ABI, density and preferred languages. Generate or extract the matching APK sets and compare their file lists. The purpose is to observe delivery selection for that build, so keep the bundle, bundletool version and signing configuration identical between the two runs.
Give the outputs separate directories and attach a copy of the specification to each result. If one set contains an additional language resource split, record that selection rather than concluding that the build randomly changed. If a required native ABI is absent from the publishing artifact, editing the specification to request that ABI cannot create the missing binary.
Use synthetic specifications as controlled fixtures
A saved JSON specification can serve as a regression fixture, but changing its fields does not turn your laptop into the described phone. Label a hand-edited specification as synthetic and explain the delivery condition it explores. Use a real device or appropriate emulator for claims about successful installation, rendering and native execution. The bundletool command reference documents the specification workflow and accepted command options.
For each fixture, retain the selected APK names and a size estimate with the specification identity. A regression assertion might require that the arm64 fixture still selects an arm64 library and that the intended locale remains available. Avoid asserting an exact byte count indefinitely when ordinary compiler or dependency changes can alter compression. Investigate meaningful inventory changes and use a documented tolerance for a size budget.
Finally, test the application tasks that depend on the selected resources. A locale fixture is useful only if the relevant screens can actually display the translated strings; a density fixture should include the resource-heavy screen where an incorrect asset would be noticed. These checks connect package selection to the feature under test instead of treating successful extraction as a complete compatibility result.
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
