fix(passkeys): harden Android 12 compatibility - #141
Open
pando85 wants to merge 16 commits into
Open
Conversation
|
✅ Fix pushed: Fixed and pushed to Root cause: Fix: Replaced the bundle with the individual JVM-compatible test dependencies ( |
|
⏸️ CI Auto-Fix paused A user commit was detected after an automated fix. CI auto-fix is now paused To resume CI auto-fix, use the |
![forkline-dev[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
…lectric and kotlin.test
…atformCompatibilityTest The test hardcoded 'app.passwordstore.passkeys.*' for component names but the applicationId is 'app.passwordstore.pando85', so merged manifest resolves relative names to 'app.passwordstore.pando85.passkeys.*'.
… PasskeyPlatformCompatibilityTest Robolectric cannot load AppPasskeyCredentialProviderService because its base class CredentialProviderService requires API 34. Switch to verifying the R.bool.isAtLeastU resource value as the primary check, with optional component enabled-state verification when Robolectric can resolve them.
Use ApplicationProvider.getApplicationContext() instead of RuntimeEnvironment.getApplication() to properly access resources in Robolectric tests. Add androidx.test:core dependency.
Replace direct R.bool.isAtLeastU resource access with Build.VERSION.SDK_INT comparison. Robolectric 4.16.1 cannot resolve app resources with compileSdk 37, causing Resources. The component enabled state check still validates the manifest configuration driven by the isAtLeastU resource.
The :format:common module is a pure JVM module but used libs.bundles.testDependencies which includes androidx.test:core:1.6.1. This pulls in androidx.tracing:tracing:1.1.0 (AAR) which cannot be resolved in a JVM module, causing CI failure. Replace the bundle with JVM-compatible test deps (junit, kotlin-test).
pando85
force-pushed
the
android-12-passkey-compat
branch
from
August 30, 2026 09:56
a660e47 to
b05a0a4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make the passkey integration safe and explicit on Android versions below Android 14 while preserving the existing Android 14+ Credential Manager provider behavior.
The application itself already supports Android 12 (
minSdk = 26). The important platform boundary is passkeys: Android only exposes the third-partyCredentialProviderServiceintegration starting at API 34 (Android 14). Android 12 / API 31 therefore cannot register Android Password Store as the OS passkey provider through the public Credential Manager provider API.Changes
AppPasskeyProviderActivitywith the same@bool/isAtLeastUresource already used byAppPasskeyCredentialProviderServiceAndroid 12 behavior
What remains available on Android 12:
passless/ soft-fido2 representationWhat is not possible through Android's public APIs on Android 12:
The existing
PasskeyAutofillHelpercannot bridge this gap: an Autofill dataset can surface/fill account data, but it does not expose the Credential Manager provider request containing the WebAuthn ceremony context needed by the current provider implementation.True APS-backed passkey ceremonies on Android 12 would require a separate integration outside the Android Credential Manager provider API (for example a browser-specific WebAuthn integration or a CTAP2 transport). That is a substantially different feature and should not be represented as an Autofill fallback.
Validation
The existing PR workflow runs:
spotlessCheckassembleDebugvalidates the merged manifest on the Android-12-compatible application configuration. The provider service was already protected by the API-34 resource gate; this change applies the same gate to its companion activity.