Password Depot for Android — RC9 QA Test Report

Currently, switching between databases is only convenient on tablet landscape mode, where the left pane allows switching between local DBs and server DBs. On tablet portrait and phone, there is no unified way to switch databases — the user must navigate back and re-enter the target database, which is cumbersome.

We propose unifying the database selector across all form factors (phone, tablet portrait, tablet landscape) by making the database name area in the top-left of the top bar a clickable dropdown, consistent with the existing localdb1002 ▼ design.

Proposal

1. Keep the existing localdb1002 ▼ design

The database name in the top bar should remain clickable, as it already is for local DBs.

2. Clicking ▼ opens a unified database list

The dropdown should show:

• All local databases

• All connected server databases (if signed in)

• All configured cloud databases

• A "Back to server list" option (only when the current DB is a server DB)

• An "Add database…" entry

3. Selecting a database switches directly to it

No need to navigate back to the database manager.

Visual Mockup

Top bar (example: Server DB open):

┌─────────────────────────────────────────────┐
│  Private_DB_suser01.pswe ▼   🔄  ⚙️  Sign out │
│  172.20.10.5:8714 · suser01                  │
└─────────────────────────────────────────────┘

Clicking ▼ opens:

┌─────────────────────────────────────────────┐
│  🔍 Search databases…                        │
├─────────────────────────────────────────────┤
│  🖥️  Server databases                        │
│     ✓ Private_DB_suser01.pswe                │
│       Private_DB_suser02.pswe                │
│       Shared_Team.pswe                       │
├─────────────────────────────────────────────┤
│  ☁️  Cloud databases                         │
│       MyVault.pswe          OneDrive         │
│       WorkVault.pswe        Google Drive     │
│       Backup.pswe           Dropbox          │
├─────────────────────────────────────────────┤
│  💾  Local databases                         │
│       localdb1002                            │
│       localdb1003                            │
├─────────────────────────────────────────────┤
│  ⬅  Back to server list                     │
│  ＋  Add database…                           │
└─────────────────────────────────────────────┘

Form-factor-specific behavior

Rationale

• Consistency: Local DBs already use a ▼ dropdown; extending this to server and cloud DBs makes the interaction uniform.

• Efficiency: Users on phones and tablet portrait currently have to navigate back to the database manager to switch DBs. A dropdown removes that friction.

• Clarity: Grouping by type (Server / Cloud / Local) with icons and subtitles (e.g., "OneDrive", "172.20.10.5:8714") makes it immediately clear what each entry is.

• Scalability: Future database types (FTP, WebDAV, etc.) can be added as new groups without redesigning the UI.

Acceptance Criteria

• The database name in the top bar is clickable on phone, tablet portrait, and tablet landscape.

• Clicking ▼ opens a dropdown list of databases grouped by type (Server / Cloud / Local).

• Selecting a database switches to it directly (prompting for password if locked).

• On tablet landscape, the dropdown only shows the relevant subset (server DB list when a server DB is open; local DB list when a local DB is open).

• An "Add database…" entry is available at the bottom of the dropdown.

• The current database is marked with a checkmark (✓).

• The dropdown is scrollable and searchable when the list is long.

When a user signs in to an Enterprise Server database via SSO (Entra ID / OpenID Connect) for the first time, the Azure login page is shown in the browser. Immediately after the SSO authentication completes, the Android client displays the autofill prompt:

"Save username and password to Password Depot?"
[No thanks] [Save]

However, after tapping Save, no entry is created in any of the following places:

• The Enterprise Server database that was just opened

• Any other open server database

• Any recent local database

The user has no way to find the saved entry, and no feedback is given about where it was (or was not) stored.

Steps to Reproduce

1. On the Android client, sign in to an Enterprise Server 20 database using SSO (Entra ID / OpenID Connect) for the first time.

2. The Azure login page opens in the browser; complete the sign-in.

3. After the SSO authentication completes, the prompt "Save username and password to Password Depot?" appears.

4. Tap Save.

5. Open the server database that was just connected.

