Currently if we open an app, unfold the device and then go to home
screen we will start the unfold animation preemptively in Launcher
because Launcher activity will receive updated configuration change
(where isTablet = true) only after going back to home screen, not
when unfolding the device.
This causes a problem because SystemUI won't send the unfold animation
events after going back home as the animation has already run, so we
end up with wrongly started animation in Launcher.
This CL fixes the issues by checking if SystemUI has finished the
animation (or if it is currently running) to avoid preemptive animation
start in this case. This is done by subscribing to the original
unfold transition progress provider which emits progress events
sent through IPC from SystemUI.
Bug: 285150685
Bug: 293131586
Test: open an app on folded screen, unfold, go to home screen =>
check that icons are not squished
Test: fold/unfold when launcher is open
Change-Id: Ic437ff4d19cbd5764635f3007d99880622150f5b
Merged-In: Ic437ff4d19cbd5764635f3007d99880622150f5b
(cherry picked from commit 6d756970e7)
- 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
Change-Id: I6875083931de63a8097d23d180553885ed7cfb01
Signed-off-by: Winson Chung <winsonc@google.com>
- 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 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
Change-Id: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
Merged-In: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
- 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
Test: built locally, recorded, and slow replayed it to verify no jank/visual anomalies visible.
Bug: 245750127
Change-Id: If7e72512d3303222f4d006a9e2a1639b2f86b1af
Change the strings for the instructions and feedback for the gesture navigation tutorial to align with new UX changes.
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fix: 286547594
Test: Manually went through the redesigned tutorial and verified that
the new strings correctly show up. Also checked that the previous
tutorial remains unchanged.
Change-Id: I27a3e8c0f09e7755e6087ce5b004b687f229d153
- Added a 6th hotseat icon to the tablet and unfolded foldable
- not animating the previous task view when animating to hotseat from the home step
- updating the first hotseat icon's color and visibility at the correct times
- cross fading the animating task view and hotseat icon's color
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fixes: 283967613
Test: ran the tutorial on handheld, tablet and foldable with ENABLE_NEW_GESTURE_NAV_TUTORIAL true and false
Merged-In: I7a76646ca71502e924f45bba76d72be17d31249d
Change-Id: I7a76646ca71502e924f45bba76d72be17d31249d
The lottie animations in the gesture navigation tutorial would get cut
off due to having to crop them to smaller devices. This change uses a
matrix to correctly scale the animation such that the aspect ratio is
maintained.
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fix: 283969417
Test: Went through the tutorial on devices of different sizes and aspect
ratios and ensured that the lottie animation isn't cut off.
Change-Id: I4b4cc9e11a68daef29fa31d6a89a1c9006041937
