Start with an inventory, not extraction
Keep the original APK unchanged and record where it came from. Work on a copy of a build you own or are authorized to inspect. Android's command-line analyzer can describe the archive without installing it:
apkanalyzer apk summary app-release.apk
apkanalyzer files list app-release.apk
apkanalyzer manifest print app-release.apk
The first command identifies the package and version. The second lists packaged paths. The third decodes the manifest; opening the raw AndroidManifest.xml in a text editor usually does not produce readable XML because the packaged version is binary. These are inspection commands, not malware or authenticity tests. Command reference.
What the important paths mean
| Path or entry | What to inspect | What not to assume |
|---|---|---|
AndroidManifest.xml |
Components, permissions, SDK declarations | It is the original source manifest |
classes.dex, classes2.dex |
Compiled managed-code inventory | Every class belongs to the app author |
resources.arsc and res/ |
Resource table, layouts and configuration variants | Every resource has a readable filename |
assets/ |
Files packaged for the app to load | Assets are necessarily images |
lib/<abi>/ |
Native shared libraries by CPU architecture | One ABI works on every device |
META-INF/ |
Metadata and possible v1 signing entries | Absence means the APK is unsigned |
Modern APK signatures can live in an APK signing block rather than ordinary ZIP entries. A directory listing alone cannot establish signature validity.
Compare the final package with the intended release
Check the application ID, version code and target SDK against the release record. Then inspect changes rather than an isolated snapshot: an unexpected new permission, native library or SDK package deserves an explanation even when the total size barely changes.
For a game, a large asset archive might be normal. For a small text utility, the same archive may reveal an accidentally bundled test fixture. The relevant question is whether each major component has an owner and a production purpose, not whether the APK exceeds an arbitrary size threshold.
Account for bundles and splits
An APK downloaded from a device may be only the base split. Language, density, ABI and dynamic-feature resources can be in companion APKs. An AAB is a different publishing container with module-specific contents; do not apply the base-APK inventory to the whole delivered application. Bundle format.
A useful inspection result
Save a small release worksheet containing the package ID, version, SDK levels, architectures, major size contributors and unexplained differences. Mark fields that your analyzer did not provide as unknown rather than filling them from a filename.
APKLint's APK Analyzer can give a structural starting point. Use Android Studio or the command-line tools for a complete resource investigation, and a separate signature-verification step when integrity matters. Finding a recognizable package name does not authenticate the publisher.
Work through an unexpected archive entry
Consider two releases of a notes application. Both contain classes.dex, a resource table and an arm64-v8a directory. The second also contains assets/demo-recordings.zip, an illustrative 18 MB archive. Start by asking which build input introduced that exact path. It might come from the application's assets directory, an imported library or a generated task. Deleting the entry from the finished APK would break the signed artifact and would leave the build error ready to return in the next release.
Instead, inspect the candidate file in the project or dependency that owns it. Confirm whether production code expects to load it and whether it is an intentional offline feature. If it is a demonstration fixture, exclude it at its source, rebuild and compare the package inventory again. If it is required, measure the delivered cost and give the feature an explicit size budget. The same filename can be legitimate in a training app and accidental in a small utility; the directory name alone cannot make that decision.
Preserve resource identity while investigating
A second example is an icon that looks correct on one phone but wrong on a tablet. Searching the extracted folder for one PNG can miss alternate density or configuration resources. Use the decoded resource information to trace the identifier and the configuration that selects each value. The resource commands support inspecting configurations and names. Record the selected resource and device configuration together, then reproduce the incorrect selection in the app.
Keep original packaged paths in any exported inventory. Flattening every file into one directory can overwrite two resources with the same basename and destroys the context needed to distinguish them. A useful comparison row includes the full path, owning module when known, byte size and the reason for the change. Save unknown ownership explicitly until a build dependency or source input explains it. An inventory becomes actionable when each unexpected difference has a traceable cause, rather than when every directory has been opened once.
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
