WM is making changes which allows apps to maintain
their orientation independent of the orientation of
the foreground app. This allows recents to always start
in portrait even when the app currently running is in
landscape. This means we have to give the illusion of
a landscape oriented overview when user swipes up in
gesterual nav when launcher is started in portrait
configuration.
PagedOrientationHandler abstracts all coordinate specific
logic from Paged/RecentsView primarily, but also all
other dynamic calculations throughout launcher.
PagedViewOrientationState is the single point of exposure
to other classes that depend on those changes. The goal
is to also minimize holding state to allow for default
implementations of PagedOrientationHandler for all the
3p/Fallback classes. PagedViewOrientationState also
holds other data around rotation that isn't
specifically tied to view logic.
The fake landscape overview can be toggled with:
adb shell settings put global forced_rotation [0/1]
Fixes: 146176182
Change-Id: I65d8d4e9f92b93931cbe0053ccaf0cda8d2ffd6c
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
> Recycling DigitalWellBeingToast so that the view is not inflated everytime
> Simplifying DigitalWellBeingToast to use a single text view
> Adding support for footers in taskView without creating additional layout
Bug: 122345781
Change-Id: Ia889819b93eb8644532ea95c6767554874d5e2d1
When the container was present, but empty, it was showing it's background.
Bug: 133783088
Change-Id: I97b65435d66e9ced7f5487dc50a00665794f8fcd
Tested: manual
This ensures that they do not fight for the space. This is intended to
be iterated upon as we find solutions to some of the technical
challenges in the current POR.
Change-Id: I831e8797b16f28fe2cd742c96e9b7c916abf77a5
This replaces all other chips containers and causes minimal
layout overhead: It is strictly within the task itself and
causes zero jank or space issues.
Screenshots:
https://drive.google.com/corp/drive/folders/1-3ZNCJtWc9_cgmP1nNd8U1yvpCr6GGoq
Test: manual
Change-Id: I5e22a34c4dc1ac3e73c4d5c913befc2360cb388e
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
Now that we don't show DWB toast for negative remaining time
Bug: 127689526
Change-Id: I3ced3ec0da9bd7b09df9b66b4ef608e87339573f
(cherry picked from commit e921bacfb8)
