This ensures that any global animation scale applies properly
Bug: 327645429
Flag: NONE
Test: Manual
Change-Id: I12205429dca5a87208fa9964b3307fb718af4fd0
(cherry picked from commit f584b32811)
Other parts of the animation rely on currentRectF to remain stable, therefore we shouldn't modify the RectF object in place.
Bug: 323628523
Flag: NONE
Test: Manual, i.e. verifying that widget close (and app close) animation animates correctly regardless of device orientation
Change-Id: I48e9ed047b956db654192eef39e5d94fbac53553
This is so that they can be used within the Animation lib itself, while
remaining available to all current users, since the SysUI shared lib
also depends on Animation lib.
Bug: 323863002
Flag: NA
Test: still builds, tests still pass, manually tested areas that depend
on these utils.
Change-Id: I10de17b51c05054efe957ed1073a1cbe6baf05c5
Soon they will be used for both launches and returns, so these names
are more accurate.
Bug: 323863002
Flag: NA
Test: still builds (no functionality change)
Change-Id: I618780f0416a466a6672a2e694cb3e3ffd3f1396
Soon it will be used for both launches and returns, so this name is
more accurate.
Bug: 323863002
Flag: NA
Test: still builds (no functionality change)
Change-Id: Iaff2589401af24c6e9f604b3d7fa11e819fc941a
Bug: 323046568
Flag: ACONFIG com.android.window.flags.predictive_back_system_anims TEAMFOOD
Test: Manual, i.e. verify no crash for predictive back to home fallback
animation
Change-Id: I8bd5ddb3f97376a9d9bc4bdf1e3a55e7f53a192f
Change-Id: I1f53b3fafb8d508a0e0b67dda16eae36191f197c
Since anim is empty in the predictiveBack case, the animationEnd listener needs to be added to rectFSpringAnim instead
Bug: 318675970
Flag: ACONFIG com.android.systemui.predictive_back_system_animations STAGING
Test: TaplTestsQuickstep
Change-Id: Ibb3fd44c56b9d5370362f994762554eff02edbe6
Bug: 316873212
Flag: ACONFIG com.android.window.flags.predictive_back_system_animations DISABLED
Test: Manual, i.e. verifying on device that window corner radius matches the device corner radius during predictive back to home
Change-Id: Ided0a09597b88a75e82dbd2ff94e7d7af5fadaa9
In the predictive back to home case, no WALLPAPER_OPEN_ANIMATION_FINISHED_MESSAGE event was sent to AccessibilityManagerCompat, which caused TaplTestsQuickstep.testPressback to fail.
Bug: 318675970
Flag: ACONFIG com.android.systemui.predictive_back_qs_dialog_anim DEVELOPMENT
Test: TaplTestsQuickstep
Change-Id: I326577575d9e51e0f9ae879bca76e9c254f4ea34
Bug: 315149515
Flag: NONE
Test: Manual, i.e. visually verifying that wallpaper never jumps to a new zoom level with predictive back enabled
Change-Id: I17b12bdfd3ef5c9cffbc64df3d26ae140e506dc6
Bug: 311337169
Flag: ACONFIG com.android.systemui.predictive_back_qs_dialog_anim DEVELOPMENT
Test: Manual, i.e. testing predictive back to home on device and verifying visually that app icon behaves correctly
Change-Id: I91491d91d004d81f4abc67c361c8824eba8dfdcd
Wallpaper animation may be interrupted with an animation to go to Normal state.
Then the animation won't succeed, but it will still end.
Bug: 315074923
Flag: N/A
Test: presubmit
Change-Id: I15a106de78030f6935978539d333cc85ee95b4e7
This will help to ensure that Launcher state has settled before continuing the test.
Bug: 313926097
Flag: N/A
Test: presubmit
Change-Id: Ice7ae8a2517d68c53d135a34cc33e11f3203f788
Bug: 305934426
Flag: NONE
Test: Manual, i.e. testing back to home with different devices and device orientations
Change-Id: I3eddbc918de95be713aecb469501b01e6b7b3d3b
The two controllers don't own any unique state, other than the current
depth state. These two _should_ never diverge anyway, because there is
only one valid depth at any given time. By using the same controller all
the time we can enforce this invariant.
Everything else is basically just registered and unregistered listeners,
which the main controller already does properly and always has the same
state in that regard as the ad-hoc one that we're removing.
Finally we don't need to take care of any cleanup explicitly, as we did
before.
Bug: 293427436
Flag: N/A
Test: manual
Change-Id: If6ea68847a60254df76e806eac2679ae0415bfe0
Bug: 235915161
Test: Reproduced the issue locally, then verified that the fix worked as
desired without introducing unwanted side effects.
Change-Id: I3db3b2ddbd34a2ef19eae10282758df32c2d5b3f
This method recursively looks up the view hierarchy for a suitable view
to animate. The wrong variable was causing an infinite loop by never
updating the object being checked for the end condition.
With the fix, the animation behaves as expected.
Fix: 302568434
Flag: ENABLE_SEARCH_RESULT_LAUNCH_ANIMATION
Test: see video in the bug.
Change-Id: I123e50f1618a1e48256c0c976eeb46c93e8391b2
Merged-In: I123e50f1618a1e48256c0c976eeb46c93e8391b2
For a remote close animation target, because the orientation can be
different from launcher, so when launcher applying surface animation
to it, there should do another coordinate transfer based on it's
coordinate.
Also for closing animation, there shouldn't use #getWindowTargetBounds
because it only search for opening target.
There is no change when launcher's orientation matches animation target.
Bug: 254805643
Bug: 298318284
Test: close activity in each oritation, verify the position of remote
animaiton target is aligned with the floating view.
Change-Id: I7799357695a467f1bfc653e4f058a5e646ea2405
ActivityLaunchAnimator.Controller.fromView requires an instance of LaunchableView, however findViewWithBackground had no checks to return one. updated the check to make the exception less likely.
Flag: not needed
Fixes: 297564681
Test: ran launcher and launched apps
Change-Id: Iddbe55c1ff66b067f8456d058cbc60a2a698c4ae
Merged-In: Iddbe55c1ff66b067f8456d058cbc60a2a698c4ae
ActivityLaunchAnimator.Controller.fromView requires an instance of LaunchableView, however findViewWithBackground had no checks to return one. updated the check to make the exception less likely.
Flag: not needed
Fixes: 297564681
Test: ran launcher and launched apps
Change-Id: Iddbe55c1ff66b067f8456d058cbc60a2a698c4ae
We should also avoid using non-static inner class that extends IOnBackInvokedCallback.Stub and IRemoteAnimationRunner.Stub inside LauncherBackAnimationController, which references the entire LauncherBackAnimationController object.
1. When launcher is created, a Runnable is posted to ShellExecutor to call BackAnimationController#registerAnimation
2. When launcher is later destroyed, another Runnable is posted to same ShellExecturo to call BackAnimationController#unregisterAnimation
3. If the execturo queued the 1st runnable, then we have leaked LauncherBackAnimationController object, including Launcher activity.
This CL fixes the leak by making the Stub static inner classes, and use weak reference hold reference to launcher activity.
Bug: 297806573
Test: Grab a heap dump and this reference no longer exist
Flag: N/A
Change-Id: I78853e900a98399b02682ba2d9179e544a4030d5
`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
Change-Id: Id90e8e728cc3e2ccf7d92148fbb0d6ff3e6fd6ca
Sunny Goyal
Luca Zuccarini
Johannes Gallmann
fbaron
Anushree Ganjam
Vadim Tryshev
Schneider Victor-tulias
Stefan Andonian
Wei Sheng Shih
Fengjiang Li
Andy Wickham
Hongwei Wang
Winson Chung