summaryrefslogtreecommitdiff
path: root/libs/androidfw/ResourceTimer.cpp
diff options
context:
space:
mode:
author Ben Lin <linben@google.com> 2024-09-12 06:50:43 +0000
committer Ben Lin <linben@google.com> 2024-10-07 20:34:59 +0000
commit5a4166738028356c3ffb9cf99debcd12688b68dd (patch)
tree8acf8aebcb89eae95cd7cfebe7c313abd5d844f3 /libs/androidfw/ResourceTimer.cpp
parent761f72e9368fc93d5ed02851c97f1227c3735261 (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