6. Check for a new entry containing the SSO credentials.

7. Also check any recently opened local databases.

Actual Result

• The prompt appears after SSO login.

• After tapping Save, no entry is created in the server database or any local database.

• The user cannot locate the saved credentials anywhere.

• No error message or explanation is shown.

Expected Result

Either of the following behaviours is acceptable:

Option A — Do not show the prompt if saving is not possible
If SSO credentials cannot be saved to Password Depot (e.g., because SSO uses a token-based flow and no reusable username/password pair exists), the prompt should not appear at all. Showing it creates a false expectation.

Option B — Actually save the entry (preferred)
If the prompt is shown and the user taps Save, the entry should be actually created. The preferred target is the most recently opened local database, since SSO credentials may not be appropriate to store inside the Enterprise Server database itself. The user should receive confirmation (e.g., "Saved to localdb1002") so they know where the entry went.

Additional Notes

• This issue occurs specifically with SSO login, where the authentication is handled by an external identity provider (Azure / Entra ID) rather than a direct username/password pair entered into Password Depot.

• The prompt appears because the browser detects a login form submission during the SSO flow, but the credentials are not reusable in the same way as a standard form login.

• The prompt is misleading and should either be suppressed for SSO flows or handled with a clear save target and confirmation.

Suggested Fix

1. Detect SSO login context and suppress the autofill save prompt if no reusable credentials can be captured.

2. If the prompt is kept, ensure the entry is actually written to a defined location (e.g., the most recent local DB) and show a confirmation message with the database name.

3. Add logging to record why the save was skipped or where it was stored, to aid future debugging.

When a user opens a database and is viewing the entry list, the top bar shows the Refresh button (🔄) alongside the settings and sign-out actions. This allows the user to manually refresh the server database and pull the latest changes.

However, as soon as the user taps an entry to open its detail view, the Refresh button disappears from the top bar. The settings (⚙️) and sign-out actions remain visible, but the refresh action is gone.

This is inconsistent — refreshing the database should be available regardless of whether the user is viewing the entry list or an entry detail. In fact, refreshing while viewing an entry is arguably more important, because the user may want to check whether the entry has been updated on the server (e.g., by another device or another user).

Steps to Reproduce

1. Sign in to an Enterprise Server database on the Android client.

2. In the entry list view, confirm that the Refresh button is visible in the top bar.

3. Tap any entry to open its detail view.

4. Observe the top bar.

Actual Result

• The Refresh button disappears from the top bar in the entry detail view.

• Only the settings (⚙️) and sign-out actions remain.

• The user cannot refresh the database without first navigating back to the entry list.

Expected Result

• The Refresh button should remain visible in the top bar in both the entry list view and the entry detail view.

• The user should be able to refresh the database at any time, regardless of which screen they are on.

In the entry detail view on tablet portrait, the Edit button and the overflow menu (⋮) are positioned on the left side of the detail header, directly below the entry title. This placement is inconsistent with the tablet landscape layout, where the same actions are correctly aligned to the right side of the header.

Since the landscape layout is already correct, this improvement only targets tablet portrait (and, if applicable, phone portrait) to bring it in line with the landscape behaviour.

Current Layout (Tablet Portrait)

┌─────────────────────────────────────────────┐
│  🔒  account.teamviewer.com                 │
│      Password                               │
│                                             │
│  ┌────────┐  ┌───┐                          │
│  │ ✏️ Edit │  │ ⋮ │                          │
│  └────────┘  └───┘                          │
│                                             │
│  Credentials                                │
│  ...                                        │
└─────────────────────────────────────────────┘

The Edit and ⋮ buttons sit on the left, immediately under the title, which:

• Differs from the already-correct landscape layout

• Pushes content downward unnecessarily

• Breaks the standard "actions on the right" pattern used elsewhere in the app

Proposed Layout (Tablet Portrait)

