Overhaul keyguard occlusion and camera launch transitions.

This CL introduces the KeyguardOcclusionRepository, which keeps track of
a single piece of state - whether there is a SHOW_WHEN_LOCKED activity
on top of the task stack, regardless of whether we're locked or not.
This is the information we actually receive from WM (either via
RemoteAnimation start/cancel calls, or from
KeyguardService#setOccluded).

This state, fused with PowerInteractor's camera launch gesture
information, is all we need to correctly start any occlusion/camera
launch transition:

1. On waking from isAsleep(currentState):
  a. If there's a SHOW_WHEN_LOCKED activity on top (Maps Navigation,
     etc.), transition to OCCLUDED.
  b. If the camera gesture was triggered, transition to OCCLUDED unless
     we were just GONE, or the keyguard is dismissable, in which case
     transition to GONE. The first power button press *always* puts us
     to sleep, so we are guaranteed to be waking whenever the second tap
     comes in and the gesture is triggered.
2. When a SHOW_WHEN_LOCKED activity is launched (timer goes off, phone
   call arrives, etc.):
  a. If we're GONE, do nothing. If this activity remains on top by the
     next time we're locked, we'll transition to OCCLUDED via (1a).
  b. Otherwise, transition to OCCLUDED.
3. When a SHOW_WHEN_LOCKED activity is no longer on top:
  a. If we're OCCLUDED, transition to LOCKSCREEN.

To avoid an already too-large CL getting even larger, I've filed follow
up bugs to move the remote animation state into ViewModels. We'll also
need to continue moving StatusBarKeyguardViewManager calls into
interactors that collect KeyguardTransitionInteractor flows, so we can
delete StatusBarKeyguardViewManagerInteractor.

Bug: 307976454
Flag: ACONFIG com.android.systemui.keyguard_wm_state_refactor DEVELOPMENT
Flag: ACONFIG com.android.systemui.migrate_clocks_to_blueprint TEAMFOOD
Test: atest SystemUITests
Change-Id: Ib469f85881dc64d31b45bb0a5c5c3e64fc210570

0 files changed, 0 insertions, 0 deletions