Fix kotlin nullable errors that were exposed by setting the retention
of android.annotation.NonNull and android.annotation.Nullable to
class retention.
This relands I26edfec35dca14abe90b08e3c74de0446eda95d2 with a fix in
SplitSelectDataHolder.kt to call createPackageContext when user is null
instead of asserting that it is not null.
Bug: 294110802
Test: builds
Test: WMShellFlickerServiceTests
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:4cc251e6c1bd5e06ef24a92e08aae043cf3f2587)
Merged-In: I4525d0fa83a1db9cc5cff90f340fc3f863537c01
Change-Id: I4525d0fa83a1db9cc5cff90f340fc3f863537c01
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:2608381792389b60ba37c08afcea09dca3c6ff9c)
Merged-In: I26edfec35dca14abe90b08e3c74de0446eda95d2
Change-Id: I26edfec35dca14abe90b08e3c74de0446eda95d2
`MyDepthController` in `QuickstepTransitionLauncher` assumes that we
want the background to always animate the same way, matching the rest
state of the workspace (depth == 0). However, in Taskbar All Apps the
background is visible, and depth != 0. We now initialize the one-off
`DepthController` for launches to take into account the latest depth set
by the top level `DepthController`, so there is no jumpcut at the
beginning of the animation.
Note that in my opinion we should use the same `DepthController` for all
cases, rather than having this one-off. I'm looking into the feasibility
of that change, but for now this fixes the issue at hand.
Fix: 292959100
Flag: N/A
Test: manual, see videos in the bug
(cherry picked from commit 627d67549f)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:3e91646d123abbe58ccc0544746145ce5024b923)
Merged-In: Id90e8e728cc3e2ccf7d92148fbb0d6ff3e6fd6ca
Change-Id: Id90e8e728cc3e2ccf7d92148fbb0d6ff3e6fd6ca
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
(cherry picked from commit 6d756970e7)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:2e53f5ef97a02d25f508774e82985e24dc2f4d2d)
Merged-In: Ic437ff4d19cbd5764635f3007d99880622150f5b
Change-Id: Ic437ff4d19cbd5764635f3007d99880622150f5b
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
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
The lottie animations used for the gesture navigation tutorial are
designed for specific orientations depending on the device. This change
ensures that users are in the correct orientation for their device. For large screen users in portrait mode, we display a prompt to rotate the screen.
Flag: ENABLE_NEW_GESTURE_TUTORIAL
Fix: 277781713
Bug: 276515961
Test: Manually went through the tutorial starting from both
orientations on handheld, foldable, and tablet to ensure that the prompt
was shown and hidden correctly. Also ensured that gestures cannot be
completed in the background while the prompt is being shown.
Change-Id: I86ae566721f240264177ad4ec7fc12e58d1b95cd
Description: we wait for icon updates to receive the title of the task. However we still set the description immediately upon digitalwellbeingtoast creation.
this creates a null set for contentDescription resulting in incorrect talkbalk. This will listen for icon updates and will reiniitialize the toast ensuring
taskview is set properly.
Test: built and tested locally with talk back ensuring the titles are being set correctly
Bug: 280908761
Change-Id: I946e7190114cbdccb75883965b1fdf85ed6ad17a
