Steps To Reproduce
- Vaultwarden/Bitwarden account, Android app 2026.7.1 (21803)
- Settings → Vault → Import items → "Import from another app"
- Select Google Password Manager as the source
- Approve the Credential Exchange handoff
Expected Result
Credentials are imported.
Actual Result
"Unable to import your items", with:
com.bitwarden.sdk.BitwardenException$Export: v1=com.bitwarden.exporters.ExportException$Cxf:
Credential Exchange error: JSON error: invalid value: integer `-10097426689`,
expected u64 at line 1 column 3163
...
com.bitwarden.sdk.ExporterClient.importCxf(...:66)
Nothing is imported — the parse fails before any write, so the vault is left empty
rather than partially populated.
Additional Context
-10097426689 read as epoch milliseconds is 1969-09-06T03:09:33Z. It fits in
i64 but not u64, so a credential with a pre-1970 (i.e. never properly set)
timestamp aborts the entire import.
Note this is a different value from the -11644473600 (Windows FILETIME epoch)
in #7175 — Google Password Manager emits a range of negative timestamps, so this
is not one magic constant.
This appears to be the same defect as #7175, which was closed as not_planned
(duplicate of #7140). I believe that triage was incorrect: #7140 is a different
symptom ("no export option"), and its own reporter stated they could no longer
reproduce it. PR #7216 already implements a fix and has been open since
2026-07-28. Filing this so the crash has an open tracking issue; happy for it to
be closed in favour of reopening #7175.
- Bitwarden Android: 2026.7.1 (21803),
release/2026.7-rc59@abb9dde
- Device: Sony XQ-EC72
- Android: 16 (API 36)
- Source: Google Password Manager
Steps To Reproduce
Expected Result
Credentials are imported.
Actual Result
"Unable to import your items", with:
Nothing is imported — the parse fails before any write, so the vault is left empty
rather than partially populated.
Additional Context
-10097426689read as epoch milliseconds is1969-09-06T03:09:33Z. It fits ini64but notu64, so a credential with a pre-1970 (i.e. never properly set)timestamp aborts the entire import.
Note this is a different value from the
-11644473600(Windows FILETIME epoch)in #7175 — Google Password Manager emits a range of negative timestamps, so this
is not one magic constant.
This appears to be the same defect as #7175, which was closed as
not_planned(duplicate of #7140). I believe that triage was incorrect: #7140 is a different
symptom ("no export option"), and its own reporter stated they could no longer
reproduce it. PR #7216 already implements a fix and has been open since
2026-07-28. Filing this so the crash has an open tracking issue; happy for it to
be closed in favour of reopening #7175.
release/2026.7-rc59@abb9dde