Slight revert of ag/10668129 with adjustment
of disabling it for tests.
Fixes: 151456795
Test: Ran the labtest command for OOP
tests for crosshatch (where this issue
was first detected)
Change-Id: I315d138c2e4a6d4068304e9b5fb2e1b7feb34e63
Bug: 144953948
Bug: 137777105
The new lite proto builder is used to send two types of logging to statsd
1) Snapshot logging
2) App launch, task launch, task dismiss
Statsd will be connected once platform CL is submitted
Change-Id: If606cee5288fe4bd6c522605ae84eb0f24174f5b
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
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
We had a max displacement for detecting pause before because people
were falsing into overview when they dragged all apps all the way
up. In this mode, there's no way to get to all apps from the nav
bar so the threshold doesn't make sense.
Bug: 151039912
Change-Id: I349f38ec1589f8b151cfbe32542159b3eb92bf61
If a user has has 0 apps in the hotseat, jump directly to showing predications.
Otherwise show migration dialog as usual and if user rejects it, show different tips based on the number of available spots.
Bug: 142753423
Test: Manual
Change-Id: Ic5202caf074db2409f6468dd9373875571f3f3c1
(cherry picked from commit aa2aff5a8f)
resume UI update for hybrid hotseat if user returns to launcher while app launch transition is animating.
Bug: 142753423
Test: Manual
Change-Id: I11ffa080bb78e7b4269747b1602b32d706f2405d
(cherry picked from commit 28f3136c6a)
resume UI update for hybrid hotseat if user returns to launcher while app launch transition is animating.
Bug: 142753423
Test: Manual
Change-Id: I11ffa080bb78e7b4269747b1602b32d706f2405d
If a user has has 0 apps in the hotseat, jump directly to showing predications.
Otherwise show migration dialog as usual and if user rejects it, show different tips based on the number of available spots.
Bug: 142753423
Test: Manual
Change-Id: Ic5202caf074db2409f6468dd9373875571f3f3c1
- Previous refactoring meant that we were always fetching the running
task to update the gesture state, even when you touch down in an
area that is not in the gesture region (which is unnecessary).
Also only transforming touch events (currently causes allocations)
when we are actually handling a gesture.
Change-Id: I32e21c3e4d7113a782afce593711d9df62551bc8
- Always just fetch the tasks that will end up in recents
Bug: 152133859
Test: Manual, swipe up with pip/assistant and verify nothing
changed
Change-Id: I41719e111cba85da7e93f65681b7b50b4c5c4a46
This flag is set by System UI in ag/10760162, when bubbles are expanded. We want to disallow system gestures from starting when bubbles are expanded, since otherwise a swipe up will both close the bubbles, and the app behind them.
Test: install launcher, add bubbles, open an app, expand bubbles, observe that swiping up only closes bubbles
Test: same but in three button nav, home button should both close bubbles + the app behind it
Bug: 146167884
Change-Id: I27ed225d2029e3cb82f4959739c7b6f25fe8adb7