- 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 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
We had a resolved case in the past where an app's context menu didn't
open on a long click (thanks to app updates), now the menu opens, but
the drag gesture doesn't drag the icon.
Bug: 133009122
Change-Id: I45d104a92fab6556ecd937aef76f0a8147e67f56
This fixes the issue where overview doesn't come in from offscreen
the first time you enter overview from home.
Test:
- Force stop launcher, quick switch from home
- Force stop launcher, swipe up and hold
Change-Id: Ia4dbd36267008bc199cff088833979606238d3eb
We would like to assume a correct up-to-date layout for Go recents
before the remote animation begins to ensure correctness of the app to
overview transition and allow for animating all the newly laid out task
views in sync.
We do this by checking if recents is the remote target we are animating
to and if so, checking if the view is ready. If it is not, then we
delay the remote animation until the layout is finished and everything
is attached.
Bug: 132112131
Fix: 132108983
Test: Run Recents Go, have no tasks in recents, open app, press
overview to go to recents
Test: Test on AOSP and NexusLauncher that animations to Launcher work as
before (both to recents and to home)
Change-Id: Id74d90cffc9fe5db1dbb5fe63b8819c7436fef21
Workspace and hotseat are drawn in rotated UI giving the impression that the
device is in Portrait, even though it is in landscape
Bug: 131360075
Change-Id: I29c4068af25fd4dcf7039b9a45886e864a137977
Add setRecentsAttachedToWindow(boolean attached, boolean animate) with
the following conditions:
Conditions for attached
- Motion is paused and shelf is peeking
- xDisplacement > yDisplacement (to ensure seamless quick switch)
- We are continuing the previous quick switch gesture
- Gesture has ended and endTarget is RECENTS or NEW_TASK
Conditions for animate
- Recents is visible. Since the running task is invisible, this is
true if either an adjacent TaskView is visible, or if we’re
continuing the previous gesture
Currently the attach/detatch animation is just fading recents in/out.
Test:
- Swipe up to go home does not show the recents list at all. Instead,
all the visuals/motion focus on the app window animating into the
home screen.
- Recents appears when swiping and holding, to indicate that letting
go will land in recents. The shelf also appears with haptic feedback
in this case to reinforce this.
- The next task is immediately visible when quick switching (swiping
left to right on the nav bar).
Bug: 129985827
Change-Id: Ib0c16f583bfd5b02d2f9f68c9688edc980a39d75
There are 2 conditions that we force the MotionPauseDetector to treat
the motion as not paused:
1. If we haven't passed a small displacement (48dp before, 36dp now)
2. If we have moved mostly orthogonally
These existed soley for the OtherActivityInputConsumer case, because
1. We only need the displacement requirement to make room for the
peeking shelf, which doesn't exist in other cases (it's already there on
home for example)
2. We can only move orthogonally for quick switch, which again doesn't
exist for other users of MotionPauseDetector.
So now instead of checking min displacement and orthogonal distance
inside MotionPauseDetector, we let callers setDisallowPause()
before adding positions to their MotionPauseDetector.
The only user visible change is that you no longer have to swipe up 48dp
before we allow pause to overview from home. This also paves the way to
using the same logic that determines to disallowPause to also detach
recents from the window while swiping up from an app.
Bug: 129985827
Change-Id: Ie690aa314da3260aff2209341a29638604f9501c
We translate DragLayer when going to -1, so the exclusion rect was off
screen when you went back from there.
Bug: 129297464
Change-Id: Ie079b2dadaca07886408ee9c1d130d7ac351a61d
Chips in overview will be shown on top of the bitmap, not in
between the bitmap and the QSB, so we no longer need to shrink
the bitmap to make room for chips. This means that the appearance
of the recents view will be consistent between chips being
enabled/disabled.
Change-Id: I1856ccb8babd388ef6c8e6a1a5defcbdd0278a60
This allows us to revert the change that fades in the shelf during swipe
up in 2 button mode, since the shelf doesn't show up until the window is
out of the way anyway.
Bug: 129746879
Change-Id: I929d8095989f9eae32d71b5bc3f67997e9df4ba0
- Don't allow back gesture at all whenever we hid back button before
- Exclude RecyclerViewFastScroller thumb rect
Bug: 129297464
Change-Id: I40a33697592b02619218c18d1b3def7c3c203f56
