File changed.
Preview size limit exceeded, changes collapsed.
Loading
[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