- If Launcher finishes the animation, that also cleans up the screenshot
on the server side, so we can skip calling it
Fixes: 192684578
Test: N/a, adding a null check
Change-Id: Ia6b99b4262e72f925e7d622ea8833d3c88252633
- Previously we rely on whether launcher is resumed as a signal to see what "toggle" means. This no longer works since launcher is not resumed in Overview. Instead, we need to check the live tile signals.
- Use screenshot doesn't propagate after setting a new current task. So followed the logic around mRunningTaskIconScaledDown to work it out.
- Get rid of NavigationModeFeatureFlag, pending on 3rd party launcher change ag/14409355
Fixes: 185934639
Test: (1) Toggle overview from home screen and toggle back to fullscreen. (2) Toggle overview from app and keep toggling.
Change-Id: Iffaea18afb2179b5bb7dadda49e56efefa5658bc
Merged-In: Iffaea18afb2179b5bb7dadda49e56efefa5658bc
The issue is that in landscape mode we add overview shortcuts (e.g. screenshot) to the task view menu, where we switch to screenshot and finish recents animation before executing the shortcut action. However for shortcut actions like screenshot, we do the same, resulting in two chained "switch to screenshot and finish". This is a temporary fix for S given it's late in the cycle and we don't want to introduce unwanted regressions.
Fixes: 192272546
Test: manual
Change-Id: I7ef596e8bce6c15aa4a27163197beac12359b691
Fix: 186537288
Test: Repeatededly launch task from home and swipe to home, animation is correct
Test: Quick switch, launch task then swipe up, there is no jump
Change-Id: I9fd7416d9811ce4e54a1c6d20374d89d00417cd5
- Don't recreate the laucher transition controller if we've already ended it, as it could clobber a touch interaction that started in the meantime
- Test: swipe up from an app to overivew, swipe to dismiss it during the transition.
- Previously, we were ending the controller twice (once on touch down as we started proxying, and again in setupLauncherUiAfterSwipeUpToRecentsAnimation()), and the second one could happen after starting the dismiss interaction.
- Don't recreateControllers() if orientation didn't change
- Test: swipe up to go from an app to home, swipe up to all apps during the transition.
- Previously, we were getting the following sequence:
1. Touch down on home to start swiping to all apps - all current controllers get this down event to start determining whether to intercept
2. Before reaching touch slop, we recreateControllers(), so all new controllers won't get the down event and thus won't intercept
- Now, we avoid unnecessarily recreateControllers(), so the original controllers can still intercept.
Test: see above
Fixes: 189700453
Change-Id: I7b5fb3d21ab7a7a7044fcec7f2c1e39afe23c5dd
We need the icon to be full alpha during the init pass, then when
the actual animation starts, we can swap the icon with the window
(splash screen that draws the icon).
Bug: 192366079
Test: slow down window animations
check no empty frame on cold start app launch
check no empty frame on warm start app launch
Change-Id: I16a1779e5252d8e88bc3c408e1dc40b264fe4cf4
- In the case where we get a screenshot on cancel, we should wait to
finish the recents animation until the view gets a chance to update
Bug: 185643608
Test: Swipe up to overview in 2 button, hit home
Change-Id: I2ac3567006f6fa7e6f473499f6862e5e408dfc3d
Test: manual
(1) Upgrading to new DB version is successful (no errors thrown in logcat)
(2) Widgets that were added with the old DB version have CONTAINER_UNKNOWN as their source container
(3) Widgets that are added with the new DB version still log source container after reboot
Bug: 185778648
Change-Id: Iaa38f0be6bc4cb0d29842f9a2ea0d08de000c930
Color change updates recreate the view, which can interfere with the
widget-to-home return animation, specifically the GhostView's use of the
AppWidgetHostView's render node.
Deferring the application of color changes until the end of the
animation allows the widget to settle and remove the GhostView before a
color change might recreate the widget's view.
Bug: 190818220
Test: manual
Change-Id: I6552e583ebb0e4810077d4e70fe9ecb07fd5d01a
Previously we computed insets for task menu position
whenever a Task was told that orientation had changed.
This missed a path for the TaskMenuView's onScrollChanged()
listener, which also calls set position and wasn't taking
the insets into account.
Moved the inset into setPosition() directly so it's caught
on all code paths.
Also noticed 2 bugs where
* We were calling updateChildTaskOrientation() twice, it
already happens in the call to updateOrientationHandler()
* We were directly modifying insets from the activity's
drag layer instead of copying those insets to another rect
and then modifying (this is no longer an issue since we
are not touching those insets at all anymore)
Bug: 192400086
Test: Rotated w/ task menu open for fake and real
landscape. Nothing seems broken.
Note real landscape hides the menu whereas fake one
shows it (which was behavior before this change)
Change-Id: I613dac9519220f49285655ef11a1f72e4a6d31bd
> Updating background color
> Updating activity theme to not be transparent
> Updating default accent color
> Adding an accessible target to exit
Bug: 190447132
Bug: 190136972
Bug: 190454597
Test: Manual
Change-Id: Ia8ef67ed429c062a8d1109d7f444343ec4ca09cf
We'd like to be able to disable blurs during app launch, but without
disabling zooms as well. The previous sysprop would set the depth of
BackgroundAppState to 0, when what we want is to conserve wallpaper
zoom.
Bug: 191969790
Test: adb shell setprop ro.launcher.blur.appLaunch false
Change-Id: Ie4b26096f6ac723c3981bba2829557e6cc6c733b
- Use Builder for constructing SwipePipToHomeAnimator since the
parameter list grows
- Use mHomeToWindowPositionMap to adjust the position, this is to fix
the position issue when auto-enter-pip from split-screen
- The position map and its inverse does not seem to fit the case when
auto-enter-pip from landscape, leave it as it is
- Setup the SwipePipToHomeAnimator the same way in
createWindowAnimationToHome
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/b1j4eK7BU18sOGfuDlKMFR
Bug: 190749305
Bug: 190855091
Test: manual, see video
Change-Id: Ica9ca9f43b8fd5f1898fef4c6d173502dd897872
This way the wallpaper won't be zoomed out if an app crashes.
Test: adb am crash <some test app>
Fixes: 191979512
Change-Id: I7576798f736d63c3e46bbac1b983b9d1a437647d
Updated gesture navigation to use either a comma-separated string or a string array for defining tutorial steps.
Fixes: 184002732
Test: manual
Change-Id: Ib2f8f78ccd57100d978db799b785fd9dffe9fb7f
- With ag/15023409, the system will screenshot and cancel the recents
animation based on the hint provided by launcher when there is a
global config change. As such, we can remove extra handling of the
configuration change on the launcher side, and handle the cancel
with the provided snapshot.
To handle the snapshot, we need to hook into the gesture state
recents animation callbacks (which actually are of the lifecycle of
the animation and not just the gesture).
Bug: 189843542
Test: With live-tile enabled, swipe up to overview and rotate
Change-Id: If74f3fc5d47c327f9f5cca8f1f5d23b48cd3c954
for CUJ_APP_LAUNCH_FROM_ICON, CUJ_APP_CLOSE_TO_HOME,
CUJ_APP_LAUNCH_FROM_WIDGET and CUJ_APP_LAUNCH_FROM_RECENTS
Test: Local perfetto run
Bug: 190858586
Change-Id: I7a26d91c44a0a4c767bde3230d39a096a26d7b75
Anywhere that was using mResetGestureInputConsumer now uses getDefaultInputConsumer, which returns NO_OP if mResetGestureInputConsumer is null.
Test: none
Bug: 191684742
Change-Id: I1ae02b01a9629fa0830955dfe4d83c95a4759c14
- Don't recreate the laucher transition controller if we've already ended it, as it could clobber a touch interaction that started in the meantime
- Test: swipe up from an app to overivew, swipe to dismiss it during the transition.
- Previously, we were ending the controller twice (once on touch down as we started proxying, and again in setupLauncherUiAfterSwipeUpToRecentsAnimation()), and the second one could happen after starting the dismiss interaction.
- Don't recreateControllers() if orientation didn't change
- Test: swipe up to go from an app to home, swipe up to all apps during the transition.
- Previously, we were getting the following sequence:
1. Touch down on home to start swiping to all apps - all current controllers get this down event to start determining whether to intercept
2. Before reaching touch slop, we recreateControllers(), so all new controllers won't get the down event and thus won't intercept
- Now, we avoid unnecessarily recreateControllers(), so the original controllers can still intercept.
Test: see above
Fixes: 189700453
Change-Id: Icfa5b6cdb32122adaf6ac8e8cb197b0c477dac60
