github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-07-21 00:33:17 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #6898] Biometric unlock setup fails on EMUI 12 (Huawei proprietary HAL) after 2026.4.0 SDK unlock refactor #109420

New Issue
Closed
opened 2026-06-06 04:28:21 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-06-06 04:28:21 -05:00
Owner
Copy Link
Copy Source

Originally created by @CrayCJ on GitHub (May 9, 2026).
Original GitHub issue: https://github.com/bitwarden/android/issues/6898

Steps To Reproduce

  1. Install Bitwarden 2026.4.0 fresh (or reinstall after previous installation).
  2. Log in with master password and 2FA.
  3. Navigate to Settings → Account Security.
  4. Observe that "Unlock with biometrics" is grayed out with the message: "Unlock with biometrics requires strong biometric authentication and is not compatible with the biometrics options available on this device."

Workaround that reveals the bug:

  1. Uninstall Bitwarden 2026.4.0.
  2. Install Bitwarden 2025.1.0 (F-Droid build 19622).
  3. Log in, navigate to Settings → Account Security, enable "Unlock with biometrics" — this succeeds.
  4. Update to 2026.4.0 via F-Droid.
  5. Biometric unlock continues to function correctly for vault access.
  6. However, the toggle in Settings → Account Security is now grayed out with the same incompatibility message as in step 4 above — even though biometrics are actively working.

Expected Result

On a device with Class 3 hardware biometrics that previously supported biometric unlock in older Bitwarden versions, the option should remain available and the toggle should reflect the actual active state. At minimum, if biometric authentication works (as demonstrated by the workaround), the settings UI should not indicate incompatibility.

Actual Result

Two separate failure modes:

1. Fresh install on 2026.4.0: The biometric unlock option is grayed out and cannot be enabled at all. The new SDK-based unlock service introduced in the 2026.3/2026.4 cycle calls canAuthenticate(BIOMETRIC_STRONG) via the Bitwarden Rust SDK's Android verifier (bitwarden_uniffi::android_support), which returns a non-success code on this device.

2. After workaround (key created on 2025.1.0, then updated to 2026.4.0): Biometric unlock works correctly for vault access, but the settings toggle is grayed out with the incompatibility message. This indicates that the setup/availability check and the actual authentication path are now decoupled: the setup check (canAuthenticate(BIOMETRIC_STRONG)) fails, while the runtime authentication against the existing Android Keystore key succeeds.

Screenshots or Videos

No response

Additional Context

I used Claude AI to troubleshoot this issue which led to the workaround above. I then instructed Claude to write up its findings for this bug report:

Root cause analysis via ADB diagnostics:
The device uses Huawei's proprietary biometric HAL instead of the standard Android BiometricService:

  • vendor.huawei.hardware.biometrics.fingerprint@2.2-service
  • vendor.huawei.hardware.biometrics.hwfacerecognize@2.0-service

Running adb shell dumpsys biometric returns empty output, confirming that no standard Android BiometricService is present. This means canAuthenticate(BIOMETRIC_STRONG) queries a service that does not respond as expected, causing the new SDK-based unlock service to treat the device as incompatible.

Why it worked before the regression: Prior to the "Refactor unlock service to use Bitwarden SDK" change, Bitwarden used the AndroidX BiometricManager compatibility library, which contains device-specific workarounds for known non-standard biometric HAL implementations (including older Huawei/EMUI devices). The new native Rust SDK implementation does not appear to apply these workarounds.

Why banking apps work but Bitwarden setup doesn't: Other apps using biometrics (e.g. banking apps) call BiometricPrompt without a CryptoObject — simple identity verification. Bitwarden requires BiometricPrompt with a CryptoObject (hardware-backed Keystore key), which is the BIOMETRIC_STRONG path. The Keystore authentication itself succeeds once the key exists; only the availability check via the new SDK fails.

Also noted in ADB logcat during device unlock:

W keystore: permission add_auth denied for 5520
W keystore: addAuthToken: permission denied for 5520

This suggests the Huawei biometric HAL process is denied permission to add auth tokens to the Android Keystore — further evidence of the non-standard integration between Huawei's proprietary biometric stack and the standard Android Keystore/BiometricManager APIs.

Suggested fix directions:

  • Apply the same device/HAL-specific fallback logic that AndroidX BiometricManager uses, within the SDK's Android verifier.
  • Or: decouple the settings UI availability check from the SDK's strict canAuthenticate result when an existing valid biometric Keystore key is present and functional.

