Analytics: SecurityException "GoogleCertificatesRslt: not allowed" in play-services-measurement-base 23.2.0 (BoM 34.11.0+) on stock Android 14–16 devices

[samilaltin]

[READ] Step 1: Are you in the right place?

Yes, this is a runtime crash whose stack trace originates entirely inside play-services-measurement-base (this repo). No frames from our application code appear in the trace, so we cannot work around it from app code.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Android Studio Otter 3 Feature Drop | 2025.2.3
• Firebase Component: Analytics (play-services-measurement-base)
• Component version: 23.2.0 (Firebase BoM 34.11.0; also reproduces on 34.12.0 which keeps analytics at 23.2.0)

Additional: minSdk 26, targetSdk 36, Gradle 9.1.0, AGP 9.0.1, Kotlin 2.3.20.

[REQUIRED] Step 3: Describe the problem

A java.lang.SecurityException: GoogleCertificatesRslt: not allowed is thrown on a Google Play Services internal HandlerThread during zack.registerListener after zabq.onConnected.

Crashes are exclusive to app version 1.5.0 (versionCode 17 + 18) — the first build to ship BoM 34.11.0. The prior version 1.4.x (BoM 34.8.0, analytics 23.0.0, identical Analytics code paths) shows zero crashes with this signature. The SHA-256 reported in the error matches our Play App Signing certificate, so these are not repackaged APKs; affected devices are stock retail flagships running Android 14/15/16: Samsung Galaxy S23 Ultra, S24 Ultra, S24+, Xiaomi Redmi 12, Tecno Camon 20 Pro. Affected GMS version on those devices: 261631035.true (≈ 26.16.31).

BoM 34.12.0 does not bump firebase-analytics (still 23.2.0) and the signature continues unchanged on 34.12.0.

Steps to reproduce:

Not reproduced on internal QA devices — surfaces only in the field via Crashlytics. The trigger appears to be the GMS measurement client connecting and registering its listener for the first time during a session, not a specific logEvent callsite.

Observed conditions, all required together:

1. App built with Firebase BoM 34.11.0 or 34.12.0 (analytics / measurement-base 23.2.0).
2. Analytics initialized via FirebaseAnalytics.getInstance(application) + setAnalyticsCollectionEnabled(true).
3. Stock retail device on Android 14/15/16 (e.g. Galaxy S23/S24 Ultra, S24+, Redmi 12, Camon 20 Pro).
4. Device GMS version 261631035.true (≈ 26.16.31).

Crash signature from Crashlytics (package and SHA-256 redacted per org policy; can share privately if needed):

Fatal Exception: java.lang.SecurityException
GoogleCertificatesRslt: not allowed: pkg=<our.package>, sha256=[<redacted>], atk=false, ver=261631035.true (go/gsrlt)
       at android.os.Parcel.createExceptionOrNull(Parcel.java:3354)
       at android.os.Parcel.createException(Parcel.java:3338)
       at android.os.Parcel.readException(Parcel.java:3321)
       at android.os.Parcel.readException(Parcel.java:3263)
       at com.google.android.gms.internal.measurement.zzbl.zzc(com.google.android.gms:play-services-measurement-base@@23.2.0:3)
       at com.google.android.gms.internal.measurement.zzkt.zzj(zzkt.java:4)
       at com.google.android.gms.internal.measurement.zzkg.accept(zzkg.java:2)
       at com.google.android.gms.common.api.internal.zack.registerListener(zack.java:1)
       at com.google.android.gms.common.api.internal.zabq.zaH(com.google.android.gms:play-services-base@@18.4.0:9)
       at com.google.android.gms.common.api.internal.zabq.onConnected(com.google.android.gms:play-services-base@@18.4.0:2)
       at com.google.android.gms.common.internal.zah.onConnected(zah.java:1)
       at com.google.android.gms.common.internal.zzf.zza(com.google.android.gms:play-services-basement@@18.10.0:10)
       at com.google.android.gms.common.internal.zza.zzc(zza.java:2)
       at com.google.android.gms.common.internal.zzc.zzd(zzc.java:3)
       at com.google.android.gms.common.internal.zzb.handleMessage(com.google.android.gms:play-services-basement@@18.10.0:33)
       at android.os.Handler.dispatchMessage(Handler.java:110)
       at android.os.Looper.loopOnce(Looper.java:273)
       at android.os.Looper.loop(Looper.java:363)
       at android.os.HandlerThread.run(HandlerThread.java:85)

