Debugging log · Firebase

google-services.json doesn't match the package

The build stopped at a Firebase task — processDebugGoogleServices — saying it found no matching client for my package name. The file was right there in the app folder; Firebase was set up. The problem was subtler: the package name inside google-services.json didn't match the applicationId the build was actually using, and the plugin refuses to proceed when they disagree.

The short version: the google-services plugin matches your build's applicationId against the package names registered in google-services.json. If they don't match — often because a debug suffix or a rename changed the id — it fails. Register the exact id in Firebase and use the fresh file, or align the id.

The error

No matching client found for package name
'com.example.app.debug'
  (or: Execution failed for task ':app:processDebugGoogleServices')

Read the package name in the message carefully — it's the id the build is looking for. Compare it to what's registered in your file, and the mismatch is usually obvious.

Why it happens

At build time the google-services plugin reads your applicationId and searches google-services.json for a client registered with that exact package name. The file can hold several clients, but your running id must be one of them. The common ways they drift apart:

A debug suffix. If debug builds use applicationIdSuffix ".debug", the id becomes com.example.app.debug — which isn't registered in Firebase, so debug builds fail while release works.
A renamed package / applicationId that was never updated in Firebase.
A stale file from a different Firebase project or an old app registration.
Build flavors with different ids, only some of which are registered.

Fix 1 — register the exact id in Firebase

In the Firebase console, add an Android app whose package name is the exact id the build uses, including any suffix (com.example.app.debug as a separate app if you use a debug suffix). Download the new google-services.json — it now contains a client for every registered id — and replace the one in your app/ folder. One file can serve debug and release this way.

Fix 2 — align the applicationId instead

If you don't want to register the suffixed id, the alternative is to not change the id for the build that's failing. But a debug suffix is genuinely useful (it lets debug and release coexist on a device), so registering the debug id in Firebase is usually the better fix than dropping the suffix.

Then clean and rebuild

The plugin processes the file at build time, so after replacing google-services.json do a clean build to regenerate the config:

./gradlew clean assembleDebug

A stale build can keep reporting the old mismatch even after you've dropped in the correct file.

The fastest check: look at the package name in the error, then open google-services.json and search for it. If it's not in there verbatim, that's your whole problem — register that id in Firebase and re-download the file.

Package names above are examples — match the exact id from your own error and Firebase project.