summaryrefslogtreecommitdiff
path: root/api/api.go
diff options
context:
space:
mode:
author Josh Tsuji <tsuji@google.com> 2022-07-01 14:58:05 -0400
committer Josh Tsuji <tsuji@google.com> 2022-07-01 19:11:43 +0000
commite66e445e6ad6c879cdcb3accac0b2c825c8151be (patch)
treef6f3d6c1aa1f6d66d4e2eebe18df9b1da0d98633 /api/api.go
parent6e5aa44ad8e1951af7070cadf8a16a3d37d6081a (diff)
Don't setOccluded in onLaunchAnimationStart.
After recent fixes, WM exclusively communicates occluded state by calling the occlude/unocclude animators' onAnimationStart and onAnimationCancelled methods. We call KeyguardViewMediator#setOccluded there to officially set System UI's occluded state. Those methods are guaranteed to be called prior to the launch animator methods. This means that the setOccluded call in onLaunchAnimationStart should always be redundant. However, a series of race conditions (see https://buganizer.corp.google.com/issues/235463625#comment85) could cause this to be called after WM called the unocclude animator's onAnimationStart. Also, add logging to places where we set occluded state to aid in future debugging. These logs are only called during activity launch so should not be frequently logged. Fixes: 235463625 Test: launch and kill the Android Auto head unit ~50 times until onLaunchAnimationStarted ends up being called after the unocclude onAnimationStart, verify that we don't end up in the black screen state Test: launch/kill camera repeatedly to verify no regressions with camera occluding lockscreen Test: launch device controls, with and without controls added, to verify that we are not regressing other trampoline occluding actvities Change-Id: Ia71eb5fb0f85eb5fb494e66a270c68d7df5e1629
Diffstat (limited to 'api/api.go')
0 files changed, 0 insertions, 0 deletions