github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-07 19:39:41 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

[PR #3234] [PM-7963] Fix vault timeout immediately on Android Fido2 autofill #10252

New Issue
Closed
opened 2026-04-11 02:39:01 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-11 02:39:01 -05:00
Owner
Copy Link

Original Pull Request: https://github.com/bitwarden/android/pull/3234

State: closed
Merged: No

Type of change

  • Bug fix
  • New feature development
  • Tech debt (refactoring, code cleanup, dependency upgrades, etc)
  • Build/deploy pipeline (DevOps)
  • Other

Objective

Fix vault timeout immediately on Android Fido2 autofill, where it was locking immediately after user unlocks because changing activity

Code changes

  • CredentialProviderSelectionActivity: Changed NoHistory to false so we can launch the MainActivity and return to this one. Added the activity launcher so we can launch MainActivity to unlock the vault after the user selects the cipher to autofill which confirms unlock on the callback.
  • Fido2GetAssertionUserInterface: Added _unlockVaultTcs so we can await until the user unlocks on immediate timeout vaults to ensure vault is unlocked for the Fido2 flow.
  • DeviceActionService: Added a new CredentialProviderConstants.Fido2CredentialNeedsUnlockingAgainBecauseImmediateTimeout to have a way to know after unlocking that is because of this scenario and then set the result back. Here a caveat is that we set vaultTimeoutService.DelayLockAndLogoutMs in order to maintain a time window of the vault unlocked for this flow. Otherwise it'll be immediately locked after the MainActivity is finished.

Before you submit

  • Please check for formatting errors (dotnet format --verify-no-changes) (required)
  • Please add unit tests where it makes sense to do so (encouraged but not required)
  • If this change requires a documentation update - notify the documentation team
  • If this change has particular deployment requirements - notify the DevOps team
**Original Pull Request:** https://github.com/bitwarden/android/pull/3234 **State:** closed **Merged:** No --- ## Type of change - [X] Bug fix - [ ] New feature development - [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc) - [ ] Build/deploy pipeline (DevOps) - [ ] Other ## Objective <!--Describe what the purpose of this PR is. For example: what bug you're fixing or what new feature you're adding--> Fix vault timeout immediately on Android Fido2 autofill, where it was locking immediately after user unlocks because changing activity ## Code changes <!--Explain the changes you've made to each file or major component. This should help the reviewer understand your changes--> <!--Also refer to any related changes or PRs in other repositories--> * **CredentialProviderSelectionActivity:** Changed `NoHistory` to `false` so we can launch the `MainActivity` and return to this one. Added the activity launcher so we can launch `MainActivity` to unlock the vault after the user selects the cipher to autofill which confirms unlock on the callback. * **Fido2GetAssertionUserInterface:** Added `_unlockVaultTcs` so we can await until the user unlocks on immediate timeout vaults to ensure vault is unlocked for the Fido2 flow. * **DeviceActionService:** Added a new `CredentialProviderConstants.Fido2CredentialNeedsUnlockingAgainBecauseImmediateTimeout` to have a way to know after unlocking that is because of this scenario and then set the result back. Here a caveat is that we set `vaultTimeoutService.DelayLockAndLogoutMs` in order to maintain a time window of the vault unlocked for this flow. Otherwise it'll be immediately locked after the `MainActivity` is finished. ## Before you submit - Please check for formatting errors (`dotnet format --verify-no-changes`) (required) - Please add **unit tests** where it makes sense to do so (encouraged but not required) - If this change requires a **documentation update** - notify the documentation team - If this change has particular **deployment requirements** - notify the DevOps team
GiteaMirror added the pull-request label 2026-04-11 02:39:01 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#10252
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?