Query the package directly
For a local APK you own, use apkanalyzer:
apkanalyzer manifest debuggable app-release.apk
apkanalyzer manifest print app-release.apk
Record the APK hash and build variant with the result. If the artifact is delivered as splits, inspect the relevant base package and the complete release context.
Trace an unexpected value
Review build variants, manifest source sets and library contributions. A custom build type may inherit debug settings, or a CI job may have uploaded the wrong artifact.
| Evidence | Investigation |
|---|---|
| Debuggable output from a release-named file | Actual task and variant used by CI |
| Correct local output but wrong distributed build | Upload artifact selection and release track |
| Debug-only trust rules active | Manifest flag and network configuration source set |
| Unexpected diagnostic UI | Build flags and feature gating beyond the manifest |
Do not simply rename the output file or assume optimization disables debugging automatically.
Fix configuration and artifact selection
Make the intended release build non-debuggable, rebuild it and inspect the new package. Confirm that the CI pipeline selects that exact output and signing configuration. Preserve separate paths for debug and release artifacts to reduce accidental substitution.
Follow Android security guidance for production hardening, but keep the claim narrow: non-debuggable does not mean impossible to analyze or free of vulnerabilities.
Test the corrected release
Install the actual release build in a controlled environment and verify core features, logging behavior and network trust. Debug and release variants can differ in more than one flag, so a manifest-only fix can expose an unrelated configuration problem.
Use APKLint for independent inspection
The Debuggable APK Checker helps examine the shipped flag. It is a focused check, not a complete release certification. Keep its observation with the build hash and your release-pipeline evidence so the result refers to the file users actually receive.
Trace a debug flag through artifact selection
Imagine CI builds both a staging debug APK and a production release APK, then uploads the first file matching a broad wildcard. A package named release-candidate.apk may therefore contain the debug variant despite a correct release configuration. Inspect the packaged application ID, debuggable flag and signing identity, then compare them with the task output that the upload step selected.
Repair the selection by using the explicit output from the intended variant. Keep staging and production artifacts in separately identified locations and verify the selected artifact after copying it into the release staging directory. A check performed before the mistaken copy can pass while the wrong file is still distributed.
Check related behavior without equating it to one flag
A non-debuggable manifest value does not prove that diagnostic screens, verbose logs or development endpoints were removed. Review those controls according to how the application implements them. Conversely, shrinking or obfuscation is not a substitute for checking the debuggable setting. The Android build-variant guide explains how build types and source sets can produce different application configurations.
For a focused test, install the actual candidate with synthetic data and exercise the paths that differed in development: a network request, a deep link and a diagnostic entry point relevant to your app. Record whether the intended endpoint and trust configuration are used. Avoid asserting a complete hardening result merely because one inspector reports the expected manifest flag.
Make the packaged flag check a repeatable release gate tied to the artifact hash. Record the expected non-debuggable value explicitly and have the job fail when the parser returns a different value or cannot read the manifest. An unavailable result should not be converted into a successful false value by a default in the test script. If the check fails, retain the offending artifact and build metadata long enough to identify the configuration error. Rebuilding without knowing which variant was selected can make the symptom disappear once while leaving the faulty CI rule ready to select the wrong output again.
Sources and further reading
- Android Developers: apkanalyzer command-line reference
- Android Developers: Configure build variants
- Android Developers: Security best practices
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
