Before, we did this by extending the window/launcher animation to
match the scroller duration. But now that we are using springs to
control the scroller, that duration is not really accurate. So
instead, we now let the window/launcher move at its own pace, and
wait for both that animation and the scroller to finish before
calling onSettledOnEndTarget().
Bug: 147302669
Change-Id: I37a9dd3eea17ebe663c33c3a4478b1b53a63dcc2
- When we have multiple wrapped input consumers, mConsumer will be
set to the wrapper while the caller can actually be the input
consumer being delegated to (ie. other activity ic). So we should
clear the consumer state if the caller is anywhere in the IC
hierarchy. This results in a separate issue where mGesture
could be cleared during onConsumerAboutToBeSwitched() before being
passed to the new consumer, so make a copy of the previous state
just for passing to the new consumer.
Bug: 152318829
Change-Id: I4afcef5b18aa772889e9104f3977887893f174ea
It also turned out that Pilfer event seems to come in a
non-deterministic order relative to the events from the Main and TIS
sequences. So I moved it to its own sequence.
Change-Id: Ie4ea5865afd900bebbd8287dad2372c94dce8ad5
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 e0ae1afd51 is in history
Change-Id: Ia06d98f7828808a72e4104c31bd13530b95ace5a
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 e0ae1afd51 is in history
Change-Id: I843ffef420f8ee6505e43b2af2267fbf3d725a2f
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: I96f6f711a0cd2c0895773cd735d46659c8bc64f7
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: Ibd73569eff678043d42dae23321649b3c616d1f0
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 e0ae1afd51 is in history
Change-Id: I801d74765e42d030771e0050e4c224e858fd2a9b
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: Ib6298a0a1c8cb384baa74dc7dbb0f435c4b4d3a4
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: I8805bfaa4ff1d0885afeb8c5918b82dc08eb4308
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: Ic5075d0e5ba3fc9f3ddeedf8972011adeec4ff2a
am skip reason: Change-Id I0665be5d585f64f3d43d42201a6529fd88247ca4 with SHA-1 6b6dbc3442 is in history
Change-Id: I9a81a86792e65be3455bf2e6d7d007a47075c60a
Unlike isStarted(), mHasLauncherTransitionControllerStarted is true
even after the animation has ended. Once it's ended, we shouldn't
continue updating it even if window shift is still changing.
This can happen when springs are enabled, as that can increase the
recents scroll duration beyond the window/launcher animation
duration (and we updateFinalShift() when the scroll changes).
Test: quick switch by swiping up and over at angle, or really hard
directly to the right, to engage the springs long enough to have a
few frames where you can notice the flicker before this change.
Bug: 147302669
Change-Id: I6a38662612de91352c0f956e6a3137f6c24eba66
Tony Wickham
vadimt
TreeHugger Robot
Hyunyoung Song
android-build-team Robot
Sreyas
Winson Chung
Sunny Goyal
Tracy Zhou
jayaprakashs