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.
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
