+18
−1
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
Currently we have the following back-and-forth for keyguard transitions: 1) Keyguard/SystemUI talks to Core via ATMS to show/hide keyguard, or tell that keyguard is about to go away 2) Core shows apps 3) Core sends a transition request to Shell 4) Shell chooses KeyguardTransitionHandler to handle it and sends off to RemoteAnimation to animate keyguard going away This new change changes it so that instead of SystemUI -> Core, it's now SystemUI -> Shell: 1) Keyguard/SystemUI starts a Transition immediately as it show/hide/"about to hide" keyguard (keyguardGoingAway) 2) Shell uses KeyguardTransitionHandler to start the transition with a WCT=DisplayOperation.setKeyguardShowing(true/false) 3) Core receives WCT and calls on KeyguardController#setKeyguardShown to show apps 4) Transition system comes back to KeyguardTransitionHandler#startAnimation and process the new Changes w.r.t. app showing This change mostly focuses only on the simple unlock/lock use case, where the user just swipes up and keyguard unlocks. Other use cases need more care and will be addressed on subsequent CLs. This new logic is also behind a flag. Bug: 364930619 Test: Manually swipe up to see that it animates properly with Flag on Flag: com.android.window.flags.ensure_keyguard_does_transition_starting Change-Id: I3d770b41249a54452b8b01d7a3159f59168811ee