Build Version

2026.4.0 (21434)

What server are you connecting to?

Self-host

Self-host Server Version

Vaultwarden Web 2026.4.1 (1.36.0)
EDIT: Issue also recreated with bitwarden.com account: On my device with app version 2026.4.0 (21434), the biometrics option is grayed out, eventhough it has class 3 biometrics available. But the workaround found does not work, as logins with the older app version 2025.1.0 (19622) seem to be rejected by the server ("an error occured, try again"). This suggests that the issue is not connected to the server, but the workaround seems to be.

Environment Details

Device: Huawei Mate 20 Pro (LYA-L29)
OS: EMUI 12.0.0 (Android 10, API 29)
Biometric hardware: Class 3 fingerprint sensor + 3D face unlock (Huawei proprietary HAL)
Bitwarden source: F-Droid
Google Play Services: present

Issue Tracking Info

  • I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
Originally created by @CrayCJ on GitHub (May 9, 2026). Original GitHub issue: https://github.com/bitwarden/android/issues/6898 ### Steps To Reproduce 1. Install Bitwarden 2026.4.0 fresh (or reinstall after previous installation). 2. Log in with master password and 2FA. 3. Navigate to Settings → Account Security. 4. Observe that "Unlock with biometrics" is grayed out with the message: "_Unlock with biometrics requires strong biometric authentication and is not compatible with the biometrics options available on this device._" **Workaround that reveals the bug:** 1. Uninstall Bitwarden 2026.4.0. 2. Install Bitwarden 2025.1.0 (F-Droid build 19622). 3. Log in, navigate to Settings → Account Security, enable "Unlock with biometrics" — this succeeds. 4. Update to 2026.4.0 via F-Droid. 5. Biometric unlock continues to function correctly for vault access. 6. However, the toggle in Settings → Account Security is now grayed out with the same incompatibility message as in step 4 above — even though biometrics are actively working. ### Expected Result On a device with Class 3 hardware biometrics that previously supported biometric unlock in older Bitwarden versions, the option should remain available and the toggle should reflect the actual active state. At minimum, if biometric authentication works (as demonstrated by the workaround), the settings UI should not indicate incompatibility. ### Actual Result Two separate failure modes: **1. Fresh install on 2026.4.0:** The biometric unlock option is grayed out and cannot be enabled at all. The new SDK-based unlock service introduced in the 2026.3/2026.4 cycle calls `canAuthenticate(BIOMETRIC_STRONG)` via the Bitwarden Rust SDK's Android verifier (`bitwarden_uniffi::android_support`), which returns a non-success code on this device. **2. After workaround (key created on 2025.1.0, then updated to 2026.4.0):** Biometric unlock works correctly for vault access, but the settings toggle is grayed out with the incompatibility message. This indicates that the setup/availability check and the actual authentication path are now decoupled: the setup check (`canAuthenticate(BIOMETRIC_STRONG)`) fails, while the runtime authentication against the existing Android Keystore key succeeds. ### Screenshots or Videos _No response_ ### Additional Context _I used Claude AI to troubleshoot this issue which led to the workaround above. I then instructed Claude to write up its findings for this bug report:_ **Root cause analysis via ADB diagnostics:** The device uses Huawei's proprietary biometric HAL instead of the standard Android BiometricService: - `vendor.huawei.hardware.biometrics.fingerprint@2.2-service` - `vendor.huawei.hardware.biometrics.hwfacerecognize@2.0-service` Running `adb shell dumpsys` biometric returns **empty output**, confirming that no standard Android BiometricService is present. This means `canAuthenticate(BIOMETRIC_STRONG)` queries a service that does not respond as expected, causing the new SDK-based unlock service to treat the device as incompatible. **Why it worked before the regression:** Prior to the "Refactor unlock service to use Bitwarden SDK" change, Bitwarden used the AndroidX `BiometricManager` compatibility library, which contains device-specific workarounds for known non-standard biometric HAL implementations (including older Huawei/EMUI devices). The new native Rust SDK implementation does not appear to apply these workarounds. **Why banking apps work but Bitwarden setup doesn't:** Other apps using biometrics (e.g. banking apps) call `BiometricPrompt` without a `CryptoObject` — simple identity verification. Bitwarden requires `BiometricPrompt` with a `CryptoObject` (hardware-backed Keystore key), which is the BIOMETRIC_STRONG path. The Keystore authentication itself succeeds once the key exists; only the availability check via the new SDK fails. **Also noted in ADB logcat during device unlock:** ``` W keystore: permission add_auth denied for 5520 W keystore: addAuthToken: permission denied for 5520 ``` This suggests the Huawei biometric HAL process is denied permission to add auth tokens to the Android Keystore — further evidence of the non-standard integration between Huawei's proprietary biometric stack and the standard Android Keystore/BiometricManager APIs. **Suggested fix directions:** - Apply the same device/HAL-specific fallback logic that AndroidX `BiometricManager` uses, within the SDK's Android verifier. - Or: decouple the settings UI availability check from the SDK's strict `canAuthenticate` result when an existing valid biometric Keystore key is present and functional. ### Build Version 2026.4.0 (21434) ### What server are you connecting to? Self-host ### Self-host Server Version Vaultwarden Web 2026.4.1 (1.36.0) **EDIT: Issue also recreated with bitwarden.com account: On my device with app version 2026.4.0 (21434), the biometrics option is grayed out, eventhough it has class 3 biometrics available. But the workaround found does not work, as logins with the older app version 2025.1.0 (19622) seem to be rejected by the server ("an error occured, try again"). This suggests that the issue is not connected to the server, but the workaround seems to be.** ### Environment Details Device: Huawei Mate 20 Pro (LYA-L29) OS: EMUI 12.0.0 (Android 10, API 29) Biometric hardware: Class 3 fingerprint sensor + 3D face unlock (Huawei proprietary HAL) Bitwarden source: F-Droid Google Play Services: present ### Issue Tracking Info - [x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
GiteaMirror added the app:password-managerbug labels 2026-06-06 04:28:21 -05:00
GiteaMirror commented 2026-06-06 04:28:25 -05:00
Author
Owner
Copy Link
Copy Source