We are planning to downgrade to BoM 34.10.0 to confirm the regression boundary, but would prefer a forward fix.

Question: is this a known regression in play-services-measurement-base 23.2.0's GMS connection / listener-registration path, or in the GMS certificate-verification side it now invokes? If it's a GMS-side bug exposed by 23.2.0, what's the recommended path — pin to BoM 34.10.0 / analytics 23.0.0 until a fix ships, or wait for a specific GMS rollout?

Relevant Code:

The only Analytics setup in our DI graph:

@Provides
@Singleton
fun provideFirebaseAnalytics(application: Application): FirebaseAnalytics {
    val analytics = FirebaseAnalytics.getInstance(application)
    analytics.setAnalyticsCollectionEnabled(true)
    return analytics
}

Standard firebaseAnalytics.logEvent(name, bundle) is used elsewhere. No Analytics-related manifest meta-data is set.

[lehcar09]

Hi @samilaltin, thank you for reaching out. I tried reproducing the issue on a similar device specs, based on what you shared, however, I wasn't able to replicate the issue.

From what I gather, there are couple of reasons that could cause the issue:

• Out of Sync Google Play Services
• Identity of the app has been tampered (i.e If a user side-loads your app (downloads an APK from a third-party site instead of the Play Store))
• "OEM" Battery Optimizations or "App Cloners"
• Play Store "Internal Sharing" vs. Production

Can you share when was this issue started? Also, how may of your users experiencing this issue?

[samilaltin]

Hi @lehcar09, thanks for taking a look.

When it started: the very first build that shipped Firebase BoM 34.11.0 — our app version 1.5.0, versionCode 17, released to Play Store production on 2026-04-22. A follow-up build (versionCode 18, same BoM) shipped on 2026-04-27 and continues to produce the same signature. Crashlytics shows zero occurrences of this signature before 2026-04-22.

Impact so far: 6 crashes / 6 users in total across 1.5.0 versionCode 17 and 18, reported as <0.01% by Crashlytics. Low absolute volume but consistently appearing on stock Samsung Galaxy S23 Ultra / S24 Ultra / S24+, Xiaomi Redmi 12, and Tecno Camon 20 Pro on Android 14–16. Across those 6 reports we see five distinct GMS micro-builds in the error string: 261631013, 261631029, 261631035 (≈ 26.16), and 261533029, 261533035 (≈ 26.15) — so it isn't pinned to a single GMS push. The top of the stack (zack.registerListener → zabq.onConnected → zah.onConnected → measurement-base 23.2.0) is byte-identical across every report, on every device. We can also see OEM-specific helper threads from three different Android skins in the recorded thread dumps (Samsung One UI, Xiaomi MIUI MiuiMonitorThread, Tecno HiOS MulLinkAppThread / AppLiceJDWP), so it isn't a single-OEM customization either.

On the four hypotheses you mentioned:

1. Out-of-sync Play Services — all five observed GMS micro-builds (across the 26.15 and 26.16 lines) are current. The same devices on the same GMS were running our previous version (1.4.x, BoM 34.8.0, analytics 23.0.0) without ever producing this signature.
2. Tampered / side-loaded APK — the SHA-256 in the error matches our Play App Signing certificate. Not a third-party APK.
3. OEM battery optimizations / app cloners — affected devices are vanilla retail flagships, no app cloners involved as far as we can tell. If there is a specific OEM tweak you suspect, happy to dig.
4. Internal Sharing vs Production — 1.5.0 has only ever been distributed via the Play Store production track.

