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
=> 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
=> 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 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
Bug: 129785904
Test: Try to swipe up with various sysui states enabled
Change-Id: I654e0efd1f29ee6b4123e7f8aa717f62a55fdb50
(cherry picked from commit f0625fd93a)
Bug: 129785904
Test: Manual, change states and verify state is sent
Change-Id: Ia1f69494a6cbae68085fb09670ffa309ce147430
(cherry picked from commit c4b88c3dfb)
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