stop a configuration change from locking the vault (v2.14.77) MainActivity declares no configChanges, so a fold or unfold destroys and recreates it. The process-level background lock relies on ProcessLifecycleOwner's debounce to survive that teardown, which is timing-dependent: a foldable switching between its displays can outlast it, and the vault locks while the user is still looking at the app, producing a second lock screen and a second authentication. MainActivity now records whether its stop is a configuration change, and the background lock skips it. This makes the behaviour the existing comment already claims instead of leaving it to a race. UNVERIFIED against the reported symptom. A display-metrics change (wm size) was tried as a stand-in for the fold and does NOT reproduce it: with this guard removed the vault stayed unlocked across the same change, so an activity recreation on its own is not the trigger. The real trigger is presumed to be the display switch or a heavier teardown it causes. The guard is correct regardless — a configuration change must never lock the vault — but it is not proven to be the fix for the double lock screen. Verification: full JVM suite 1015 tests / 0 failures / 0 errors / 2 skipped; lintDebug clean; assembleDebug and debug androidTest sources compile.
$ koh steal kepr.uk/peach-android@cb82121ca450
·
parent: 95cd952b172e
discussion
log in to leave a comment.