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
There's an edge case where user isn't unlocked even if device is. In
that case, we still need to use DeviceLockedInputConsumer because
variables needed for any other input consumer aren't initialized until
the user is unlocked.
Bug: 129947426
Change-Id: I33a5e9a8d5c4266d45bd0d5a16657fa3c9644a1f
- Don't allow back gesture at all whenever we hid back button before
- Exclude RecyclerViewFastScroller thumb rect
Bug: 129297464
Change-Id: I40a33697592b02619218c18d1b3def7c3c203f56
More specifically, any window (e.g. qsb search) or AbstractFloatingView.
NavBarToHomeTouchController now implements TouchController directly instead
of AbstractStateChangeTouchController, as it not only dealing with
launcher states. This makes it easier to override intercept logic to
handle cases like not having window focus, for example.
AbstractFloatingViews can createHintCloseAnim() to play an animation
hinting that it is about to be closed by swiping up. Widgets sheets use
this to pull back similar to the all apps transition to home.
Bug: 129976669
Change-Id: Ie157b978d9f1ee36d5fd32cea72ec02ce40878c0
