Debug builds are signed automatically with a self-signed debug certificate, and app stores including Google Play do not accept apps signed that way. What you publish must be signed with your release key, which for most apps today is the upload key used with Play App Signing.
Definitions
A keystore is a file that holds private keys and certificates. A debug keystore is one that Android Studio creates for you so you can run test builds without setting anything up. A release key is the key you create and protect for signing builds that go to users or to a store.
The comparison
Google's documentation compares them directly.
| Debug | Release | |
|---|---|---|
| Who signs | Android Studio, automatically | Your upload key, or your app signing key if you do not use Play App Signing |
| Where the key lives | A debug keystore in your home folder under the Android settings directory, created on first run | A keystore you create yourself |
| Can you publish with it | No | Yes |
Google says most app stores, including Google Play, do not accept apps signed with a debug certificate.
Why the debug key is weak by design
The debug certificate is self-signed and is created on a developer machine. Nothing about it identifies your organization, and every developer's copy is different. It is meant for convenience. Treat any build signed with it as a test build: do not share it with customers, do not attach it to a release page, and do not install it on devices that hold real data.
Google notes that the debug certificate has a long expiry. When it does expire, you get a build error, and the fix is to delete the debug keystore so Android Studio regenerates it on the next build and run. That is a developer convenience problem, not a release problem.
How to find out what signed a build
Google says you can find the debug keystore location by running the Gradle signing report task and looking for the line that starts with Store. The same report is a quick way to see which signing configuration each build variant uses.
./gradlew signingReport
Run it in your release pipeline's setup step and confirm that the release variant does not point at the debug keystore.
Guardrails for a release pipeline
- Separate variants. Make the debug and release build types explicit in Gradle, and never fall back to debug signing for release if a secret is missing.
- Fail closed. If the release keystore is unavailable, fail the build instead of producing an unsigned or debug signed artifact.
- Check the artifact. After the build, verify which certificate signed it before you upload it anywhere.
- Keep sideload builds separate. If you share test builds, label them as test builds and use a separate distribution channel.
A related post covers verifying an APK after the build at /resources/blog/verify-an-apk-signature-with-apksigner.
What about store rejection?
If you upload a debug signed build, Google Play will reject it, which is the safe failure. The risky case is a debug signed build shared outside the store, where no gatekeeper exists at all. That is where discipline in your own pipeline matters.
Where Safeguard fits
Signing choices do not tell you what libraries a build contains. Safeguard offers dependency scanning and SBOM generation, with a free scan at gold.safeguard.sh/scan.
Quick check
Can I publish a debug signed app on Google Play?
No. Google states that most app stores, including Google Play, do not accept apps signed with a debug certificate.
My debug key expired and the build fails. What do I do?
Google says to delete the debug keystore. Android Studio regenerates it on the next build and run.
How do I find my debug keystore?
Run the Gradle signing report task and look for the line starting with Store.
Sources
Last reviewed: 19 October 2026.
