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
- 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
The same surface can become invalid, in which case we need to wait
until the next draw to apply blur
Bug: 284411563
Test: Verified on device
Change-Id: Ifb6be94756fd00c5925e11a6b7d57f206e063a17
During each app launch, a new `MyDepthController` is instantiated, which
registers two of its methods as listeners for cross window blur and
opaqueness. This controller's usefulness spans that specific animation
only, but the listeners are never unregistered. This creates conflicts
when an opaqueness signal happens, which cause the background to flicker
(see videos).
Bug: 283335820
Test: manual, see videos in the bug
Flag: not needed, bug fix
Change-Id: I3dcb0b8ff0aa77bf3183a926889d0131b17bcaa4
Divider should hide immediately when going to launcher, this fix
the divider hidden delay in 3-btn-nav mode.
Fix: 283058496
Test: manual
Test: pass existing tests
Change-Id: Ia4eaba8020c564cc95b8652fe0f7066b653b9df4
A recurring class of null pointers are caused by using views with no view root implementation in SurfaceTransactionApplier from QuickstepTransitionManager. This can happen when we use launcher views after it has been destroyed.
- No longer using mDragLayer in getFallbackClosingWindowAnimators; simply applying the transaction immediately.
- Forcefully using getFallbackClosingWindowAnimators when launcher is destroyed.
Flag: not needed
Bug: 278833389
Test: launches and closed several apps in 3-button and gesture nav mode
Change-Id: I83b3aec1488fe9666bd0301a6044a181bb05dbdd
overridden
Bug: 280585150
Test: flashed device, and verified along with other changes in this
topic
Flag: ENABLE_DREAM_TRANSITION
Change-Id: Ic62ab51e0b95253127aa0c4fc8a4ea613afafaa3
Adding debug-names to remote transitions so that
they can be identified across processes
Bug: 276349701
Test: existing tests since this doesn't change logic
Change-Id: I41400feeb2dd91971f8c750613085c80af309aea
Use the screen based position instead of parent-relative position to
make sure the surface was placing at the expected position while
animation apps to home.
Bug: 273685456
Test: http://recall/-/fLARJNt42LVxc3tt86SneW/c2pLS6FwyEMweiLiWqqzPa
Change-Id: Iea79e6d2b9ab591fe18c5ac7a0d89bb90a461145
Schneider Victor-tulias
Luca Zuccarini
Stefan Andonian
Wei Sheng Shih
Fengjiang Li
Sunny Goyal
Andy Wickham
Johannes Gallmann
Hongwei Wang
Winson Chung
Jerry Chang
TreeHugger Robot
Kateryna Ivanova
Tony Huang
Treehugger Robot
Lucas Silva
Robin Lee
Evan Rosky
Jon Miranda