github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-06 15:58:22 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #6284] [PM-29960] HyperOS 3 CredentialSelectorActivity crashes with ClassCastException (Long to Integer) #15051

New Issue
Open
opened 2026-04-15 01:21:39 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-15 01:21:39 -05:00
Owner
Copy Link

Originally created by @bbxblue on GitHub (Dec 19, 2025).
Original GitHub issue: https://github.com/bitwarden/android/issues/6284

Origin

Native Application (non-browser app)

Web URL or App name

webauthn.io

Passkey Action

  • Creating new passkey (Registration)
  • Signing in (Authentication)

Build Information

2025.12.0

Additional Information

1. Description:
On Xiaomi 15 (HyperOS 3 CN, Android 16), Bitwarden is unable to complete the Passkey authentication or registration flow when system biometrics (Fingerprint/Face) are enabled. The system's com.android.credentialmanager component crashes immediately upon trying to show the selector UI.

2. Steps to Reproduce:

  1. Use Xiaomi 15 with Fingerprint/Face unlock enabled.
  2. Set Bitwarden as the primary Credential Provider.
  3. Attempt to log in to a website/app using a Passkey stored in Bitwarden.
  4. The system "CredentialSelectorActivity" fails to pop up, and Bitwarden receives a TYPE_NO_CREDENTIAL or cancellation error.

3. Expected Behavior:
The system credential selector should appear, allowing the user to select the Bitwarden credential and authenticate via biometrics.

4. Actual Behavior:
The system component com.android.credentialmanager crashes due to a ClassCastException.

5. Root Cause Analysis (from Logcat):
The crash occurs in the system's biometric pre-validation logic. Android 15 has updated certain SliceItem fields to Long, but Xiaomi's CredentialSelectorActivity implementation still calls getInt(), causing a type mismatch.

6. Supporting Logcat Trace:

E CredentialSelectorActivity: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
E CredentialSelectorActivity:    at android.app.slice.SliceItem.getInt(SliceItem.java:238)
E CredentialSelectorActivity:    at com.android.credentialmanager.ktx.CredentialKtxKt.predetermineAndValidateBiometricFlow(CredentialKtx.kt:98)
E CredentialSelectorActivity:    at com.android.credentialmanager.ktx.CredentialKtxKt.getCredentialOptionInfoList(CredentialKtx.kt:307)
E CredentialSelectorActivity:    at com.android.credentialmanager.ktx.CredentialKtxKt.toProviderList(CredentialKtx.kt:122)
E CredentialSelectorActivity:    at com.android.credentialmanager.CredentialSelectorActivity.onCreate(CredentialSelectorActivity.kt:91)

7. Critical Finding:
Disabling all system biometrics (removing fingerprints/face data) resolves the crash, and the Bitwarden selector UI appears correctly.

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 @bbxblue on GitHub (Dec 19, 2025). Original GitHub issue: https://github.com/bitwarden/android/issues/6284 ### Origin Native Application (non-browser app) ### Web URL or App name webauthn.io ### Passkey Action - [ ] Creating new passkey (Registration) - [x] Signing in (Authentication) ### Build Information 2025.12.0 ### Additional Information **1. Description:** On Xiaomi 15 (HyperOS 3 CN, Android 16), Bitwarden is unable to complete the Passkey authentication or registration flow when system biometrics (Fingerprint/Face) are enabled. The system's `com.android.credentialmanager` component crashes immediately upon trying to show the selector UI. **2. Steps to Reproduce:** 1. Use Xiaomi 15 with Fingerprint/Face unlock enabled. 2. Set Bitwarden as the primary Credential Provider. 3. Attempt to log in to a website/app using a Passkey stored in Bitwarden. 4. The system "CredentialSelectorActivity" fails to pop up, and Bitwarden receives a `TYPE_NO_CREDENTIAL` or cancellation error. **3. Expected Behavior:** The system credential selector should appear, allowing the user to select the Bitwarden credential and authenticate via biometrics. **4. Actual Behavior:** The system component `com.android.credentialmanager` crashes due to a `ClassCastException`. **5. Root Cause Analysis (from Logcat):** The crash occurs in the system's biometric pre-validation logic. Android 15 has updated certain `SliceItem` fields to `Long`, but Xiaomi's `CredentialSelectorActivity` implementation still calls `getInt()`, causing a type mismatch. **6. Supporting Logcat Trace:** ```text E CredentialSelectorActivity: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer E CredentialSelectorActivity: at android.app.slice.SliceItem.getInt(SliceItem.java:238) E CredentialSelectorActivity: at com.android.credentialmanager.ktx.CredentialKtxKt.predetermineAndValidateBiometricFlow(CredentialKtx.kt:98) E CredentialSelectorActivity: at com.android.credentialmanager.ktx.CredentialKtxKt.getCredentialOptionInfoList(CredentialKtx.kt:307) E CredentialSelectorActivity: at com.android.credentialmanager.ktx.CredentialKtxKt.toProviderList(CredentialKtx.kt:122) E CredentialSelectorActivity: at com.android.credentialmanager.CredentialSelectorActivity.onCreate(CredentialSelectorActivity.kt:91) ``` **7. Critical Finding:** **Disabling all system biometrics (removing fingerprints/face data) resolves the crash**, and the Bitwarden selector UI appears correctly. ### 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 bug-passkeyapp:password-manager labels 2026-04-15 01:21:39 -05:00
GiteaMirror commented 2026-04-15 01:21:41 -05:00
Author
Owner
Copy Link