┌─────────────────────────────────────────────┐
│  🔒  account.teamviewer.com                 │
│      Password                               │
│                                             │
│                         ┌────────┐  ┌───┐   │
│                         │ ✏️ Edit │  │ ⋮ │   │
│                         └────────┘  └───┘   │
│                                             │
│  Credentials                                │
│  ...                                        │
└─────────────────────────────────────────────┘

The Edit and ⋮ buttons move to the right side, on the same line as the entry title.

Scope

Only tablet portrait is in scope for this ticket. Landscape is already correct and should not be modified.

Acceptance Criteria

• In tablet portrait, the Edit and ⋮ buttons appear on the right side.

• The title and metadata remain left-aligned.

• Layout remains stable when the entry title is long (no overlap, no wrapping issues).

• Tablet landscape layout remains unchanged.

When a user logs in to a website in the browser and Password Depot offers to save the credentials, the save flow does not allow the user to choose which folder the new entry should be saved into.

Currently, the entry is saved to the database root (or to an unspecified default location), which means:

• Users with many folders (e.g., "Work", "Personal", "Finance", "Clients") cannot file the new entry where it belongs

• The user has to open the app afterwards, find the entry, and manually move it to the correct folder

• On larger databases this creates clutter and makes entries harder to find later

The same applies to the "Replace saved password?" dialog — there is no way to change the target folder at that point either.

Current Flow

Step 1 — Save to Password Depot

Step 2 — Replace saved password?

Neither dialog lets the user pick a folder.

Proposed Improvement

Add a folder selector to both dialogs, so the user can choose where the entry is saved.

Step 1 — Save to Password Depot (with folder selector)

┌─────────────────────────────────────┐
│           🔒                        │
│   Save to Password Depot            │
│   ● Database: localdb1002           │
│   ● for account.teamviewer.com      │
│                                     │
│   Save to folder                    │
│   [ 📁 / (root)              ▼ ]    │
│                                     │
│   User name                         │
│   ─                                 │
│                                     │
│   Password                          │
│   ••••••••                          │
│                                     │
│   Master password                   │
│   [___________________]             │
│                                     │
│   [  Unlock and save  ]             │
│   Don't save                        │
└─────────────────────────────────────┘

Step 2 — Replace saved password? (with folder option)

┌─────────────────────────────────────┐
│           🔒                        │
│   Replace saved password?           │
│   The entry account.teamviewer.com  │
│   (—) already exists for this       │
│   target. Replace its saved         │
│   password with the new one?        │
│                                     │
│   Save to folder                    │
│   [ 📁 Work / Clients        ▼ ]    │
│                                     │
│   User name                         │
│   ─                                 │
│                                     │
│   Password                          │
│   ••••••••                          │
│                                     │
│   [   Replace password   ]          │
│   [   Save as new entry  ]          │
│   Cancel                            │
└─────────────────────────────────────┘

Folder picker behaviour:

• Defaults to the last used folder

• Shows the same folder tree as the main app

• Allows creating a new folder inline (optional, nice-to-have)

• Remembers the last selected folder for the next autofill save

Acceptance Criteria

• The "Save to Password Depot" dialog includes a folder selector.

• The "Replace saved password?" dialog includes a folder selector (used when saving as a new entry).

• The folder selector shows the same folder hierarchy as the main app.

• The selected folder is respected when the entry is created.

• The default folder is the database root or the last used folder.

• If the user does not interact with the folder selector, the entry is saved to the default location as before.

In the Android client's Settings screen, every other setting applies immediately when the user toggles it or changes its value. There is no Save or Cancel button anywhere else in Settings — the change takes effect right away and the screen simply reflects the new state.

The Master password policy dialog is the only exception. It shows a dedicated Save and Cancel button at the bottom, which:

• Breaks the interaction pattern used everywhere else in Settings

• Makes the user wonder whether other settings also require a save

• Adds unnecessary friction (an extra tap to confirm)

• Creates a risk of losing changes if the user navigates away without tapping Save

For a consistent experience, this dialog should behave like the rest of Settings: changes apply immediately, with no Save or Cancel buttons.

Current Behaviour

