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
Overview chips are now shown on top of the SuggestView, so there is
no need to implement them separately in Launcher (now they live in
the AiAi UI library).
Change-Id: I49bfdcae7ed5ea3f1c40a539217579dfce5b3172
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.
Test: Checked value added to bundle
BUG:128982146
Change-Id: I24a276155e0564bba222859b150dc3696979d9b5
=> bumping detectable region to 48 dp horizontal + vertical within corner
=> centering detectable angle; total 70 degrees (ie. btw 10 off the vertical and 10 off the horizontal)
=> pilfering touch events when slop is passed and assistant gesture is engaged
=> Fixing issue where we were incorrectly using “sharedState” causing incorrect handling of gestures subsequent to AssistantTouchConsumer being invoked (it was forgetting to clear it’s input state and hence reporting “active” when it wasn’t). The symptom was that gestures after the AssistantTouchConsumer would never actually move the active window even though state was being updated; you’d feel the Overview haptic.
=> Devices with large corner radii are still somewhat problematic as the initial touch down often lands high on the display (ie. above the 48 dp region).
Change-Id: I3d5761112f4cb8b7b1eee987de5afe9aee260304
This is likely going to result in flaky tests, but we'll benefit more
from having these tests than not.
We'll track all flakes that are going to pop up as bugs.
Change-Id: I73902a1bce8181d522376ff912e238ec84ef1eed
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
This case originally existed to handle transparent activities, but in
reality it was hit most often when swiping up during transitions, i.e.
before launcher was stopped. So now we do the same thing regardless of
whether launcher was "visible" at the start of the animation: go to the
background state immediately and create our transition from there. This
looks a little strange if the activity truly is transparent, because you
can see launcher jump to the background state, but ultimately leads to a
more consistent experience (and the state animation we used before
looked super weird anyway).
Test:
- Open Calculator from the home screen and immediately swipe up from nav
bar (before animation finishes)
- Open Calculator from overview and immediately swipe up from nav bar
- Open Caluclator from all apps and immediately swipe up from nav bar
- Open Cortana (which has a translucent activity) from home screen,
then swipe up.
- Open Cortana and quick switch from it
- Open Rube screenshot (dialog activity) from home screen and swipe up
- Open Rube screenshot from all apps and swipe up
- Open Rube screenshot from all apps and swipe up and back down (ensure
launcher returns to all apps state)
Change-Id: I87bdbc6ddf41971fd327c807269c0bd94c97c95c
Now that we don't show DWB toast for negative remaining time
Bug: 127689526
Change-Id: I3ced3ec0da9bd7b09df9b66b4ef608e87339573f
(cherry picked from commit e921bacfb8)
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
Tony Wickham
TreeHugger Robot
Hyunyoung Song
Matthew Ng
Adam Cohen
Sunny Goyal
Govinda Wasserman
Vadim Tryshev
Miranda Kephart