When device is locked, only scale down the top task as a response to
the user interaction. When user flings or lifts his finger, the task
is dismissed to go to the lock screen
LockScreenRecentsActivity is an empty activity which starts on top of lock
screen and finishes immediately. This allows us to start a recents transition
with just the top activity as the animation target. This target is then used
for swipe up interaction
Bug: 133167096
Change-Id: I466ed142ea33d626c78cb9cc5f6311bad26b8d98
When the container was present, but empty, it was showing it's background.
Bug: 133783088
Change-Id: I97b65435d66e9ced7f5487dc50a00665794f8fcd
Tested: manual
- Previously, we clamped the progress to 1 when reaching mTransitionDragLength.
Now, we allow dragging all the way to the top of the screen, and store this
new top progress in mDragLengthFactor (> 1f).
- Because the launcher animation controller is inherently bound to a progress
between 0 and 1, we have to do a bit of trickery involving interpolators.
Specifically, we normalize the progress to 0 to 1 by dividing by
mDragLengthFactor, but then we set the interpolators to multiply their
progress by mDragLengthFactor. The result is that the animation progress
appears to go from 0 to mDragLengthFactor, just like the window progress.
- To avoid scaling too small, we start interpolating the progress at a certain
point, ending at a specified max progress when reaching the top of the screen.
Bug: 131741395
Change-Id: Ie8b4b56d37249cd1456f93c110c26c78fe052dc0
This eliminates an unreliable timeout.
Also removing an unnecessary check for harness that is done by the
called method.
Change-Id: If954580060415cbb2952532c16ea0ae4dc7b9469
If we are cancelled after the animation has completed, but before the deferred frame
was captured, we set the state as cancelled, and start the new consumer with the
existing recents controller.
But after the deferred frame, we finish the controller (and since the state was set to
cancelled, do not launch the new task)
Bug: 132756514
Change-Id: If30af713c76b6d895d0b01b93d31c0e1403b7214
- If screen pinning is enabled, disable gestures and wrap with input
consumer to break out of screen pinning (existing logic)
- If Home & Overview are both disabled, disable gestures completely
- If only Home is disabled, then always launch the user into fallback
recents (to simplify logic around breaking out of overview into Home)
- If only Overview is disabled, then prevent swiping from going into
overview or from triggering overview from home
- Switch to using screen pinning flag check instead of binder call
Bug: 133113732
Bug: 131698989
Change-Id: Ie6f447520d4cc3fa1eaaf8427ee014851688bf37
Constructor of PredictionUiStateManager posts an action in 5 sec, which
may interfere with the process of opening all apps.
Waiting until the posted action happens.
Hopefully this will fix massive flakes.
Bug: 131854153
Change-Id: I6544eae1a3b063c03e78185826c05a76add1f71b
This is to ensure the task thumbnail is captured in the correct
orientation, rather than waiting until after the task pauses
which might be after the device rotates to portrait.
Also update the state to wait until screenshot is captured
before finishing the transition to home.
Test: testStressPressHome
Test: Swipe up from a forced landscape app, enter overview;
ensure task view thumbnail is shown correctly
Bug: 132687470
Change-Id: I5cd5f4b2a413628a8bdcb456e2d132c1c2da5258
Sunny Goyal
Vadim Tryshev
Zak Cohen
Jon Miranda
TreeHugger Robot
Bill Yi
Winson Chung
Tony Wickham