A release build that ships with android:debuggable="true" is one of the more serious and avoidable Android security mistakes. The debuggable flag is meant for development; in a released app it lets anyone attach a debugger to your app on their device, inspect its memory, step through its code, and tamper with it at runtime. Normally the build system sets it correctly for release, but a hardcoded manifest value or a misconfigured build can leave it on. Here is what the flag does, why it is dangerous in release, and how to be sure yours is off.
Short answer
Yes, android:debuggable="true" in a release build is a security risk, because it lets anyone attach a debugger to your app, inspect and modify its runtime, read memory, and tamper with its behavior on any device. Per Android's guidance, the debuggable flag is for development and must be off in release. Normally the release build type sets it to false automatically, but a manifest that hardcodes android:debuggable="true", or a misconfigured build, can leave it enabled. Make sure your release build does not set it, verify the flag in the release manifest, and treat a debuggable release as a defect to fix before shipping.
What you should know
- It enables debugging of your app: attaching a debugger at runtime.
- Release must not be debuggable: the flag is for development only.
- Release builds normally set it false: unless the manifest overrides it.
- A debuggable release is high-risk: runtime inspection and tampering.
- Verify the release manifest: confirm the flag is not enabled.
What does android:debuggable do?
It tells Android whether your app can be debugged at runtime. When android:debuggable is true, the system allows a debugger to attach to the running app, which is what you want during development so you can step through code and inspect state. The same capability in a shipped app is a problem, because it is not limited to you: anyone with the app on a device can attach a debugger and gain the same access, inspecting memory, reading variables, stepping through logic, and altering behavior. So the flag is a development convenience that becomes an exposure if it survives into release, since it hands every user, and every attacker, a window into your app's runtime that release builds are supposed to close.
Why is a debuggable release a risk?
Because it opens the app's runtime to inspection and tampering. The table lays out the exposure.
| With debuggable enabled in release | Consequence |
|---|---|
| A debugger can attach to the app | Anyone can inspect the running app |
| Memory and variables are readable | Sensitive values can be observed at runtime |
| Code can be stepped through | Logic and checks become easy to analyze |
| Behavior can be altered at runtime | Client-side checks can be bypassed |
The throughline is that a debuggable release removes the runtime opacity a shipped app should have. An attacker does not need to root the device to take advantage; the debuggable flag itself grants the access. That makes any secret handled in memory, any client-side check, and any sensitive logic far easier to observe and defeat, which is why a debuggable release is treated as a clear security defect rather than a minor misconfiguration.
How do you make sure release is not debuggable?
Rely on the release build type and verify the result. In a standard Android build, the release build type sets debuggable to false, and the debug build type sets it true, so the simplest correct setup is to not hardcode android:debuggable in your manifest at all and let the build type control it. The way this usually goes wrong is a manifest that explicitly sets android:debuggable="true", which overrides the build type and ships a debuggable release, so search your manifest and remove any such hardcoded value. After building your release, confirm the flag is not enabled in the final manifest, since the build you ship is what matters. Treat a debuggable release build as a release blocker, not a warning to revisit later.
What to watch out for
The first trap is a hardcoded android:debuggable="true" left in the manifest from development, which overrides the release build type and ships debuggable. The second is assuming the build type handled it without verifying the final release manifest. The third is a generated or template project that set the flag and was never checked. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces whether the debuggable flag is enabled in your release build, so you catch a debuggable release before it reaches users. Removing the hardcoded flag and letting the release build type set it is the fix.
What to take away
android:debuggable="true"in a release build is a security risk, letting anyone attach a debugger to inspect, read, and tamper with your app at runtime.- The flag is for development; the release build type normally sets it false unless a hardcoded manifest value overrides it.
- Do not hardcode
android:debuggablein your manifest, and verify the flag is off in your final release manifest. - Treat a debuggable release as a release blocker, and use a pre-submission scan such as PTKD.com to confirm the flag is not enabled before you ship.