@bitwarden-bot commented on GitHub (May 9, 2026):

Thank you for your report! We've added this to our internal board for review.
ID: PM-36981

<!-- gh-comment-id:4413902660 --> @bitwarden-bot commented on GitHub (May 9, 2026): Thank you for your report! We've added this to our internal board for review. ID: [PM-36981](https://bitwarden.atlassian.net/browse/PM-36981) [PM-36981]: https://bitwarden.atlassian.net/browse/PM-36981?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
GiteaMirror commented 2026-06-06 04:28:26 -05:00
Author
Owner
Copy Link
Copy Source

@pamperer562580892423 commented on GitHub (May 10, 2026):

Self-host Server Version
Vaultwarden Web 2026.4.1

Vaultwarden server version 1.36.0 then, I guess?

<!-- gh-comment-id:4415328995 --> @pamperer562580892423 commented on GitHub (May 10, 2026): > Self-host Server Version > Vaultwarden Web 2026.4.1 Vaultwarden server version 1.36.0 then, I guess?
GiteaMirror commented 2026-06-06 04:28:28 -05:00
Author
Owner
Copy Link
Copy Source

@CrayCJ commented on GitHub (May 10, 2026):

Self-host Server Version
Vaultwarden Web 2026.4.1

Vaultwarden server version 1.36.0 then, I guess?

Yes, 1.36.0. Sorry, for not clarifying that. I added this info to the bug report above.

<!-- gh-comment-id:4415337301 --> @CrayCJ commented on GitHub (May 10, 2026): > > Self-host Server Version > > Vaultwarden Web 2026.4.1 > > Vaultwarden server version 1.36.0 then, I guess? Yes, 1.36.0. Sorry, for not clarifying that. I added this info to the bug report above.
GiteaMirror commented 2026-06-06 04:28:29 -05:00
Author
Owner
Copy Link
Copy Source

@pamperer562580892423 commented on GitHub (May 10, 2026):

I really don't know how accurate the Claude AI analysis is... but can you reproduce this issue whit a BW cloud account?

<!-- gh-comment-id:4415406798 --> @pamperer562580892423 commented on GitHub (May 10, 2026): I really don't know how accurate the Claude AI analysis is... but can you reproduce this issue whit a BW cloud account?
GiteaMirror commented 2026-06-06 04:28:32 -05:00
Author
Owner
Copy Link
Copy Source

@rmcdowell-bitwarden commented on GitHub (May 11, 2026):

Hi there,

