Fix kotlin nullable errors that were exposed by setting the retention
of android.annotation.NonNull and android.annotation.Nullable to
class retention.
Bug: 294110802
Test: builds
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:4aef83aa32df00c3d3e7c4cc239a08299c3b7d7d)
Merged-In: I158db4f57d46606d7152a438d68e2b9f4c0014d9
Change-Id: I158db4f57d46606d7152a438d68e2b9f4c0014d9
Fix kotlin nullable errors that were exposed by setting the retention
of android.annotation.NonNull and android.annotation.Nullable to
class retention.
Bug: 294110802
Test: builds
Change-Id: I26edfec35dca14abe90b08e3c74de0446eda95d2
Merged-In: I26edfec35dca14abe90b08e3c74de0446eda95d2
- The second start activity was causing issues with 3p launchers which
may not expect another new intent (ie. if it handles gestures at
the bottom of the screen). We can't completely remove this logic
because for button navigation we don't want to fall through to the
launch-next-task animation below, but we can can continue to
finish the recents animation immediately.
- With shell transitions, leashes for opening apps are always hidden
by default so when transitioning to a 3p launcher from
RecentsActivity we also need to show the surface if we want to
animate it in
Bug: 289609734
Test: Set 3p Launcher as default, in both gesture & button navigation
- Go from 3p home -> overview, then overview -> 3p home
- Go from app -> 3p home
- Go from app -> overview, then overview -> 3p home
- Quickswitch from app
Signed-off-by: Winson Chung <winsonc@google.com>
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:2b3dc6f73007f8b7d97ae2972e37c5d055659c8b)
Merged-In: I6875083931de63a8097d23d180553885ed7cfb01
Change-Id: I6875083931de63a8097d23d180553885ed7cfb01
If the onRecentsAnimationStart callback runs after the user lifts their finger and onFlingFinished runs, then onFlingFinished never has another chance to run, leaving the user trapped in a state where the launcher is not started and the AllSetActivity is still present but invisible. Reverted to allow onFlingFinished to run onRecentsAnimationStart to handle this edge case.
Flag: not needed
Fixes: 285194839
Test: Ran AllSetActivty with a delay in onRecentsAnimationStart
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:1b2c2e694c6e233057570d3e8b4e5a0aa9c0c51a)
Merged-In: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
Change-Id: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
- 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
Signed-off-by: Winson Chung <winsonc@google.com>
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:ccd359d76c7f42d4fc799f19d54a66c7c2fa462a)
Merged-In: I43e473faf4fa2a493b9705506e3755df8f6264e7
Change-Id: I43e473faf4fa2a493b9705506e3755df8f6264e7
- 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
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:6f7e15ff644bac2f11ecb779030255efebc18885)
Merged-In: I3657c000cbc8c14c9ac989c2a57715515c96edb6
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
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:57c2a79e47bc583306bd77ea3039d821a8d33dde)
Merged-In: Iec3ab97c8817a5e95399cec90f891d65f369d234
Change-Id: Iec3ab97c8817a5e95399cec90f891d65f369d234
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
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:97eb471f2efda1eccce7eba8c68301b2fa34c5e7)
Merged-In: I3a595722721186e8de7d60c9fb8c099ec799804a
Change-Id: I3a595722721186e8de7d60c9fb8c099ec799804a
- 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
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:6cfe2e6cbe52f5fc9aa0eb94afaeb7679810cc13)
Merged-In: I5f584451b41c666916801b8ea0cb470c7ab9fc51
Change-Id: I5f584451b41c666916801b8ea0cb470c7ab9fc51
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