diff options
| author | 2024-09-12 06:50:43 +0000 | |
|---|---|---|
| committer | 2024-10-07 20:34:59 +0000 | |
| commit | 5a4166738028356c3ffb9cf99debcd12688b68dd (patch) | |
| tree | 8acf8aebcb89eae95cd7cfebe7c313abd5d844f3 /libs/androidfw/ResourceTimer.cpp | |
| parent | 761f72e9368fc93d5ed02851c97f1227c3735261 (diff) | |
Have Keyguard drive Unlock/Lock transition directly to Shell.
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
Diffstat (limited to 'libs/androidfw/ResourceTimer.cpp')
0 files changed, 0 insertions, 0 deletions