Version
3.4.2
Source
Google Play
Vault encryption
Yes (with biometric unlock)
Device
Pixel 9a
Android version
Android 16
ROM
No response
Steps to reproduce
- Create two entries with the exact same Account Name but different Issuers (e.g., Entry 1: Account testuser, Issuer Amazon | Entry 2: Account testuser, Issuer Google).
- Open the sort menu and select Account (Z to A). Observe the order of the two entries.
- Next, create entries with accented characters (e.g., Ämazon, Apple, Zebra).
- Change the sort to Issuer (A to Z) or Account (A to Z) and observe the placement of the accented entry.
- Create two identical entries that only differ by casing (e.g., apple and Apple), trigger a few sorts, and observe their relative order.
What do you expect to happen?
-
For Z to A: When sorting by Account (Z to A), the primary list should be sorted by Account from Z to A. However, entries that share the exact same Account name should fall back to being sorted by their Issuer from A to Z. Reversing a primary sort should not reverse the secondary tie-breaker.
-
For A to Z: Accented characters (like Ä) should be sorted naturally alongside their base letters (like A), honoring standard localized collation rules. Identical strings that only differ by capitalization should maintain a deterministic, stable order rather than randomly swapping places.
What happens instead?
-
For Z to A: Selecting Account (Z to A) or Issuer (Z to A) in SortCategory.java applies Collections.reverseOrder() to the entire chained comparator. This incorrectly reverses the secondary sort key as well, placing Google before Amazon when their account names tie.
-
For A to Z: Alphabetical sorting relies on String.compareToIgnoreCase(), which performs raw Unicode code point comparisons. This pushes accented characters to the very bottom of the list (e.g., Ämazon appears after Zebra). Additionally, case-differing identical strings return 0 with this method, which causes the stable sorter to lose determinism, resulting in items randomly swapping positions upon UI refreshes.
Log
No response
Version
3.4.2
Source
Google Play
Vault encryption
Yes (with biometric unlock)
Device
Pixel 9a
Android version
Android 16
ROM
No response
Steps to reproduce
What do you expect to happen?
For Z to A: When sorting by Account (Z to A), the primary list should be sorted by Account from Z to A. However, entries that share the exact same Account name should fall back to being sorted by their Issuer from A to Z. Reversing a primary sort should not reverse the secondary tie-breaker.
For A to Z: Accented characters (like Ä) should be sorted naturally alongside their base letters (like A), honoring standard localized collation rules. Identical strings that only differ by capitalization should maintain a deterministic, stable order rather than randomly swapping places.
What happens instead?
For Z to A: Selecting Account (Z to A) or Issuer (Z to A) in SortCategory.java applies Collections.reverseOrder() to the entire chained comparator. This incorrectly reverses the secondary sort key as well, placing Google before Amazon when their account names tie.
For A to Z: Alphabetical sorting relies on String.compareToIgnoreCase(), which performs raw Unicode code point comparisons. This pushes accented characters to the very bottom of the list (e.g., Ämazon appears after Zebra). Additionally, case-differing identical strings return 0 with this method, which causes the stable sorter to lose determinism, resulting in items randomly swapping positions upon UI refreshes.
Log
No response