Why we're confident this is BoM-bound rather than environmental: the entire app cohort (same users, same devices, same GMS builds, same distribution channel) was running 1.4.x with zero crashes of this signature. The only Analytics-related delta between 1.4.x and 1.5.0 is BoM 34.8.0 (analytics / measurement-base 23.0.0) → 34.11.0 (23.2.0). BoM 34.12.0 keeps analytics at 23.2.0 and the signature continues unchanged.

Volume is low enough that we can hold off on a hotfix while you investigate, but we're prepared to ship a 1.5.x with BoM pinned back to 34.10.0 on a small rollout if that would help confirm the regression boundary. Happy to share package name, SHA-256, or a Crashlytics issue link via a private channel if needed.

[carlonzo]

Thanks @samilaltin to open the above. just wanted to add we see this crash on the thousands users starting from same day on older and newer versions of our app, making me think of something out of our control. The number last week reduced by quite a bit.

[lehcar09]

Hey @samilaltin, thank you for additional information and checking for the possible causes. I'll raise this to our engineers and see what we can do here. Thanks!

[Faierbel]

We're seeing the same crash in production and wanted to share data that may help.

Volume (last 90 days): 510 events / 510 unique users.
Onset: zero occurrences before 2026-04-22, then a sharp spike on that date, the same regression date @samilaltin reports. Unlike the OP, the crash hits multiple already-published builds simultaneously, including app versions released months earlier.

That matches @carlonzo's observation more than a build-bound regression: client binaries that had been running fine for weeks all began crashing on the same day, suggesting a server-side / GMS-side change rather than something purely in the BoM 34.11.0 client code. The build currently in production ships Firebase BoM 34.12.0 and the crash continues unchanged.

OS distribution of affected users:

• Android 16: 69%
• Android 15: 15%
• Android 14: 8%
• Android 13: 4%
• Android 12 / 11 / 17: ~1% each

So the spread is broader than the Android 14–16 range in the OP, we see a small but non-zero slice on Android 11, 12, and 17 as well.

Device makers: top is Google at ~36% (Pixel-class), with the rest spread across Samsung / Xiaomi / others

Device state at crash time: 96% background. The crash fires almost exclusively while the app is not in the foreground, which fits the description of the GMS measurement client connecting and registering its listener outside any user-initiated event.

Build info:

• Firebase BoM 34.12.0
• minSdk 26, targetSdk 37
• Standard Analytics setup (FirebaseAnalytics.getInstance() + setAnalyticsCollectionEnabled(true))
• Distributed only via Play Store production; signing cert matches Play App Signing.

[lehcar09]

Thanks for the additional information @carlonzo and @Faierbel.

I can't say anything for sure if this is a server side issue, but, from what I gather the occurrence of the issue coincides with Google Play Services releases. I also found this similar issue (https://issuetracker.google.com/issues/505976408) filed in Android Public Tracker.

I've raised this to our engineers for investigation. I'll post back here once I hear from them. Thanks!

[amberkira]

we reached the same problem in mom 34.13.0 is there any workaround？ maybe like downgrade to 34.8.0？

[Moervean]

Also happened to me with firebaseBOM = "34.13.0". I had 1 phone that gave similar error, but downgrading BOM didn't help. However I'm thinking if it happens only on 1 of my phones maybe downgrading BOM would fix it for some users/phones. Have someone tried it?

[samilaltin]

Hey @amberkira, @Moervean — we haven't downgraded. Crash volume on our side is still pretty low, so we're just sitting on the current BoM for now.

The Android tracker issue @lehcar09 linked (https://issuetracker.google.com/issues/505976408) looks like the place to watch. Still waiting on the Firebase team here too.

[amberkira]

Hey @amberkira, @Moervean — we haven't downgraded. Crash volume on our side is still pretty low, so we're just sitting on the current BoM for now.

The Android tracker issue @lehcar09 linked (https://issuetracker.google.com/issues/505976408) looks like the place to watch. Still waiting on the Firebase team here too.

@samilaltin @Moervean I have downgraded to 34.8.0, right now it seems to be all right.