Addresses 14 of the 15 confirmed findings from the max-effort review of the
screen-lock app gate. The remaining one (accounts/credentials share the
auth-bound cache DB) needs a device-tested Room migration and is filed
separately; its blast radius is reduced here by eliminating the spurious wipes.
- Cold-start deadlock: LibreMailApplication injects AccountRepository lazily so
the Room DB is never built on the main thread before unlock.
- Passphrase source of truth: DatabaseKeyStore.resolvePassphrase() keys off
which seal exists, not the app-lock setting; passphrase() refuses to mint a
master key while an auth seal exists.
- Toggle-order strand: disabling app-lock reseals under the master key whenever
an auth seal exists (not gated on the encryptCache setting).
- Crash-safe clear protocol: wipe + reset seals, then clear the flag last; set
clear-pending before flipping app-lock off.
- isInvalidated(): treats a lapsed auth window (UserNotAuthenticated) as valid,
and onForeground short-circuits when app-lock is off.
- unwrapSealedPassphrase: classifies all decrypt failures — no crash after a
successful auth.
- Headless entry points: SyncWorker/SendWorker/IdleService fail fast via
EncryptedCacheGuard instead of blocking DB construction while locked.
- sealWithMaster: deletes the orphaned auth key (no spurious later wipe).
- Lock-bypass race: AppLockGate ignores a background recorded after a foreground
pass began; the ViewModel captures the foreground timestamp synchronously.
- FLAG_SECURE: set while app-lock is on (recents/screenshot protection).
- Resume + re-lock: the gate covers content with an opaque overlay instead of
removing it, so no stale frame renders and in-progress state (nav, drafts)
survives re-lock.
- Retry feedback: lock emissions carry a nonce so a retry updates the UI.
Tests: AppLockGate stale-foreground race cases + an exhaustive
KeyInvalidationPolicy table. Fast gate green + androidTest compiles.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
JMR-devandClaude Fable 5
f66ec3d7fb