[GH-ISSUE #5688] [PM-24709] Session Timeout as Immediately Brokes Attachments on Android #39281

Open
opened 2026-04-23 18:02:25 -05:00 by GiteaMirror · 3 comments
Owner

Originally created by @ffreality on GitHub (Aug 13, 2025).
Original GitHub issue: https://github.com/bitwarden/android/issues/5688

Steps To Reproduce

I bought personal premium for attachments but if I enable Settings / Account security / Unlock with Biometrics and set Session Timeout as Immediately, attachment adding doesn't work on Android (Samsung Galaxy S23 Android 15. There is NO custom rom or root.) because app goes background and file manager opens. When Bitwarden returns, it asks my finger print and open main menu without adding my attachments. Also, there is no third party file manager other than Samsun's default one.

In short, app can't hold its last state at memory. You can say don't set session timeout immediately but it is not a solution and why not ? it is the secured solution.

Expected Result

Successfuly adding an attachment to an entry such as secure note.

Actual Result

app goes background and file manager opens. When Bitwarden returns, it asks my finger print and open main menu without adding my attachments.

Screenshots or Videos

No response

Additional Context

No response

Build Version

2025.7.2 (20551)

What server are you connecting to?

EU

Self-host Server Version

No response

Environment Details

Samsung Galaxy S23 Android 15

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 @ffreality on GitHub (Aug 13, 2025). Original GitHub issue: https://github.com/bitwarden/android/issues/5688 ### Steps To Reproduce I bought personal premium for `attachments` but if I enable `Settings / Account security / Unlock with Biometrics` and set `Session Timeout` as `Immediately`, attachment adding doesn't work on Android (Samsung Galaxy S23 Android 15. There is NO custom rom or root.) because app goes background and file manager opens. When Bitwarden returns, it asks my finger print and open main menu without adding my attachments. Also, there is no third party file manager other than Samsun's default one. In short, app can't hold its last state at memory. You can say **don't set session timeout immediately** but it is not a solution and why not ? it is the secured solution. ### Expected Result Successfuly adding an attachment to an entry such as secure note. ### Actual Result app goes background and file manager opens. When Bitwarden returns, it asks my finger print and open main menu without adding my attachments. ### Screenshots or Videos _No response_ ### Additional Context _No response_ ### Build Version 2025.7.2 (20551) ### What server are you connecting to? EU ### Self-host Server Version _No response_ ### Environment Details Samsung Galaxy S23 Android 15 ### 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 bugapp:password-manager labels 2026-04-23 18:02:25 -05:00
Author
Owner

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

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

<!-- gh-comment-id:3184129007 --> @bitwarden-bot commented on GitHub (Aug 13, 2025): Thank you for your report! We've added this to our internal board for review. ID: PM-24709
Author
Owner

@marcopla99 commented on GitHub (Dec 26, 2025):

Hi! I've investigated the issue and found 2 main causes. Before opening a PR, I'd like to confirm with the development team to ensure that the issue is still relevant and I'm not missing important details.

  1. After unlocking the vault, in RootNavScreen, instead of always navigating to VaultRoute, the app should not have a cleared the back stack. Instead, it should pop the back stack so that AttachmentsScreen returns at the top of the stack, ideally with its state preserved. I've tested this quickly and it seems to work fine. Have you ever tried this approach, or are you aware of any potential issues with it?
  2. Step 1 alone isn't sufficient because AttachmentsViewModel will still have no data. This happens because the loading state is represented as a ViewState, and since AttachmentsState holds a reference to viewState that switches between Loading, Error, and Content, when viewState switches to Loading, the previous Content (including the newAttachment state) is lost. I noticed the same state management pattern in other screens. Is there a reason for this design? Why isn't the loading state represented by a simple boolean flag in the screen state, for example? Are there security concerns about keeping the cipher in memory even when data is loading?
<!-- gh-comment-id:3692753307 --> @marcopla99 commented on GitHub (Dec 26, 2025): Hi! I've investigated the issue and found 2 main causes. Before opening a PR, I'd like to confirm with the development team to ensure that the issue is still relevant and I'm not missing important details. 1. After unlocking the vault, in `RootNavScreen`, instead of always navigating to `VaultRoute`, the app should not have a cleared the back stack. Instead, it should pop the back stack so that `AttachmentsScreen` returns at the top of the stack, ideally with its state preserved. I've tested this quickly and it seems to work fine. Have you ever tried this approach, or are you aware of any potential issues with it? 2. Step 1 alone isn't sufficient because `AttachmentsViewModel` will still have no data. This happens because the loading state is represented as a `ViewState`, and since `AttachmentsState` holds a reference to viewState that switches between Loading, Error, and Content, when viewState switches to `Loading`, the previous Content (including the `newAttachment` state) is lost. I noticed the same state management pattern in other screens. Is there a reason for this design? Why isn't the loading state represented by a simple boolean flag in the screen state, for example? Are there security concerns about keeping the cipher in memory even when data is loading?
Author
Owner

@ffreality commented on GitHub (Dec 26, 2025):

Hi! I've investigated the issue and found 2 main causes. Before opening a PR, I'd like to confirm with the development team to ensure that the issue is still relevant and I'm not missing important details.

  1. After unlocking the vault, in RootNavScreen, instead of always navigating to VaultRoute, the app should not have a cleared the back stack. Instead, it should pop the back stack so that AttachmentsScreen returns at the top of the stack, ideally with its state preserved. I've tested this quickly and it seems to work fine. Have you ever tried this approach, or are you aware of any potential issues with it?
  2. Step 1 alone isn't sufficient because AttachmentsViewModel will still have no data. This happens because the loading state is represented as a ViewState, and since AttachmentsState holds a reference to viewState that switches between Loading, Error, and Content, when viewState switches to Loading, the previous Content (including the newAttachment state) is lost. I noticed the same state management pattern in other screens. Is there a reason for this design? Why isn't the loading state represented by a simple boolean flag in the screen state, for example? Are there security concerns about keeping the cipher in memory even when data is loading?

I don't know what are you talking about when you say RootNavScreen or VaultRoute. Even though I am a developer (just not mobile developer), I am an end user who paid for this "product" and I would like to use it without using some workarounds.

Currently I have this problem and if I want to add an attachment, I just change Session Timeout to a different value than Immediately.

If I don't do that, it just returns main screen without adding attachment. After adding an attachment, I change my setting back to immediately.

Problem continues since August (when I start to use the app)

<!-- gh-comment-id:3692925047 --> @ffreality commented on GitHub (Dec 26, 2025): > Hi! I've investigated the issue and found 2 main causes. Before opening a PR, I'd like to confirm with the development team to ensure that the issue is still relevant and I'm not missing important details. > > 1. After unlocking the vault, in `RootNavScreen`, instead of always navigating to `VaultRoute`, the app should not have a cleared the back stack. Instead, it should pop the back stack so that `AttachmentsScreen` returns at the top of the stack, ideally with its state preserved. I've tested this quickly and it seems to work fine. Have you ever tried this approach, or are you aware of any potential issues with it? > 2. Step 1 alone isn't sufficient because `AttachmentsViewModel` will still have no data. This happens because the loading state is represented as a `ViewState`, and since `AttachmentsState` holds a reference to viewState that switches between Loading, Error, and Content, when viewState switches to `Loading`, the previous Content (including the `newAttachment` state) is lost. I noticed the same state management pattern in other screens. Is there a reason for this design? Why isn't the loading state represented by a simple boolean flag in the screen state, for example? Are there security concerns about keeping the cipher in memory even when data is loading? I don't know what are you talking about when you say `RootNavScreen` or `VaultRoute`. Even though I am a developer (just not mobile developer), I am an end user who paid for this "product" and I would like to use it without using some workarounds. Currently I have this problem and if I want to add an attachment, I just change `Session Timeout` to a different value than `Immediately`. If I don't do that, it just returns main screen without adding attachment. After adding an attachment, I change my setting back to immediately. Problem continues since August (when I start to use the app)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#39281