- There are flows where the shared taskbar state is updated prior
to being destroyed, and not updated to the latest values when
the taskbar is recreated.
ie.
unfolded -> lock screen -> LauncherTaskbarUiController's
mTaskbarInAppDisplayProgress[SYSUI_SURFACE_PROGRESS_INDEX]
is set to 1 due to the notif shade (lockscreen) showing.
This is written into TaskbarSharedState's sysuiStateFlags
and inAppDisplayProgressMultiPropValues.
fold -> TaskbarActivityContext is destroyed
unlock -> TaskbarManager and TaskbarSharedState's
sysuiStateFlags are updated while the device is folded
unfold -> TaskbarActivityContext is recreated and initialized
which restores from the shared state's
inAppDisplayProgressMultiPropValues. It also tries to reapply
the shared state's sysuiStateFlags, but this doesn't update
inAppDisplayProgressMultiPropValues because the state's
"enabled" state is not updated (default is no flag set, and
lockscreen sysui state is not set anymore).
-> The restored inAppDisplayProgressMultiPropValues value
results in the wrong translation.
- Note that after the above, the NavbarButtonsViewController state
is actually correct and reflects the SysUI state, but the
LauncherTaskbarUiController state is wrong. This CL tries to
manually update the ui controller to the correct state when it
is recreated.
- CL also fixes a separate issue where LauncherTaskbarUIController
could potentially overwrite the saved state progresses while
restoring them due to the state callback being called
Bug: 283346744
Test: Unfold -> Lockscreen -> Fold -> Unlock -> Unfold and ensure
the buttons are translated correctly
Change-Id: I43e473faf4fa2a493b9705506e3755df8f6264e7
Signed-off-by: Winson Chung <winsonc@google.com>
- In the case where Launcher calls startRecentsTransition while there
are no other visible tasks, we should not be continuing with the
transition as there are no tasks for Launcher to control. This was
previously handled in RecentsAnimationController in legacy
transitions, but the safer fix is to ignore it on the Launcher
side for this release.
Bug: 289175232
Test: Manually trigger empty targets and verify no issues
Change-Id: I3657c000cbc8c14c9ac989c2a57715515c96edb6
- If a task is already visible, then startActivity is a no-op and the
remote transition that launcher expects to run is not started. As a
workaround (until restarts are an actual transition), listen for
the case where a task is restarted and invoke the end callbacks
Fixes: 286016555
Test: Repro steps on the bug
Change-Id: Iec3ab97c8817a5e95399cec90f891d65f369d234
Includes WINDOWING_MODE_MULTI_WINDOW closing target to the condition of
playing fallback animation. So the remaining splitting task won't be
play with iconview animation when home-key to auto-pip consumed another
splitting task in pip transition handler.
Bug: 281476331
Test: repro steps of the bug
Test: pass existing tests
Video: http://recall/-/fLARJNt42LVxc3tt86SneW/eelqATeE1REoOtOEDxeDVR
Change-Id: If05d8841a6a940e61f71683422ef1a3d4e3597c7
- The remote animation factory needs to be strongly referenced since
the only other reference is a weakly held one from
LauncherAnimationRunner, and if a gc happens in between starting
the animation and the onAnimationStart() callback, then the
animation will not play.
Fixes: 284106887
Test: Force a gc after creating a remote app launch animation and ensure
that the runner still exists when the animation starts
Change-Id: I5f584451b41c666916801b8ea0cb470c7ab9fc51
When switching in between two split pairs just quick enough, it is
possible to send the second entering split transition while it is
animating the first entering split transition which is merged to a
recents-during-split transition. The split parents might not be
collected into the second transition because the split parents are
already visible at that time, and there is no recents transition to
merge to. So updates to not throwing when there is no split parent when
composing a recents-to-split animation.
Bug: 236226779
Test: repro steps of the bug and the Launcher won't throw
Change-Id: I3a595722721186e8de7d60c9fb8c099ec799804a
For enter PiP animations started from Launcher, we send the signal to
WMShell to reparent the overlay under task as soon as possible.
This avoids flicker issue caused by race condition of cleaning up the
transition leash before the reparenting was done, which made the issue
of overlay being not attached to anything for few frames.
Bug: 281711939
Test: winscope trace from comment#28, leash follows task
Test: after http://recall/-/ekEuGtt9d9HWqkUtAzpHx8/ewrarENSYYOmUCa0b3fdtp
Change-Id: Ia16afd49a94d9ba8456287c2cdffb2a84e5a2bc7
Merged-In: Ia16afd49a94d9ba8456287c2cdffb2a84e5a2bc7
- The rotation button background does not change based on the current
light/dark mode
Bug: 288126260
Test: Check rotation button color with dark mode enabled/disabled
Change-Id: If4d5edfd4b118e4f16b6d472f206587e7cd61f98
This prevents the case where we are drawing both the taskbar bg
renderer and the stashed handle at the same time.
Fixes: 287245176
Test: go home/overview, open/close notif shade, stash/unstash in app
Change-Id: Ib025a0cf1ad5fd8a9afd079aa50210f3b2388d8e
Winson Chung
Jagrut Desai
Treehugger Robot
Hongwei Wang
Jon Miranda
Jerry Chang
TreeHugger Robot
Bill Yi
Vinit Nayak
Mateusz Cicheński
Alex Chau
Randy Pfohl