@bitwarden-bot commented on GitHub (Dec 19, 2025):

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

<!-- gh-comment-id:3674072820 --> @bitwarden-bot commented on GitHub (Dec 19, 2025): Thank you for your report! We've added this to our internal board for review. ID: [PM-29960](https://bitwarden.atlassian.net/browse/PM-29960) [PM-29960]: https://bitwarden.atlassian.net/browse/PM-29960?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
GiteaMirror commented 2026-04-15 01:21:41 -05:00
Author
Owner
Copy Link

@Adedamola-Aina commented on GitHub (Dec 23, 2025):

Hello @bbxblue

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, We use GitHub issues as a place to track bugs and other development related issues. If your issue persists, please write us back using our “Contact support” form located on our Help Center (https://bitwarden.com/help/).
You can include a link to this issue in the message content.
Alternatively, you can also search for an answer in our help documentation or get help from other Bitwarden users on our community forums (https://community.bitwarden.com/c/support/).

<!-- gh-comment-id:3685717575 --> @Adedamola-Aina commented on GitHub (Dec 23, 2025): Hello @bbxblue I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, We use GitHub issues as a place to track bugs and other development related issues. If your issue persists, please write us back using our “Contact support” form located on our Help Center (https://bitwarden.com/help/). You can include a link to this issue in the message content. Alternatively, you can also search for an answer in our help documentation or get help from other Bitwarden users on our community forums (https://community.bitwarden.com/c/support/).
GiteaMirror commented 2026-04-15 01:21:42 -05:00
Author
Owner
Copy Link

@Gavin-Guiii commented on GitHub (Jan 2, 2026):

Hello @bbxblue

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, We use GitHub issues as a place to track bugs and other development related issues. If your issue persists, please write us back using our “Contact support” form located on our Help Center (https://bitwarden.com/help/). You can include a link to this issue in the message content. Alternatively, you can also search for an answer in our help documentation or get help from other Bitwarden users on our community forums (https://community.bitwarden.com/c/support/).

Hello @Adedamola-Aina ,

I did some further testing and investigation. Could you please forward the following information to the development team? It might help them locate the issue.

AOSP's Credential Manager is using getLong to read the CRYPTO_OP_ID (See Line 252).

Xiaomi somehow decided to implement its own Credential Manager, and the decompiled code suggests that it's using getInt to read the same CRYPTO_OP_ID (See line 371).

So it's causing the java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer exception mentioned in this issue.

One way to quickly fix it is to assume Xiaomi doesn't support Android's integrated biometric prompt in Bitwarden's CredentialEntryBuilderExtensions so Xiaomi's faulty logic will be skipped. Users will still be directed to Bitwarden app to do authentication so there's not a big UX difference. Alternatively, maybe we can add a Biometrics Compatibility Mode settings somewhere in the Bitwarden app?

Totally understand this is completely Xiaomi's fault but they refuse to acknowledge and fix the issue. But considering Xiaomi has a ~15% marketshare globally, maybe it wouldn't hurt for Bitwarden to do a patch for Xiaomi devices? If the team is busy with other tasks, I can also do a quick PR to patch this up but please let me know which way the team would like to proceed with. It would significantly benefit all Xiaomi users.

By the way, Proton Pass is working fine because they didn't implement Android's BiometricPrompt.

<!-- gh-comment-id:3705618623 --> @Gavin-Guiii commented on GitHub (Jan 2, 2026): > Hello [@bbxblue](https://github.com/bbxblue) > > I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, We use GitHub issues as a place to track bugs and other development related issues. If your issue persists, please write us back using our “Contact support” form located on our Help Center (https://bitwarden.com/help/). You can include a link to this issue in the message content. Alternatively, you can also search for an answer in our help documentation or get help from other Bitwarden users on our community forums (https://community.bitwarden.com/c/support/). Hello @Adedamola-Aina , I did some further testing and investigation. Could you please forward the following information to the development team? It might help them locate the issue. [AOSP's Credential Manager](https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/main/packages/CredentialManager/shared/src/com/android/credentialmanager/ktx/CredentialKtx.kt#252) is using `getLong` to read the `CRYPTO_OP_ID` (See Line 252). Xiaomi somehow decided to implement its own Credential Manager, and [the decompiled code](https://github.com/user-attachments/files/24409171/CredentialKtxKt.java) suggests that it's using `getInt` to read the same `CRYPTO_OP_ID` (See line 371). So it's causing the `java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer` exception mentioned in this issue. One way to quickly fix it is to assume Xiaomi doesn't support Android's integrated biometric prompt in Bitwarden's [CredentialEntryBuilderExtensions](https://github.com/bitwarden/android/blob/674cde9869b0c5f95d881916911798df9a37c943/app/src/main/kotlin/com/x8bit/bitwarden/data/credentials/util/CredentialEntryBuilderExtensions.kt#L18) so Xiaomi's faulty logic will be skipped. Users will still be directed to Bitwarden app to do authentication so there's not a big UX difference. Alternatively, maybe we can add a `Biometrics Compatibility Mode` settings somewhere in the Bitwarden app? Totally understand this is completely Xiaomi's fault but they refuse to acknowledge and fix the issue. But considering Xiaomi has a ~15% marketshare globally, maybe it wouldn't hurt for Bitwarden to do a patch for Xiaomi devices? If the team is busy with other tasks, I can also do a quick PR to patch this up but please let me know which way the team would like to proceed with. It would significantly benefit all Xiaomi users. By the way, Proton Pass is working fine because they didn't implement Android's [BiometricPrompt](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt).
GiteaMirror commented 2026-04-15 01:21:43 -05:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (Jan 6, 2026):

Hi @Gavin-Guiii

Thanks for the extra research and details. It has been very helpful. Question for you since I don't have access to a Xiaomi device; does the default biometric prompt still work as expected to unlock your vault and phone, or are all biometric prompts broken on Xiaomi devices? That will drive how we decide to address the issue.

<!-- gh-comment-id:3715669104 --> @SaintPatrck commented on GitHub (Jan 6, 2026): Hi @Gavin-Guiii Thanks for the extra research and details. It has been very helpful. Question for you since I don't have access to a Xiaomi device; does the default biometric prompt still work as expected to unlock your vault and phone, or are **all** biometric prompts broken on Xiaomi devices? That will drive how we decide to address the issue.
GiteaMirror commented 2026-04-15 01:21:44 -05:00
Author
Owner
Copy Link

@Gavin-Guiii commented on GitHub (Jan 6, 2026):

Hi @Gavin-Guiii

Thanks for the extra research and details. It has been very helpful. Question for you since I don't have access to a Xiaomi device; does the default biometric prompt still work as expected to unlock your vault and phone, or are all biometric prompts broken on Xiaomi devices? That will drive how we decide to address the issue.

Hi,

Thanks for getting back to me.

All the other prompts still work as expected. The issue only happens when we setBiometricPromptData on PublicKeyCredentialEntry.Builder.

Sorry I just realized I made a typo in my previous comment. What I meant to say is BiometricPromptData (not BiometricPrompt) is causing the issue. Proton Pass didn't use this so it's working on Xiaomi devices, but Bitwarden has implemented it here.

Kudos to Bitwarden for using this new Android API though. It's working perfectly on my other Android phones. Xiaomi just had to change it and break it.

Thanks again for taking your time to look into this issue. We wouldn't bother you guys if we had other options. I heard someone who even complained this bug to the chinese government but Xiaomi still refused to fix it...

<!-- gh-comment-id:3715724934 --> @Gavin-Guiii commented on GitHub (Jan 6, 2026): > Hi [@Gavin-Guiii](https://github.com/Gavin-Guiii) > > Thanks for the extra research and details. It has been very helpful. Question for you since I don't have access to a Xiaomi device; does the default biometric prompt still work as expected to unlock your vault and phone, or are **all** biometric prompts broken on Xiaomi devices? That will drive how we decide to address the issue. Hi, Thanks for getting back to me. All the other prompts still work as expected. The issue only happens when we `setBiometricPromptData` on `PublicKeyCredentialEntry.Builder`. Sorry I just realized I made a typo in my previous comment. What I meant to say is [BiometricPromptData](https://developer.android.com/reference/kotlin/androidx/credentials/provider/BiometricPromptData) (not `BiometricPrompt`) is causing the issue. Proton Pass didn't use this so it's working on Xiaomi devices, but Bitwarden has implemented it [here](https://github.com/bitwarden/android/blob/a8ef32ae761d3337e5502b398fe1d613b0844e80/app/src/main/kotlin/com/x8bit/bitwarden/data/credentials/util/CredentialEntryBuilderExtensions.kt#L19). Kudos to Bitwarden for using this new Android API though. It's working perfectly on my other Android phones. Xiaomi just had to change it and break it. Thanks again for taking your time to look into this issue. We wouldn't bother you guys if we had other options. I heard someone who even complained this bug to the chinese government but Xiaomi still refused to fix it...
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 app:password-manager bug-passkey
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#15051
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?