Bug: 131436393
Test: Swipe to next task, before it can settle, touch and start quick
switching again
Change-Id: I568ec059be4c5c2f8c663980da0931c01d784f1f
Pixel1: 3-button
Pixel2: 2-button
Pixel3: 0-button
This is a temporary workaround for the listed bugs.
Bug: 130558787
Bug: 131419978
Change-Id: Ic57422c7ca8e9985fc0613239c803149e66d907f
In draglayer, we always dispatch touch events to child views. If the
touch originated from gesture area, when we dont route it through touch
controllers.
The proxy events are only send to touch controller. If any controller consumes
the event, then we cancel the view touch (pilferPointers)
This allows the controllers to work outside the dragView area, and prevents normal
view interaction when there is a window on top (like keyboard) while keeping our
activity focused
Bug: 131088901
Bug: 130618737
Change-Id: If033dde3a0f9cb6a6e449c9586c1fa050af5bdcb
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
Before, the soonest we initTransitionEndpoints() is in
onRecentsAnimationStart(), which might be too late if launcher was
killed. (In that case, the gesture might end before we ever get
onRecentsAnimationStart(), and thus will never consider the distance
traveled great enough to trigger recents since we don't have endpoints.)
Bug: 129723135
Change-Id: I349f62244aaba8369926b14f90acd994fd40a93a
- Add support for mMinScrollX to PagedView
- Add RECENTS_CLEAR_ALL_BUTTON as a state-specified visible element
- In BackgroundAppState, set Clear all invisible and bound RecentsView
scroll to the last task
Test:
- Open an app, quick switch until reaching the end, ensure Clear all
does not show up and an overscroll effect is performed
- Enter overview, scroll to the end and ensure Clear all shows up
- Same tests in RTL and 3rd party launcher
Bug: 130160876
Change-Id: I5fb958744d0055b83ced1f8b0d7face0e06a0cc5
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
Frame width is not used because navigation bar is always on the bottom.
Test: manual
Bug: 113952590
Change-Id: I48c29ffa4ca982a7aa20e2cced019e50580fe302
(cherry picked from commit 69a329e79e)
=> Using the drag slop (currently 10dp), which is the appropriate slop when comparing to the other gestures. Touch slop (which was being used for the Assistant) is only being used for gestures starting from the back button. This means that the delegate was getting triggered much too often (unfair slop competition). This prevents that.
=> Fixed additional bugs with the consumer delegate / sharedState; the shared state notion really only applies to the OtherActivityInputConumer, and it wasn't being propagated from the AssistantConsumer.In addition, the isActive() method is only being used as a proxy for whether or not to use the shared state, so clarified the naming. This fixes another case where touch could become completely stuck and you could no longer swipe up.
=> Modified the effective angle to be 90 degrees down to 20 above the horizontal.
=> Reduced the drag threshold to 55 dps.
=> Known issue: the time threshold requires motion events to be triggered. In practice, this works because the finger doesn't stay completely still, but we should add a timer to update the progress smoothly.
=> Removed pause detector.
Change-Id: Ie23e836c6d778914594774b830c3cd2e7b94eca4
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
This hides the quick search bar and the suggested apps. Visibility is
unchanged when the all apps view is fully expanded.
Test: Tested locally
Change-Id: I6bc453b5ad89ca3d1280957e595bf2a3f074a72d
BUG:129755311
FIX:129755311
(cherry picked from commit 917af755e4)
This will allow logging of the way that the Assistant gets triggered as
well as allowing the Assistant to modify its behavior based on how it is
invoked.
BUG:128982146
Change-Id: I5c7d6f317baeac3835a2ea193fe64856419dc2c4
TreeHugger Robot
Winson Chung
vadimt
Sunny Goyal
Matthew Ng
Tony Wickham
Hyunyoung Song
Adam Cohen
Govinda Wasserman