Choose the artifact that answers the question
Analyze the exact release variant being shipped. A debug APK can include different code, resources, logging and instrumentation. Comparing a debug build with a minified release build makes it difficult to attribute a change to one dependency or feature.
Record the application ID, version code, build variant and source revision before opening the file. For a Play-distributed app, note whether you are examining a universal APK, a base split or APKs generated for a device. These packages answer different size and compatibility questions.
Open the analyzer and establish a baseline
Use Android Studio's Build → Analyze APK action; menu placement can vary with Studio versions, so action search is a practical fallback. Select the APK and begin at the package root. Expand only the categories relevant to the investigation rather than reading thousands of entries indiscriminately. APK Analyzer documentation.
A disciplined pass has three stages:
- Identify the largest file categories and compare raw contribution with download estimates.
- Inspect the decoded manifest for the final permissions, components and SDK declarations.
- Explore DEX packages or resources associated with the changed feature or dependency.
For repeatable metadata checks outside the IDE, use:
apkanalyzer manifest application-id app-release.apk
apkanalyzer manifest version-code app-release.apk
apkanalyzer dex list app-release.apk
Investigate a size increase with a controlled comparison
Suppose a release grows after adding an analytics library. Compare artifacts built from adjacent revisions with the same variant and optimization settings. Look for new DEX packages, bundled native libraries and transitive dependencies. The named library may be small while a transitive component accounts for most of the increase.
If image resources dominate instead, inspect configuration variants and originals accidentally packaged in assets/. Removing a language or architecture solely to shrink the chart can exclude users; make distribution decisions deliberately.
Understand the limits of the view
A class present in DEX does not prove that its code executes in your app's normal flow. An absent resource in a base split does not prove it is missing from delivery. Compressed file size also does not equal installed storage or RAM use.
The analyzer can reveal evidence that motivates a test. It does not replace an installation test, runtime profile, signature verification or security assessment. Command-line alternatives.
Close the loop
After the proposed change, rebuild under the same conditions and repeat the comparison. Keep before-and-after figures with the exact artifact identifiers. Test the features associated with removed code or resources, including release-only paths affected by shrinking.
Use APKLint for a quick structural summary or sharing a focused finding, then return to the build-aware analyzer when resource-level attribution or full project context is required.
Turn the comparison into a testable hypothesis
Suppose an image-editing app grows from an illustrative 24 MB to 31 MB after a feature branch is merged. Record those sizes, but do not attribute all 7 MB to the feature's own classes. Expand the changed native libraries, assets and DEX packages in the comparison. A new 5 MB native dependency plus 2 MB of sample images calls for two different decisions. Removing sample images may be safe; removing the native dependency may disable the feature.
Make a candidate build that excludes only the sample images through the project's packaging inputs. Compare that candidate with the same baseline, and confirm the expected paths disappeared. Launch the release variant and open the feature with an empty user library, an imported image and a cancelled import. These cases check whether a supposedly unused sample was actually serving as a fallback. The numerical reduction and the feature checks together support the change.
Avoid blaming the wrong DEX package
Package names in a minified release can be abbreviated, and references to a class do not establish that the class is defined in the selected DEX file. Load mappings from the exact build when available, as described by the Android Studio analyzer documentation. A mapping retained from yesterday's build may attach plausible names to the wrong artifact, making an explanation look more certain than it is.
If an unexpected class belongs to a third-party dependency, use the project's dependency report to identify how it entered the selected runtime configuration. Then compare the report with the packaged result. A compile-time dependency list and a final APK inventory answer different questions, especially when shrinking removes unused code. Preserve both pieces of evidence when proposing a dependency change.
Finally, put the comparison artifacts under explicit labels such as baseline, candidate and accepted release. Do not rely on three files all called app-release.apk in different download folders. Associate each screenshot or exported observation with a file hash, so another developer can reopen the same comparison without reconstructing which build was selected.
Sources and further reading
- Android Developers: Analyze your build with APK Analyzer
- Android Developers: apkanalyzer command-line reference
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
