I'm seeing a specific Android device consistently receive floor scores from reCAPTCHA Enterprise, and I can't find any signal that explains why. Looking for anyone who has seen this pattern or knows what an assessment with score: 0 and no reason codes indicates for the mobile SDK.
What I observe on one device (Pixel 9 Pro, Android 17, stock, bootloader locked, verified boot green)
Android SDK com.google.android.recaptcha:recaptcha:18.9.2, app installed from Google Play. Every assessment comes back like this:
tokenProperties: valid: true, action matches expectedAction, clientSignalsFailed: false
riskAnalysis: score: 0, reasons: [], extendedVerdictReasons: []
- 12 attempts over two days: eleven scored 0.0, one scored 0.1. Never a reason code.
- Persists across two networks (Wi-Fi and mobile data), across an app-process restart with a fresh client and fresh token, and across a device reboot.
- The SDK reports no error — executeTask succeeds every time, so the app has nothing to react to.
- In logcat the SDK's Play Integrity exchange (StandardIntegrity: requestExpressIntegrityToken → onRequestExpressIntegrityToken) completes normally in under 100 ms.
Controls that pass, same account, same network, same minute
- Web reCAPTCHA in the browser on the same Pixel 9 Pro.
- The same app build on a Pixel 5 (Android 14): login succeeds.
- A sideloaded (non-Play-signed) build of the app on the Pixel 9 Pro gets score: 0 with UNEXPECTED_ENVIRONMENT — so environment detection is clearly working; the Play build's reason-less zeros are the anomaly.
Not just my device
From the logs I can see the same shape — valid token, score 0, empty reasons — recurring on other users' devices too, mostly Pixels and Samsung Galaxy S-series, typically as a run of identical results from one device.
Questions
1. For the mobile SDK, what does score: 0 with an empty reasons list mean? Is it "no device signal / attestation unavailable" as opposed to a genuine high-risk verdict? The interpretation docs only cover the named reasons.
2. Is a Play services / DroidGuard / Play Integrity token-provider state known to cause this on certified devices, and is there any client-side way to detect or recover from it (re-fetching the client and rebooting did not help)?
3. Is there a recommended server-side way to distinguish this shape from real abuse so it can be routed to a step-up rather than a hard block?
