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
(cherry picked from commit 1454274680f6d43dc8a37ea4df7cf4699348d039)
Merged-In: Ia71eb5fb0f85eb5fb494e66a270c68d7df5e1629

0 files changed, 0 insertions, 0 deletions