Every other Settings row applies immediately — only this dialog has Save / Cancel.

Proposed Behaviour

┌─────────────────────────────────────┐
│   Master password policy            │
│   Applies to new master passwords   │
│   (creating a database, changing    │
│   the master password). Managed     │
│   settings can only tighten it.     │
│                                     │
│   Minimum length                    │
│   [ 8                    ]          │
│                                     │
│   Lowercase letters required    [●] │
│   Uppercase letters required    [○] │
│   Numbers required              [●] │
│   Special characters required   [○] │
└─────────────────────────────────────┘

• Changes apply immediately, exactly like all other Settings entries.

• The dialog can still be closed with the standard back gesture or a close (✕) action.

• A subtle inline confirmation (e.g., "Policy updated") could optionally be shown, matching the pattern used elsewhere.

Acceptance Criteria

• The Master password policy dialog no longer shows Save and Cancel buttons.

• Changing any value in the dialog (minimum length, letter/number/special-character toggles) takes effect immediately.

• Closing the dialog without any change leaves the policy untouched.

• The behaviour matches all other Settings entries (immediate apply, no confirm step).

• If a change cannot be applied (e.g., managed settings only tighten the policy), a clear inline message explains why, instead of blocking on a Save button.

In Settings → Backup copies, the row "Create backup copy now" currently shows a chevron (>) on the right side, identical to navigation rows such as Number of stored copies, External folder, and Backup copies.

However, this row is not a navigation entry — tapping it immediately performs an action (creating a backup copy). Using the chevron is misleading, because elsewhere in Settings the chevron consistently means "opens a sub-page".

Additionally, after tapping the row, there is no feedback telling the user whether the backup was created successfully or whether it failed. The only indirect signal is the Last copy: timestamp, which the user may not notice.

Current Behaviour

Problems:

• The > icon implies navigation, but the row performs an action.

• No success or failure feedback is shown after tapping.

Proposed Behaviour

1. Replace the chevron with an action icon

Use a "run / execute now" icon instead of >, for example a refresh-style circular arrow (⟳):

┌─────────────────────────────────────────────┐
│  Create backup copy now                 ↻  │
│  Last copy: 10/02/2026 4:39 PM              │
├─────────────────────────────────────────────┤
│  When saving the database           [ ● ]   │
│  When opening the database          [ ○ ]   │
│  Number of stored copies             7  >   │
│  External folder                        >   │
│  Backup copies                          >   │
└─────────────────────────────────────────────┘

The other rows keep their > chevron, since they genuinely open sub-pages. This visually distinguishes "action" rows from "navigation" rows.

2. Show a result toast after the action

After tapping the row, display a short snackbar / toast:

• On success:

  ✅ Backup copy created
  (optionally include the timestamp or file name)

• On failure:

  ⚠️ Could not create backup copy
  (optionally include a short reason, e.g. "Not enough storage")

• While in progress (optional):
  Briefly disable the row and show a spinner or "Creating backup…" state to prevent double-taps.

Acceptance Criteria

• The > chevron on "Create backup copy now" is replaced with an action icon (e.g., ↻).

• Other rows in the same group keep their > chevron.

• Tapping the row triggers the backup immediately.

• A success toast is shown when the backup is created.

• A failure toast is shown when the backup cannot be created.

• The Last copy: timestamp updates after a successful backup.

• The row is briefly disabled or shows a progress state while the backup runs, to prevent duplicate taps.

In Settings → Backup copies, the row "Number of stored copies" currently shows the current value followed by a chevron (7 >). Tapping the row opens a separate dialog where the user can edit the number.

Since this setting only changes a single numeric value, opening a full dialog is unnecessarily heavy. An inline stepper control directly on the Settings row would be faster and more consistent with how numeric settings are handled in modern mobile apps.

Current Behaviour

┌─────────────────────────────────────────────────────┐
│  Number of stored copies                    7  >    │
└─────────────────────────────────────────────────────┘
                        ↓ tap
┌─────────────────────────────────────┐
│   Number of stored copies           │
│                                     │
│   [        7            ]           │
│                                     │
│   [   Save   ]    [  Cancel  ]      │
└─────────────────────────────────────┘

Problems:

• Two taps required just to change one number (open dialog → confirm).

• Inconsistent with the rest of Settings, where most values are changed inline.

• A dialog for a single numeric field feels heavier than necessary.

Proposed Behaviour

Replace the value + chevron with an inline stepper on the row itself:

text

┌─────────────────────────────────────────────────────┐
│  Number of stored copies        ─  [  7  ]  +       │
│  Copies older than this are removed.                │
└─────────────────────────────────────────────────────┘

Control behaviour:

Subtitle (optional): Add a short line under the row explaining the effect, e.g., "Copies older than this are removed." This replaces the need for a separate dialog with explanatory text.

Comparison

Acceptance Criteria

• The "Number of stored copies" row no longer opens a dialog.

• The row shows a stepper control: − [ value ] +.

• − and + adjust the value by 1 and are disabled at min/max.

• Tapping the input field opens the numeric keyboard for direct entry.

• Non-numeric input is ignored; out-of-range values are clamped.

• Changes apply immediately (no Save / Cancel buttons).

• The row remains visually consistent with other Settings entries.

When both a local database and a server database are open and unlocked in the Android client at the same time, the autofill feature only searches for matching entries in the server database.

This happens regardless of which database the user opened most recently. Even if the user just opened a local database and is actively working in it, autofill still ignores it and only looks at the server DB.

As a result, entries saved in the local database are never offered for autofill, even though the local DB is unlocked and available.

Steps to Reproduce

1. On the Android client, sign in to an Enterprise Server database (leave it unlocked).

2. Also open a local database (leave it unlocked).

3. Switch to the local database and open an entry in it.

4. Open a browser and trigger autofill on a login page that matches an entry in the local database.

5. Observe which entries are offered.

Actual Result

• Autofill only searches the server database.

• Entries from the local database are not offered, even though the local DB is unlocked and was the most recently used database.

• The user cannot autofill entries from the local DB unless they close or lock the server DB first.

Expected Result

When both a local DB and a server DB are unlocked, autofill should search both databases and offer matching entries from either. If multiple matches exist, they should be presented in a clear list (e.g., grouped by database).

Alternatively, at minimum, autofill should prioritise the most recently opened / most recently used database, so that if the local DB is active, its entries are offered first or included.

Suggested Behaviour

Option A — Search both databases (preferred)

Autofill aggregates results from all unlocked databases and shows them in one list, grouped or labelled by source:

text

┌─────────────────────────────────────────────┐
│  Autofill suggestions                       │
├─────────────────────────────────────────────┤
│  💾 localdb1002                             │
│     account.teamviewer.com                  │
├─────────────────────────────────────────────┤
│  🖥️ Private_DB_suser01.pswe                 │
│     account.teamviewer.com                  │
└─────────────────────────────────────────────┘

Option B — Prioritise the most recently opened database

If the local DB is the active one, autofill searches it first and only falls back to the server DB if no match is found.

Acceptance Criteria

• When both a local DB and a server DB are unlocked, autofill searches both.

• Entries from the local DB are offered when they match, even if a server DB is also unlocked.

• The source database of each suggestion is visible to the user (e.g., labelled or grouped).

• If both databases contain a matching entry, the user can choose which one to use.

• Behaviour is consistent regardless of which database was opened first.

Current Behavior:
In the "Another way in" section on the home screen:

• When collapsed, the indicator arrow points right (>).

• When expanded, the indicator arrow points down (v).

Problems / UX Rationale:

1. In mobile UX (Material Design / iOS), a right chevron (>) strongly indicates page navigation / drill-down to a new screen. Because the sub-options inside "Another way in" (e.g., "Open database file", "Open from cloud") already use right chevrons (>) to navigate, having a right chevron on the collapsible header creates confusion and inconsistency.

2. When the section is already expanded, a downward arrow does not intuitively convey "collapse/hide upward".

