Checklist
Description
Title
CredentialsManagerException.isDeviceIncompatible() is being returned from
SecureCredentialsManager.saveCredentials() on modern, fully crypto-capable
devices — e.g. Galaxy S24+, Galaxy Z Fold5, recent Pixels — that clearly support
AndroidKeyStore RSA/AES.
Checklist
Summary
Your own docs describe CredentialsManagerException.isDeviceIncompatible() as a
rare, catastrophic condition:
"Device is not compatible with some of the algorithms required by the
SecureCredentialsManager class. This is considered a catastrophic event and
might happen when the OEM has modified the Android ROM removing some of the
officially included algorithms."
— EXAMPLES.md
In production we see the exact opposite of "rare / exotic ROM": this fires at
scale on mainstream, fully crypto-capable flagships (Galaxy S24+, Galaxy Z Fold5)
running a stock. These devices support AndroidKeyStore
RSA/AES — they have not had algorithms stripped.
Production data (30-day window, analytics-tracked handled exceptions)
Why this matters
The documented remedy for isDeviceIncompatible is "fall back to the regular
CredentialsManager" — plain-text storage. That is acceptable for the rare
ROM-stripped device the docs describe. It is not acceptable to silently route
a large, mainstream population to plain-text token storage
because of what looks like an over-eager incompatibility verdict. The correct
outcome is that these capable devices keep using secure storage.
Environment
Reproduction
- A capable stock device (we see it on Galaxy S24+ / Z Fold5).
- Login/signup via the SDK, then
SecureCredentialsManager.saveCredentials().
- Observe
CredentialsManagerException with isDeviceIncompatible() == true.
(Not reproducible on a Pixel 7a on our side — appears intermittent / device-dependent.)
Additional context
No response
Auth0.Android version
3.16.0
Android version(s)
16 and others
Checklist
Description
Title
CredentialsManagerException.isDeviceIncompatible()is being returned fromSecureCredentialsManager.saveCredentials()on modern, fully crypto-capabledevices — e.g. Galaxy S24+, Galaxy Z Fold5, recent Pixels — that clearly support
AndroidKeyStore RSA/AES.
Checklist
Summary
Your own docs describe
CredentialsManagerException.isDeviceIncompatible()as arare, catastrophic condition:
In production we see the exact opposite of "rare / exotic ROM": this fires at
scale on mainstream, fully crypto-capable flagships (Galaxy S24+, Galaxy Z Fold5)
running a stock. These devices support AndroidKeyStore
RSA/AES — they have not had algorithms stripped.
Production data (30-day window, analytics-tracked handled exceptions)
sdk_method = save_credentials, "This device is not compatible with theSecureCredentialsManager class": ~14,700 occurrences
fixed the PKCS1→OAEP migration, but
generateNewAESKey()still re-throwsIncompatibleDeviceExceptionwhen the Keystore op fails, so on these devicescredential storage is now a clean-but-fatal failure → users can't complete
login/signup (next read is "credentials not found").
Why this matters
The documented remedy for
isDeviceIncompatibleis "fall back to the regularCredentialsManager" — plain-text storage. That is acceptable for the rareROM-stripped device the docs describe. It is not acceptable to silently route
a large, mainstream population to plain-text token storage
because of what looks like an over-eager incompatibility verdict. The correct
outcome is that these capable devices keep using secure storage.
Environment
Reproduction
SecureCredentialsManager.saveCredentials().CredentialsManagerExceptionwithisDeviceIncompatible() == true.(Not reproducible on a Pixel 7a on our side — appears intermittent / device-dependent.)
Additional context
No response
Auth0.Android version
3.16.0
Android version(s)
16 and others