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

[GH-ISSUE #6164] [PM-28157] Passkey error with Revolut app: 'Passkeys not supported for this app' #15017

New Issue
Open
opened 2026-04-15 01:18:06 -05:00 by GiteaMirror · 17 comments
GiteaMirror commented 2026-04-15 01:18:06 -05:00
Owner
Copy Link

Originally created by @samuele-ruffino96 on GitHub (Nov 13, 2025).
Original GitHub issue: https://github.com/bitwarden/android/issues/6164

Origin

Native Application (non-browser app)

Web URL or App name

Revolut (com.revolut.revolut)

Passkey Action

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

Build Information

App Version: 2025.10.1 (20867)
Build: release/standard
Operating System: Android 16 (API 36)
Device: Samsung SM-A566E (Galaxy A56)

Additional Information

Related Issue:
This appears similar to #6111, which was closed due to insufficient reproduction information.
I'm providing detailed logs, screenshots, and device information to help investigate this issue.

Steps to reproduce:

  1. Open Revolut app (com.revolut.revolut)
  2. Attempt to create a passkey
  3. Bitwarden autofill appears
  4. Error dialog displays: "An error has occurred - Passkeys not supported for this app"

Observations:

  • Digital Asset Links verification succeeds (200 response)
  • Revolut's certificate fingerprint is correctly verified
  • Bitwarden autofill service processes the request (request ID 2254)
  • Despite successful verification, passkey operation fails

Attached:

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 @samuele-ruffino96 on GitHub (Nov 13, 2025). Original GitHub issue: https://github.com/bitwarden/android/issues/6164 ### Origin Native Application (non-browser app) ### Web URL or App name Revolut (com.revolut.revolut) ### Passkey Action - [x] Creating new passkey (Registration) - [ ] Signing in (Authentication) ### Build Information App Version: 2025.10.1 (20867) Build: release/standard Operating System: Android 16 (API 36) Device: Samsung SM-A566E (Galaxy A56) ### Additional Information **Related Issue:** This appears similar to #6111, which was closed due to insufficient reproduction information. I'm providing detailed logs, screenshots, and device information to help investigate this issue. **Steps to reproduce:** 1. Open Revolut app (com.revolut.revolut) 2. Attempt to create a passkey 3. Bitwarden autofill appears 4. Error dialog displays: "An error has occurred - Passkeys not supported for this app" **Observations:** - Digital Asset Links verification succeeds (200 response) - Revolut's certificate fingerprint is correctly verified - Bitwarden autofill service processes the request (request ID 2254) - Despite successful verification, passkey operation fails **Attached:** - Screenshot of error dialog ![image](https://github.com/user-attachments/assets/21542ad8-dd3e-4783-b0ae-9cac7efe2598) - Application logs showing the autofill request flow [flight_recorder_2025-11-13_09-40-43.txt](https://github.com/user-attachments/files/23520767/flight_recorder_2025-11-13_09-40-43.txt) ### 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:18:06 -05:00
GiteaMirror commented 2026-04-15 01:18:08 -05:00
Author
Owner
Copy Link

@bitwarden-bot commented on GitHub (Nov 13, 2025):

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

<!-- gh-comment-id:3526623191 --> @bitwarden-bot commented on GitHub (Nov 13, 2025): Thank you for your report! We've added this to our internal board for review. ID: PM-28157
GiteaMirror commented 2026-04-15 01:18:09 -05:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (Nov 13, 2025):

Hi @samuele-ruffino96

The logs do indicate a 200 response, but that only means Google's DAL API successfully processed the request and provided a response. The 200 does not indicate the actual result of validation. When I perform the same API call in Postman, I can see that the response body contains an error. Google's DAL API is receiving a redirect response when attempting to retrieve Revolut's assetlinks.json file. For security reasons the API does not follow redirects.

That being said, I do notice the response indicates Google is calling https://revolut.com. (note the additional . at the end), despite us properly sending https://revolut.com (without the additional .). I have reached out to Google for clarity regarding this behavior. You can track the issue here.

Response from Google's DAL API: 
{
    "maxAge": "599.999999986s",
    "debugString": "********************* ERRORS *********************\n* Error: unavailable: Redirect encountered while fetching statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json'): redirects are disallowed for security reasons (NOT_FOLLOWED_MAX_FORWARDS) [651] while fetching Web statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json') using download from the web (ID 1).\n",
    "errorCode": [
        "ERROR_CODE_REDIRECT"
    ]
}
<!-- gh-comment-id:3528535789 --> @SaintPatrck commented on GitHub (Nov 13, 2025): Hi @samuele-ruffino96 The logs do indicate a 200 response, but that only means Google's DAL API successfully processed the request and provided a response. The 200 does not indicate the actual result of validation. When I perform the same API call in Postman, I can see that the response body contains an error. Google's DAL API is receiving a redirect response when attempting to retrieve Revolut's `assetlinks.json` file. For security reasons the API does not follow redirects. That being said, I do notice the response indicates Google is calling `https://revolut.com.` (note the additional `.` at the end), despite us properly sending `https://revolut.com` (without the additional `.`). I have reached out to Google for clarity regarding this behavior. You can track the issue [here](https://issuetracker.google.com/issues/460172858). <details> <summary>Response from Google's DAL API:</summary> ```json { "maxAge": "599.999999986s", "debugString": "********************* ERRORS *********************\n* Error: unavailable: Redirect encountered while fetching statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json'): redirects are disallowed for security reasons (NOT_FOLLOWED_MAX_FORWARDS) [651] while fetching Web statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json') using download from the web (ID 1).\n", "errorCode": [ "ERROR_CODE_REDIRECT" ] } ``` </details>
GiteaMirror commented 2026-04-15 01:18:12 -05:00
Author
Owner
Copy Link

@samuele-ruffino96 commented on GitHub (Nov 14, 2025):

Hi @SaintPatrck
Thanks for the detailed explanation and for reaching out to Google about this!

You're absolutely right about the redirect. I've confirmed that https://revolut.com/.well-known/assetlinks.json returns a 301 redirect to https://www.revolut.com/.well-known/assetlinks.json. This is why Google's Digital Asset Links API is failing the verification - as you mentioned, it doesn't follow redirects for security reasons.

Regarding the additional . at the end (https://revolut.com.), I tested this as well and it performs the same redirect (see attached screenshot). From what I found, the trailing dot represents the DNS root and it's technically valid - most HTTP clients handle revolut.com. identically to revolut.com.

It's a bit unusual that Google is using the FQDN format but it shouldn't affect the outcome. I believe the core issue is that Revolut needs to serve the file directly without any redirects on either domain.

Curious to hear what Google says!

Image
<!-- gh-comment-id:3533448042 --> @samuele-ruffino96 commented on GitHub (Nov 14, 2025): Hi @SaintPatrck Thanks for the detailed explanation and for reaching out to Google about this! You're absolutely right about the redirect. I've confirmed that `https://revolut.com/.well-known/assetlinks.json` returns a 301 redirect to `https://www.revolut.com/.well-known/assetlinks.json`. This is why Google's Digital Asset Links API is failing the verification - as you mentioned, it doesn't follow redirects for security reasons. Regarding the additional `.` at the end (`https://revolut.com.`), I tested this as well and it performs the same redirect (see attached screenshot). From what I found, the trailing dot represents the DNS root and it's technically valid - most HTTP clients handle `revolut.com.` identically to `revolut.com`. It's a bit unusual that Google is using the FQDN format but it shouldn't affect the outcome. I believe the core issue is that Revolut needs to serve the file directly without any redirects on either domain. Curious to hear what Google says! <img width="1096" height="814" alt="Image" src="https://github.com/user-attachments/assets/1af950ff-f9e4-4cbe-9141-585406e300ab" />
GiteaMirror commented 2026-04-15 01:18:13 -05:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (Nov 20, 2025):

Hi @samuele-ruffino96

We heard back from Google. The absence of www. in the target website is causing a redirect. I have opened a PR that injects www. to hopefully prevent redirects from occurring for Revolut and any other applications that do not host assetlinks.json at their apex domain.

Thanks again for reporting the issue and providing details.

<!-- gh-comment-id:3558043596 --> @SaintPatrck commented on GitHub (Nov 20, 2025): Hi @samuele-ruffino96 We heard back from Google. The absence of `www.` in the target website is causing a redirect. I have opened a PR that injects `www.` to hopefully prevent redirects from occurring for Revolut and any other applications that do not host `assetlinks.json` at their apex domain. Thanks again for reporting the issue and providing details.
GiteaMirror commented 2026-04-15 01:18:13 -05:00
Author
Owner
Copy Link

@Raul6469 commented on GitHub (Nov 21, 2025):

Hi everyone!

May be off topic, but I'm commenting on this issue since I'm encountering the same error message in a somewhat similar situation 👀

While testing our mobile implementation of passkeys, I found out that our app.domain.com. was not working, which is probably why I was getting the error message in Bitwarden. I guess we have to work this out and handle the fully qualified domain to fix Bitwarden compatibility?

Also, on our app, we host the asset links file exclusively on app.domain.com, and is not accessible through www.app.domain.com. The RP ID we use is app.domain.com. I may be mistaken since I'm not familiar with Kotlin, but will #6183 break comptability with our app, by prefixing with www. ? Maybe this injection should only happen on apex domains like domain.com?

<!-- gh-comment-id:3563948536 --> @Raul6469 commented on GitHub (Nov 21, 2025): Hi everyone! May be off topic, but I'm commenting on this issue since I'm encountering the same error message in a somewhat similar situation 👀 While testing our mobile implementation of passkeys, I found out that our `app.domain.com.` was not working, which is probably why I was getting the error message in Bitwarden. I guess we have to work this out and handle the fully qualified domain to fix Bitwarden compatibility? Also, on our app, we host the asset links file exclusively on `app.domain.com`, and is not accessible through `www.app.domain.com`. The RP ID we use is `app.domain.com`. I may be mistaken since I'm not familiar with Kotlin, but will #6183 break comptability with our app, by prefixing with `www.` ? Maybe this injection should only happen on apex domains like `domain.com`?
GiteaMirror commented 2026-04-15 01:18:14 -05:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (Nov 21, 2025):

Hi, @Raul6469.

Not off topic at all. Thank you for chiming in and pointing this out.

You're absolutely right. After taking another look at WebAuthn and Digital Asset Link specs, our strict matching was correct. I've opened a PR to revert the change.

@samuele-ruffino96 unfortunately this means Revolut, and any other applications that are misconfigured, will continue failing. I suggest reaching out to Revolut if you have not already. They will need to host their assetlinks.json file at revolut.com instead of redirecting to www.revolut.com. Alternatively, they can update the RP ID, but that is a destructive change I do not suggest unless no other options are available.

<!-- gh-comment-id:3564635655 --> @SaintPatrck commented on GitHub (Nov 21, 2025): Hi, @Raul6469. Not off topic at all. Thank you for chiming in and pointing this out. You're absolutely right. After taking another look at WebAuthn and Digital Asset Link specs, our strict matching was correct. I've opened a PR to revert the change. @samuele-ruffino96 unfortunately this means Revolut, and any other applications that are misconfigured, will continue failing. I suggest reaching out to Revolut if you have not already. They will need to host their `assetlinks.json` file at `revolut.com` instead of redirecting to `www.revolut.com`. Alternatively, they can update the RP ID, but that is a destructive change I do not suggest unless no other options are available.
GiteaMirror commented 2026-04-15 01:18:15 -05:00
Author
Owner
Copy Link

@samuele-ruffino96 commented on GitHub (Nov 22, 2025):

Contacted Revolut via api-requests@revolut.com (the closest technical contact I've found) about this configuration issue. Will keep the thread updated on their response.

@SaintPatrck Thanks! 👍

<!-- gh-comment-id:3566798444 --> @samuele-ruffino96 commented on GitHub (Nov 22, 2025): Contacted Revolut via api-requests@revolut.com (the closest technical contact I've found) about this configuration issue. Will keep the thread updated on their response. @SaintPatrck Thanks! 👍
GiteaMirror commented 2026-04-15 01:18:15 -05:00
Author
Owner
Copy Link

@Raul6469 commented on GitHub (Nov 24, 2025):

Hi @SaintPatrck !

I have a last question regarding the trailing . on digital asset link requests: is this an Android behaviour, or specific to Bitwarden?

On our existing app, we already host the assetlinks.json file for other purposes than passkeys support, and according to our logs, all requests we currently receive are made without this trailing dot.

When developing our passkey support, it seems like requests on app.domain.com. are only made when trying to use a Bitwarden passkey. Also, google password manager passkeys seem to work fine, which makes me believe there is some sort of Bitwarden specific configuration 👀

<!-- gh-comment-id:3570012412 --> @Raul6469 commented on GitHub (Nov 24, 2025): Hi @SaintPatrck ! I have a last question regarding the trailing `.` on digital asset link requests: is this an Android behaviour, or specific to Bitwarden? On our existing app, we already host the `assetlinks.json` file for other purposes than passkeys support, and according to our logs, all requests we currently receive are made without this trailing dot. When developing our passkey support, it seems like requests on `app.domain.com.` are only made when trying to use a Bitwarden passkey. Also, google password manager passkeys seem to work fine, which makes me believe there is some sort of Bitwarden specific configuration 👀
GiteaMirror commented 2026-04-15 01:18:15 -05:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (Dec 1, 2025):

Hi @Raul6469

Great questions!

The trailing dot is part of the error response message from Google's DAL API (see below). Google is not actually including it when fetching the asset links file, that I can tell. If they are, it's not the cause of the failure.

While using Google's DAL API to verify the calling application's authenticity is Bitwarden specific behavior, Google explicitly recommends providers perform DAL verification as part of the flow.1 Other password managers may have implemented different methods of verifying calling applications, or may not perform verification correctly or at all.

If you see Bitwarden requesting assetlinks.json from https://app.domain.com it is because the Relying Party ID we receive in the passkey request is app.domain.com. Ideally, the RP ID we receive reflects the actual asset link host. That being said, I can't find anything explicitly stating we cannot discard labels from the left of the effective domain, so that may be a more robust solution that doesn't compromise security. I.e., if the RP ID is app.domain.com we attempt to read DAL at https://app.domain.com first, then https://domain.com. I will discuss that approach with the rest of the team and update this thread accordingly.

DAL error response 
{
    "maxAge": "599.999999950s",
    "debugString": "********************* ERRORS *********************\n* Error: unavailable: Redirect encountered while fetching statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json'): redirects are disallowed for security reasons (NOT_FOLLOWED_MAX_FORWARDS) [700] while fetching Web statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json') using download from the web (ID 1).\n",
    "errorCode": [
        "ERROR_CODE_REDIRECT"
    ]
}
<!-- gh-comment-id:3597747358 --> @SaintPatrck commented on GitHub (Dec 1, 2025): Hi @Raul6469 Great questions! The trailing dot is part of the error response message from Google's DAL API (see below). Google is not actually including it when fetching the asset links file, that I can tell. If they are, it's not the cause of the failure. While using Google's DAL API to verify the calling application's authenticity is Bitwarden specific behavior, Google explicitly recommends providers perform DAL verification as part of the flow.[^1] Other password managers may have implemented different methods of verifying calling applications, or may not perform verification correctly or at all. If you see Bitwarden requesting `assetlinks.json` from `https://app.domain.com` it is because the Relying Party ID we receive in the passkey request is `app.domain.com`. Ideally, the RP ID we receive reflects the actual asset link host. That being said, I can't find anything explicitly stating we cannot discard labels from the left of the effective domain, so that may be a more robust solution that doesn't compromise security. I.e., if the RP ID is `app.domain.com` we attempt to read DAL at `https://app.domain.com` first, then `https://domain.com`. I will discuss that approach with the rest of the team and update this thread accordingly. <details> <summary>DAL error response</summary> ```json { "maxAge": "599.999999950s", "debugString": "********************* ERRORS *********************\n* Error: unavailable: Redirect encountered while fetching statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json'): redirects are disallowed for security reasons (NOT_FOLLOWED_MAX_FORWARDS) [700] while fetching Web statements from https://revolut.com./.well-known/assetlinks.json (which is equivalent to 'https://revolut.com/.well-known/assetlinks.json') using download from the web (ID 1).\n", "errorCode": [ "ERROR_CODE_REDIRECT" ] } ``` </details> [^1]: https://developer.android.com/identity/sign-in/credential-provider - Step 6
GiteaMirror commented 2026-04-15 01:18:16 -05:00
Author
Owner
Copy Link

@andyplop9 commented on GitHub (Dec 15, 2025):

This issue also occurs on Facebook.

<!-- gh-comment-id:3655694155 --> @andyplop9 commented on GitHub (Dec 15, 2025): This issue also occurs on Facebook.
GiteaMirror commented 2026-04-15 01:18:17 -05:00
Author
Owner
Copy Link

@RokeJulianLockhart commented on GitHub (Dec 19, 2025):

@andyplop9, and forkgram/TelegramAndroid/issues/360, so this issue's title should be modified.

<!-- gh-comment-id:3676439625 --> @RokeJulianLockhart commented on GitHub (Dec 19, 2025): @andyplop9, and [`forkgram/TelegramAndroid/issues/360`](https://github.com/forkgram/TelegramAndroid/issues/360#issuecomment-3676423074), so this issue's title should be modified.
GiteaMirror commented 2026-04-15 01:18:17 -05:00
Author
Owner
Copy Link

@samuele-ruffino96 commented on GitHub (Dec 24, 2025):

[UPDATE]: Response from Revolut Support Team

After reporting this issue through Revolut's in-app support, here's the response I received:

"Thank you for your patience. I wanted to let you know that I've received confirmation from our tech team regarding the use of third-party password managers with Revolut passkeys. Unfortunately, it is not currently possible to configure a third-party password manager to add your Revolut passkey. However, if this option becomes available in the future, you will be able to set up passkeys with third-party password managers directly through the app."

"Additionally, I've noted your request and forwarded it internally with my team for their consideration in future app improvements."

So the Revolut's team is treating this as a "future improvement" rather than a bug fix 🫤.

@SaintPatrck At this point, should this issue remain open?

<!-- gh-comment-id:3690444490 --> @samuele-ruffino96 commented on GitHub (Dec 24, 2025): [**UPDATE**]: Response from Revolut Support Team After reporting this issue through Revolut's in-app support, here's the response I received: > "Thank you for your patience. I wanted to let you know that I've received confirmation from our tech team regarding the use of third-party password managers with Revolut passkeys. **Unfortunately, it is not currently possible to configure a third-party password manager to add your Revolut passkey.** However, if this option becomes available in the future, you will be able to set up passkeys with third-party password managers directly through the app." > "Additionally, I've noted your request and forwarded it internally with my team for their consideration in future app improvements." So the Revolut's team is treating this as a "future improvement" rather than a bug fix 🫤. @SaintPatrck At this point, should this issue remain open?
GiteaMirror commented 2026-04-15 01:18:18 -05:00
Author
Owner
Copy Link

@RokeJulianLockhart commented on GitHub (Dec 28, 2025):

At this point, should this issue remain open?

@samuele-ruffino96, that's a matter of Revolut's first-line support not understanding that CTAP2 is an open standard. Bitwarden can special-case this, if required; there's little that needs to be done on Revolut's end, if they're not willing to. It'll merely mean that it shall take longer.

<!-- gh-comment-id:3694769061 --> @RokeJulianLockhart commented on GitHub (Dec 28, 2025): > At this point, should this issue remain open? @samuele-ruffino96, that's a matter of Revolut's first-line support not understanding that CTAP2 is an open standard. Bitwarden can special-case this, if required; there's little that *needs* to be done on Revolut's end, if they're not willing to. It'll merely mean that it shall take longer.
GiteaMirror commented 2026-04-15 01:18:19 -05:00
Author
Owner
Copy Link

@Lord-Of-Mysteries404 commented on GitHub (Jan 1, 2026):

This happening to me on Facebook, WhatsApp, Notion and so on. This is annoying

<!-- gh-comment-id:3704140237 --> @Lord-Of-Mysteries404 commented on GitHub (Jan 1, 2026): This happening to me on Facebook, WhatsApp, Notion and so on. This is annoying
GiteaMirror commented 2026-04-15 01:18:20 -05:00
Author
Owner
Copy Link

@Lord-Of-Mysteries404 commented on GitHub (Jan 1, 2026):

This happening to me on Facebook, WhatsApp, Notion and so on. This is annoying. This issue isn't limited to US but other countries as well.

<!-- gh-comment-id:3704142943 --> @Lord-Of-Mysteries404 commented on GitHub (Jan 1, 2026): This happening to me on Facebook, WhatsApp, Notion and so on. This is annoying. This issue isn't limited to US but other countries as well.
GiteaMirror commented 2026-04-15 01:18:20 -05:00
Author
Owner
Copy Link

@pamperer562580892423 commented on GitHub (Jan 3, 2026):

@Lord-Of-Mysteries404:

This happening to me on Facebook, WhatsApp, Notion and so on.

WhatsApp is tracked in a separate issue: https://github.com/bitwarden/android/issues/5329 (and I think Notion was mentioned there as well by a BW developer)

PS: And there is another issue about "Facebook" (though mainly for the browser extensions): https://github.com/bitwarden/clients/issues/17955

<!-- gh-comment-id:3707265474 --> @pamperer562580892423 commented on GitHub (Jan 3, 2026): @Lord-Of-Mysteries404: > This happening to me on Facebook, WhatsApp, Notion and so on. WhatsApp is tracked in a separate issue: https://github.com/bitwarden/android/issues/5329 (and I think Notion was mentioned there as well by a BW developer) PS: And there is another issue about "Facebook" (though mainly for the browser extensions): https://github.com/bitwarden/clients/issues/17955
GiteaMirror commented 2026-04-15 01:18:21 -05:00
Author
Owner
Copy Link

@Rogerddit commented on GitHub (Feb 11, 2026):

@Lord-Of-Mysteries404:

This happening to me on Facebook, WhatsApp, Notion and so on.

WhatsApp is tracked in a separate issue: #5329 (and I think Notion was mentioned there as well by a BW developer)

PS: And there is another issue about "Facebook" (though mainly for the browser extensions): bitwarden/clients#17955

WhatsApp case is solved in last bitwarden android app update 2026.1.1.

I hope that revolut implement the changes in their app ASAP 🙏

<!-- gh-comment-id:3883946730 --> @Rogerddit commented on GitHub (Feb 11, 2026): > [@Lord-Of-Mysteries404](https://github.com/Lord-Of-Mysteries404): > > > This happening to me on Facebook, WhatsApp, Notion and so on. > > WhatsApp is tracked in a separate issue: [#5329](https://github.com/bitwarden/android/issues/5329) (and I think Notion was mentioned there as well by a BW developer) > > PS: And there is another issue about "Facebook" (though mainly for the browser extensions): [bitwarden/clients#17955](https://github.com/bitwarden/clients/issues/17955) WhatsApp case is solved in last bitwarden android app update 2026.1.1. I hope that revolut implement the changes in their app ASAP 🙏
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#15017
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?