Proposed Solution:
Adopt the standard mobile collapsible / accordion pattern:

• Collapsed state: Chevron points down (⌄) to indicate that the section expands downwards.

• Expanded state: Chevron points up (⌃) to indicate that tapping will collapse the section upwards.

Acceptance Criteria:

1. When "Another way in" is collapsed, the arrow icon points down (⌄).

2. When "Another way in" is expanded, the arrow icon points up (⌃).

3. Tapping the section toggles between expanded and collapsed states with the matching chevron direction.

Impact

Syncing a local database to cloud storage permanently converts it into a cloud database. This causes offline work to block and hang. Users cannot open or change entries smoothly when the network is unavailable.

Expected behaviour

• Syncing a local database to cloud storage should not turn it into a cloud-only database.

• Read and write actions should work directly on the local copy.

• Cloud sync should only run during automatic sync intervals or when the user triggers it manually.

• If offline, the app should use the local copy immediately without waiting for a network timeout.

Actual behaviour

• After syncing a local database to cloud storage, the database becomes a cloud database.

• When the network is unavailable or the cloud storage is unreachable:

  • Opening the database hangs and blocks the UI until the cloud connection times out.

  • CRUD operations such as adding, editing, moving, and deleting entries also hang until the connection times out.

• The database icon/type changes directly into a cloud database after syncing.

Steps to reproduce

• Create a new local database.

• Sync the database to WebDAV or another cloud storage service.

• Notice that the database changes directly into a cloud database.

• Disconnect the network or switch the device to Airplane Mode.

• Attempt to open the database.

• Attempt a CRUD operation such as:

  • add a new entry

  • edit an existing entry

  • move an entry to a folder

  • delete an entry

Environment

• Local database synced to WebDAV or another cloud storage service

• Offline conditions

• Network unavailable or device in Airplane Mode

• Client version: v20.0.0 RC9 build 2009

Summary

Currently, the Settings menu mixes database-level settings and app-level settings together into a single flat list. This causes confusion for users because it is unclear which settings apply globally across the entire app and which settings are specific to the currently opened database. Furthermore, in tablet mode, navigation does not clearly differentiate between global and database-specific settings.

Problem Analysis & Current State

• Settings are mixed together without clear scope differentiation:

  • Users cannot easily tell whether modifying an option (e.g., in Security or Backup copies) will affect all databases or just the current database.

  • In Tablet mode, the left navigation bar provides a Settings button, but opening it shows mixed settings (or local/cloud settings) rather than a dedicated global app settings panel.

Proposed Classification of Settings

1. Database-Level Settings (Scoped to individual DB):

   • Security: Each database should have its own security configurations (e.g., encryption settings, password policies, auto-lock behavior per DB).

   • Backup copies: Backup frequency, retention, and storage path specific to that database.

   • Entry Point: Accessible when a database is open (e.g., via a Settings button/icon in the database view top bar / action bar).

2. App-Level Settings (Global across all DBs):

   • Autofill & passkeys: System-wide autofill provider and passkey behavior.

   • Databases & sync: Global sync schedules, cloud accounts, default storage locations.

   • General: App language, theme, startup behavior, etc.

   • Support: Help center, contact support, diagnostic logs, app version.

   • Entry Point: Main navigation / left sidebar settings button.

Tablet Mode Navigation Improvement

• Left Sidebar Settings Button: Clicking Settings on the left navigation bar should exclusively display App-level Settings.

• Database View Toolbar: When any database is opened (in the right panel / detail view), add a dedicated Database Settings button in the top action bar to open Database-level Settings for that specific database.

Acceptance Criteria

1. Settings options are clearly separated into App-level settings and Database-level settings.

2. In Tablet mode:

   • Left bar "Settings" button opens only App-level settings (Autofill & passkeys, Databases & sync, General, Support).

   • An open database view provides an entry point (e.g., settings icon in the top right / header) to access that database's specific settings (Security, Backup copies).

3. The UI clearly communicates the scope of each setting so users are not confused about whether a setting is global or per-database.