`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
Prior to this change, if taskbar is showing and we are cloing an app
that is visible in the taskbar, the taskbar view would immediately
disappear.
Now we will fade out the view until the animation is 33% complete,
at which point the 'space' will be clear for the FloatingIconView
to settle at its final location.
Bug: 273961611
Test: open app in hotseat
note that the taskbar view is gone immediately
have taskbar visible, close app that is shown in taskbar
note that the taskbar view fades out
Change-Id: I5589e2ce3033cfa19669d1bfaf568aef2a96015e
with a taskbar.
Thought about using the Builder pattern here but the CL becomes
much larger due to SwipePipToHomeAnimator having its own
Builder.
Bug: 268026344
Test: swipe up to close app thats in hotseat
swipe back to close app thats in hotseat
Change-Id: Idd0729224374579753fc91c7820f3b04a7d3e1a4
For apps that use AdaptiveIcon, we used to animate the foreground
drawable independently from the background. This is sometimes
perceived as jank so we remove the animation since it is very subtle
in the best case scenario.
Bug: 268026344
Test: open/close apps/folders that use AdaptiveIcons
Change-Id: I500bf56e04823757d511d909a93d3b30703249a1
Bug: 246635237
Test: open app in hotseat
close app in hotseat
the 'matching' view in taskbar should be hidden
tested icon, predicted icon, folders in taskbar/hotseat
Change-Id: I74382480826afafe6ae58e78faf26fe10812e29b
