- 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>
For any view files applying the WidgetConatinerTheme via widgetsTheme they were incorrectly inheriting themes and skipping the AppTheme provided but only in light mode. In dark mode the WidgetContainerTheme.Dark was correctly inheriting the theme.
To avoid a risky theme update for all widgetsThemes we just modify the color accessor to use @color instead of ?attr as these colors should not be attributes AFAIKT
Bug: b/289305591
Test: Follow repro steps on the bug for smartspace
Change-Id: I26cc3239763f8eac3dfe5f094c6757692f46d1bc
- 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
It reports its size through SystemUiProxy and this tag causes it to
report the region twice. Additionally upon screen rotation the value
is getting updated with a delay, so for a moment two keep clear areas
for Launcher are present - one from the previous orientation (on the
side), and one from the current orientation (matching the proxy value
in unrestrictedKeepClearAreas).
Bug: 285242520
Test: before http://recall/-/ekEuGtt9d9HWqkUtAzpHx8/cLtiXGYUyItm2kNCCEkkWA
Test: after http://recall/-/ekEuGtt9d9HWqkUtAzpHx8/iPs6fwdSXG3TE0IERmxA8
Change-Id: I40dfe08680c944f2be5db0f6b15515492f409565
- 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