Read the top-level structure
A bundle commonly contains a base/ module, additional feature-module directories, BundleConfig.pb and bundle metadata. Within a module, code, resources, native libraries and the manifest have defined locations. The manifest representation in a bundle is not simply the same binary XML stored in a built APK. Bundle format.
Start by listing module names and identifying the base module. Then note which components belong to optional modules instead of assuming every class or asset ships to every device immediately.
Separate module content from delivery behavior
| Area | Question to ask |
|---|---|
| Base manifest | What identity, SDK floor and core components are declared? |
| Feature modules | Which features are installed initially or on demand? |
| Native libraries | Which ABIs are available in each relevant module? |
| Resources | What device configurations can influence generated splits? |
| Bundle configuration | What generation and packaging settings apply? |
A file's presence somewhere in the AAB does not prove that it is present in a particular installed package set. Conversely, a missing file in the base APK may be available in a delivered feature.
Validate with bundle-aware tooling
Use bundletool's validation and APK-generation workflows rather than attempting to install the AAB. For a local structural check:
java -jar bundletool.jar validate --bundle=app-release.aab
A successful validation checks the bundle against the tool's rules. It does not establish Google Play policy compliance, correct backend behavior or safety of every included SDK. bundletool.
Investigate incomplete analysis honestly
An analyzer may decode only the base manifest or provide aggregate counts without every module's resource inventory. Check its documented scope before concluding that a permission, component or asset is absent from the entire application.
For APKLint's AAB Analyzer, use the module and base-manifest information as a starting point. Continue with bundletool and the project when a feature-specific question requires deeper inspection.
Keep a delivery-aware release record
Record module names, delivery modes, target test devices and generated APK sets. Test a fresh installation and a subsequent feature download, including failure and retry behavior if the app uses optional delivery.
This record is more useful than a single “AAB passed” label. It explains which part of the publishing artifact was inspected and which part of actual user delivery was exercised.
Sources and further reading
Reference review: 22 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
