What it means
A debuggable app accepts a debugger and exposes its process to run-as on any device: its data and memory can be read without root. The Android Gradle Plugin sets the flag on debug builds only; it ends up in a store upload when the debug variant is uploaded, when the manifest hardcodes it, or when a release build type sets isDebuggable = true.
Deadline
No date: Google Play has refused debuggable uploads for years. It is a blocker today.
How to fix it
1. Build the release variant
./gradlew bundleRelease # app/build/outputs/bundle/release/app-release.aab
./gradlew assembleRelease # APK2. Do not force the flag
android {
buildTypes {
release {
isDebuggable = false // the default; remove any 'true'
}
}
}Delete android:debuggable from AndroidManifest.xml if it is there: the build type sets it for you, and a hardcoded value wins over it.
Check before you submit
Upload the APK, AAB or split-APK set (XAPK, APKS, APKM) on the store check page. It runs PLAY-DEBUGGABLE against the dates on this page, then deletes the file: nothing about the app is kept. The same engine runs offline in the Narvy CLI, and exits with code 1 when a blocker is found, so it can gate a CI job.
narvy store-check app-release.aabFAQ
I built with bundleRelease and it is still flagged. Why?
Look for android:debuggable="true" in src/main/AndroidManifest.xml or in a flavor manifest, and for isDebuggable = true (Groovy: debuggable true) in the release build type or a custom build type you upload.
Is "signed in debug mode" the same error?
No. "You uploaded an APK or Android App Bundle that was signed in debug mode" is about the signing key, not the debuggable flag: sign with your upload key (a release signing config). The two often come together when the debug variant is uploaded.
Is a debuggable build a security issue outside the store?
Yes. Anyone with the device can attach a debugger or read the app's private files through adb shell run-as. Never ship one to testers outside your team either.