Add option to "Shake and Lock" to still allow fingerprint unlock

[BlockchainVRCloudAI]

Currently if "Shake and Lock" is enabled, and the accelerometer triggers and locks the phone, the user is forced to use the primary unlock mechanism of the lockscreen (i.e. biometrics are disabled).

Would it be possible to add an option, to still allow the secondary unlock mechanism, e.g. the fingerprint to unlock the lockscreen?

---

I use GrapheneOS with Two-factor fingerprint unlock. That means my primary unlock mechanism is a very long diceware password, which takes a long time to enter and is very inconvenient, and my secondary unlock is fingerprint + a short PIN code.

Currently whenever the app decides to lock the device, I need to enter the very long diceware password (primary unlock). This makes it ~unusable for me. The secondary unlock is already extremely secure in my case. If there was an option to select the "harshness" of the locking done by the app, I would want it to always allow secondary unlock.

My use cases would be to enable "Shake and Lock" and

• use it as an "anti-theft" mechanism. Ideally if a thief snatches the unlocked phone out of my hands, the accelerometer-based checks should trigger the locking of the phone.
• prolong the expected lifetime of the power button. Instead of pressing the power button hundreds of times per day (lock device, wake device) I could save roughly half the presses via locking by shaking it.

---

As per wesaphzt/privatelock#34 (comment),

"Android Pie introduces an accessibility action to turn off the screen. If the device is > running Pie, you can use an AccessibilityService to run
performGlobalAction(GLOBAL_ACTION_LOCK_SCREEN);"

That is, it is technically possible to programmatically trigger the screen lock without disabling secondary unlock.

Thanks for the app and for the consideration.

[hardalgorithm]

Thanks for the detailed explanation and for describing your use case so clearly — it makes a lot of sense. I’ll think about implementing this option in a future update, as your reasoning about the “soft lock” behavior is quite logical.