Debuggable Release APK: Inspect the Built Artifact, Not Just Gradle

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.

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.