It is important to note that Vaultwarden is not associated with Bitwarden. Vaultwarden is a re-writing of the Bitwarden server code in Rust, that is not contributed to nor supported by the Bitwarden team or organization. The security audits granted to Bitwarden do not apply to Vaultwarden, and the Bitwarden support team is not able to respond to questions regarding Vaultwarden. Support options for Vaultwarden are found here:

https://github.com/dani-garcia/vaultwarden?tab=readme-ov-file#get-in-touch

Please only report issues on Bitwarden's repositories when you are able to reproduce the behavior with an official Bitwarden server (cloud or self-hosted).

You can find information about using Bitwarden's self-hosted servers here: https://bitwarden.com/help/self-host-bitwarden/

This issue will now be closed.

Thanks!

<!-- gh-comment-id:4417085764 --> @rmcdowell-bitwarden commented on GitHub (May 11, 2026): Hi there, It is important to note that Vaultwarden is not associated with Bitwarden. Vaultwarden is a re-writing of the Bitwarden server code in Rust, that is not contributed to nor supported by the Bitwarden team or organization. The security audits granted to Bitwarden do not apply to Vaultwarden, and the Bitwarden support team is not able to respond to questions regarding Vaultwarden. Support options for Vaultwarden are found here: https://github.com/dani-garcia/vaultwarden?tab=readme-ov-file#get-in-touch Please only report issues on Bitwarden's repositories when you are able to reproduce the behavior with an official Bitwarden server (cloud or self-hosted). You can find information about using Bitwarden's self-hosted servers here: https://bitwarden.com/help/self-host-bitwarden/ This issue will now be closed. Thanks!
GiteaMirror commented 2026-06-06 04:28:34 -05:00
Author
Owner
Copy Link
Copy Source

@sw5ciprl commented on GitHub (May 14, 2026):

I believe that the server used here isn't relevant, as the change comes from client-side APIs. Maybe this should be reopened? @rmcdowell-bitwarden

<!-- gh-comment-id:4454526839 --> @sw5ciprl commented on GitHub (May 14, 2026): I believe that the server used here isn't relevant, as the change comes from client-side APIs. Maybe this should be reopened? @rmcdowell-bitwarden
GiteaMirror commented 2026-06-06 04:28:35 -05:00
Author
Owner
Copy Link
Copy Source

@CrayCJ commented on GitHub (May 16, 2026):

@sw5ciprl:

I really don't know how accurate the Claude AI analysis is... but can you reproduce this issue whit a BW cloud account?

Yes: I'm able to recreate my issue with bitwarden.com account: On my device with app version 2026.4.0 (21434), the biometrics option is grayed out, eventhough it has class 3 biometrics available. But the workaround found does not work, as logins with the older app version 2025.1.0 (19622) seem to be rejected by the server ("an error occured, try again"). This suggests that the issue is not connected to the server, but the workaround seems to be. I added this info to the initial bug report. I also don't know, how accurate Claude is in this, I just wanted to provide all info I have and be helpful.

Whether this issue is addressed, is up to you, @rmcdowell-bitwarden. With Vaultwarden, the workaround works.

<!-- gh-comment-id:4468331556 --> @CrayCJ commented on GitHub (May 16, 2026): @sw5ciprl: > I really don't know how accurate the Claude AI analysis is... but can you reproduce this issue whit a BW cloud account? **Yes: I'm able to recreate my issue with bitwarden.com account:** On my device with app version 2026.4.0 (21434), the biometrics option is grayed out, eventhough it has class 3 biometrics available. But the workaround found does not work, as logins with the older app version 2025.1.0 (19622) seem to be rejected by the server ("an error occured, try again"). This suggests that the issue is not connected to the server, but the workaround seems to be. I added this info to the initial bug report. I also don't know, how accurate Claude is in this, I just wanted to provide all info I have and be helpful. Whether this issue is addressed, is up to you, @rmcdowell-bitwarden. With Vaultwarden, the workaround works.
GiteaMirror commented 2026-06-06 04:28:37 -05:00
Author
Owner
Copy Link
Copy Source

@Cosaque commented on GitHub (May 19, 2026):

Got exactly the same problem.
Used workaround too to temporary resolve.

<!-- gh-comment-id:4492341019 --> @Cosaque commented on GitHub (May 19, 2026): Got exactly the same problem. Used workaround too to temporary resolve.
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 labels app:password-manager bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#109420