Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 8205a699 authored by Alejandro Nijamkin's avatar Alejandro Nijamkin
Browse files

[flexiglass] Fixes lockdown

There was an issue that, when the user entered lockdown mode, the device
would clearly be in that mode but the scene didn't change from Gone to
Lockscreen.

This was fixed by making sure that
DeviceUnlockedInteractor.deviceUnlockStatus took lockdown state into
account. This required a medium sized refactor to move the lockdown flow
from DeviceEntryInteractor to DeviceUnlockedInteractor (for background,
see ** below). Once the lockdown flow was moved into
DeviceUnlockedInteractor, it was possible to have its deviceUnlockStatus
take it into account. A device in lockdown has a DeviceUnlockStatus
where isUnlocked=false.

This also means that all downstream consumers of DeviceUnlockedInteractor.deviceUnlockStatus are now getting proper values when the device enters or exits lockdown.

The above fixed the original issue but then a new issue was revealed:
entering the correct PIN after lockdown didn't move bouncer to the Gone
scene.

As it turns out, system_server wasn't actually reporting that the need
for strong auth was removed so the system UI authentication code still
believed that the device isn't locked, leaving the user locked on the
bouncer scene - not good!

The solution was to move the call to LockPatternUtils.userPresent that
was previously a side effect of DeviceEntryInteractor.isDeviceEntered
(added in ag/28135648) to happen inside AuthenticationRepository
instead, right next to where we tell LockPatterUtils of a successful
password attempt.

This is a safe change because the legacy code seems to be doing
something similar, albeit a little different. The legacy code calls
userPresent only when the keyguard is hidden and, if I understand
correctly, hides the keyguard based on the event of a successful
credential check. In Flexiglass, the keyguard isn't hidden based on that
event; instead, it's hidden in response to a state change that tells
Flexiglass that the device has become unlocked. This means that we have
a sort of a catch 22 where we can't call userPresent before leaving the
bouncer but we can't leave the bouncer before calling userPresent.

** DeviceUnlockedInteractor history: The reason DeviceUnlockedInteractor exists as a separate class from
the seemingly better named DeviceEntryInteractor is to avoid a circular
dependency. DeviceEntryInteractor needs to depend on SceneInteractor
because that's how it knows whether the device is entered (whether we
moved to the Gone scene). The SceneInteractor needs to know if the
device unlocked to validate scene transition requests and make sure that
it's okay to move to the Gone scene (can only happen if the device is
unlocked, forbidden otherwise - a security feature).

Fix: 352404539
Test: manually verified that (1) entering lockdown from the power menu
moved to the lockscreen scene and that (2) entering the correct
credentials in the bouncer during lockdown moved to the gone scene
(tried 10 times)
Test: unit tests related to the moved logic were also moved
Test: unit tests added for lockdown in DeviceUnlockedInteractor
Flag: com.android.systemui.scene_container

Change-Id: Iffd4a1737bbeb1e3d953134ec3073c11e350bf9a
parent ae097932
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment