If you are running Android Studio as a Flatpak on Linux, there is a subtle but painful gotcha with debug signing keys that can cost you hours of debugging. The symptoms are generic, the usual troubleshooting steps will mislead you, and the root cause is entirely about where Flatpak stores your keystore.

The Problem

When you install Android Studio via Flatpak, the app runs inside a sandboxed container. This means the debug signing keystore (debug.keystore) that Android Studio uses is not the one at the usual location:

~/.android/debug.keystore

Instead, Flatpak stores it inside the container’s sandboxed filesystem, typically at:

~/.var/app/com.google.AndroidStudio/config/.android/debug.keystore

This matters because when you register your app’s SHA1 fingerprint with Google services (Google Sign-In, Firebase, Maps API, etc.), you need the fingerprint from the keystore that Android Studio is actually using. If you grab the SHA1 from the wrong keystore, every API call that validates against your signing certificate will fail.

How It Manifests

The error you will see is some variant of:

DEVELOPER_ERROR

or:

Status{statusCode=DEVELOPER_ERROR, resolution=null}

or simply:

Code: 10

These are the generic errors Google Play Services returns when the SHA1 fingerprint registered in your Google Cloud Console or Firebase project does not match the fingerprint of the certificate that actually signed your APK. The error tells you nothing about why the fingerprints do not match.

The Trap: signingReport Lies to You (Sort Of)

Here is where it gets really frustrating. The standard advice for debugging SHA1 issues is to run the Gradle signingReport task:

./gradlew signingReport

If you run this outside of Android Studio, in a regular terminal, it will read the debug keystore from ~/.android/debug.keystore, which is the default location for a non-sandboxed environment. It will print a SHA1 fingerprint, and you will register that fingerprint with Google.

But Android Studio Flatpak is not using that keystore. It is using the one inside its sandbox. So the fingerprint from signingReport run in your terminal does not match the fingerprint of the key that is actually signing your debug APK.

You now have two different debug keystores producing two different SHA1 fingerprints, and you have registered the wrong one. Everything looks correct on paper. You followed all the steps. But the app still throws DEVELOPER_ERROR.

This is the trap. Because the usual debugging steps confirm what you already believe, you start looking elsewhere: maybe it is the OAuth client configuration, maybe it is the package name, maybe it is a caching issue. You can easily burn hours going down rabbit holes that have nothing to do with the actual problem.

Solution 1: Get the Fingerprint From the Flatpak Keystore

The most direct fix is to extract the SHA1 fingerprint from the keystore that Android Studio Flatpak is actually using:

keytool -list -v \
  -keystore ~/.var/app/com.google.AndroidStudio/config/.android/debug.keystore \
  -alias androiddebugkey \
  -storepass android

This will print the correct SHA1 fingerprint. Use this fingerprint when registering your app in the Google Cloud Console or Firebase.

You can also run signingReport from within the Android Studio Flatpak terminal (the built-in terminal inside the IDE), which will resolve to the sandboxed keystore and give you the correct fingerprint.

Solution 2: Use Flatseal to Expose the Default Keystore

If you would rather have Android Studio Flatpak use the standard ~/.android/debug.keystore so that everything behaves the same as a non-Flatpak install, you can use Flatseal to grant the Flatpak container access to the default keystore directory.

  1. Install Flatseal from Flathub if you do not have it already.
  2. Open Flatseal and select Android Studio from the app list.
  3. Under Filesystem, add access to ~/.android by adding it to Other files.
  4. Restart Android Studio.

After this, Android Studio Flatpak will be able to see and use the keystore at ~/.android/debug.keystore, and the fingerprints will be consistent whether you run signingReport inside or outside the IDE.

How to Avoid This in the Future

If you are on a Flatpak-based setup, keep in mind that any tool running inside a Flatpak sandbox has its own isolated view of your home directory. This does not just apply to Android Studio. Any Flatpak app that writes to ~/.config, ~/.local, or ~/.android is actually writing to ~/.var/app/<app-id>/ unless you have explicitly granted broader filesystem access.

When something works on the command line but fails inside a Flatpak app (or vice versa), filesystem sandboxing should be one of the first things you check.