Starts by showing a notification, which will open a dialog
with options for users to keep their hotseat layout or fully
migrate to hybrid hotseat
Bug:142753423
Test:Manual
Change-Id: I178de612837ec8551f6776fa7c6fb6111bc7431d
include actual implementation of gesture tutorial.
Bug: 146173041
Test: adb shell am start -a \
"com.android.quickstep.action.BACK_GESTURE_TUTORIAL"
Change-Id: Ic166f0a10d8efc22d9684f089142de164ca24c90
import various resources from tips gesture tutorial
Bug: 146173041
Test: build and verify it passes
Change-Id: Iacea7ba1f2d15452e7442f2976633da7012fab35
Two changes for the latest Compose prototype:
1. Pass the identity of the underlying app to the Overscroll plugin.
2. Enable the Compose gesture over an app when there's a Recents extra
card plugin active (otherwise the current app won't count as the
rightmost one).
Some changes to the gesture:
- Angle decreased from 35° to 25° to remove overlap with
Assistant gesture
- Distance increased from 8 to 110 dp. 110 dp is 2x the Assistant
gesture and roughly the same as scrubbing into an app from Home.
- Fling detection added; uses same distance threshold, 110 dp.
- If a touch was recognized as another gesture, the touch will not be
reinterpreted as a Compose gesture, no matter what touch movement occurs
- Fixes issue where Assistant + Compose could both be triggered
- Fixes issue where scrubbing apps to the left, then back to the right,
would bring in Compose. i.e. if a touch down + touch movement starts
bringing in Assistant UI elements, then, the user moves their touch
below the Assistant angle, the Compose gesture will not start
being recognized
- Gesture length required for fling lowered from 110 dp to 40 dp, per
tuning with PM.
Bug: b/146508473
Change-Id: I414573d1a92684d1d992837a5f1df522346ec211
Add the actions to the task overlay to simplify code sharing.
Test: added unit tests for controller
Change-Id: Ie497a717b189903cc1834685f4b7d0cb926a7f52
There were two descriptions before, one saying Overview and the
other saying Recent apps. Now we always use Recent apps.
Bug: 145181858
Change-Id: I0d33fdccb30ad3eb56ebfb3d533ea01c2e7866c1
Adds ENABLE_OVERVIEW_ACTIONS feature flag and base factory. Requires an
implementation in overlay to show any actions.
Test: run locally with flag on and off.
Bug: 145628186
Change-Id: I1c36330464cc01e1e987ebfea1a9f451067598a5
Test:
1. . build/envsetup.sh && tapas NexusLauncher
2. ccdebug && cclogcat
3. launch from workspace any app that is also in predicted apps
4. verify in terminal it has correct predicted_rank
Bug: 143855018
Change-Id: I07a62f07057537a6c09384cf944bbc5aa5888d22
> Connect to a predefined content provider to get package specific action
> Add that action to shortcut menu and task menu
Change-Id: Ide5c09d04112e86c8e19c2f9e66c88c15b3fd04e
It was possible to invoke the assistant accidentally. This change
adds a minimum distance threshold before we register a fling (the
same distance as used for drag, 55dp).
Bug: 137106918
Test: manual; tested that accidental flings were much more difficult,
but intentional invocations were still easy to register
Change-Id: I40c8bd43c1a28c7b161467804a1e44746b8e92ef
- Peek in overview further, and with more overshoot
- Fade out and scale down workspace faster while swiping up
- Scale and translate workspace slower when letting go to enter
overview (so it doesn't zoom out at warp speed)
- Fade in all apps shelf sooner
Bug: 132455160
Change-Id: Ieafad0ccf9bb587889bc35d536627661db10e358
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
=> 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
=> 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
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
Add AnimationComponents.ATOMIC_OVERVIEW_PEEK_COMPONENT, and rename
previous ATOMIC_COMPONENT to ATOMIC_OVERVIEW_SCALE_COMPONENT.
When SWIPE_HOME is enabled:
- Overview lives to the left of Workspace, which is encoded in
LauncherState.NORMAL.getOverviewScaleAndTranslation().
- Create atomic animation based on ATOMIC_OVERVIEW_PEEK_COMPONENT
and OVERVIEW_PEEK state when swiping and holding from home screen.
Bug: 111926330
Change-Id: Iab6dbef7238dae15b3036d4b2a026b781eee6b4b
The reason is that there is no API that reports that an app is grayed.
Not showing DWB toast for apps that ran over their limit because they
shouldn't be in Overview.
Bug: 129067053
Change-Id: Ia04e17aa85ca015b7932496ad5e730fe61b4be69
The corners will be separated with quick switch by detecting at the slop
of the angle from touch down to that position. If over 30 deg then
assistant will be tracked otherwise quick switch while swipe up will not
be tracked at all.
Test: manual
Bug: 112934365
Change-Id: I6a3aeb1509d9706696a30ef1fba3ce7e3e5ec07c
- Orthogonal displacement now checks angle instead of fixed amount
- Only allow timeout when passed min primary displacement and not
orthogonal displacement
- Don't set timeout for !SWIPE_HOME, which should never detect pause
Change-Id: I3d810831316affff138968dfc62b921b20c752c5
- Add max orthogonal displacement to MotionPauseDetector to avoid
pausing when swiping left or right
- When gesture in ambiguous between swipe up for home or swipe over
for the new task, base the decision on the faster velocity component
- Disable recents freescroll mode when dispatching motion from the nav
bar. This way recents handles it naturally and we don't need custom
logic to snap to the next page at the end of the gesture.
- Fix a bug where you couldn't hook to start a new task when SWIPE_HOME
was disabled
Bug: 111926330
Change-Id: If63aa2bb32b57c3f401c5df8b3f6f4efec97b1fa
- Pause (swipe and hold) detection based on velocity and acceleration,
so it feels immediately responsive
- Don't show shelf during swipe; peek when swipe pauses
- Disallow long swipe
- If swiping to go home (we didn't detect a pause), animate window and
launcher together (not final animation, but mechanism is in place)
- Guarded by SWIPE_HOME flag
Bug: 111926330
Change-Id: Ie4af04517c6688e3d649c2971a1aad197837cb3b
