Skip to content
Commit 14542746 authored by Josh Tsuji's avatar Josh Tsuji
Browse files

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
Merged-In: Ia71eb5fb0f85eb5fb494e66a270c68d7df5e1629
parent 04d4e068
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment