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
Logging assertion failures.
Modifying waits for condition to avoid timing out the whole test if the
iteration takes too long in favor of failing with an actionable diag.
Bug: 145985438
Change-Id: Ie32d93e1548ce6ec64c38449eb1be1287ff9cf56
- In the case where the recents animation is canceled while the running
window animation is running, we invalidate the handler, and force end
the window animation, which results in the end target being calculated
and transitioned to. Because the handlers can still reference the
animation controller at this point (even though the calls will be
no-ops since it was canceled), we should not reset the vars until the
state has been updated.
Bug: 145641576
Change-Id: I5a660026fabb5beb0c45dffeeb4cb4feef5dec30
Updating various static objects to use a standard pattern so that
it is easier to track and cleanup those objects
Bug: 141376165
Change-Id: Ia539cbfa338d544dddad771c5027b6748762768b
> Changing the lifecycle to follow other static objects in Launcher
> Removing compat interface and inlining everything to helpers
Bug: 141376165
Change-Id: I82bd5db1969101de9a7eac77f32728d70195bb35
Only the FallbackSwipeHandler supports quickswitch mode on the
home screen, but we only used that handler for fully gestural
mode. Now we also use that handler for 2-button mode if both
of these conditions are met:
- User is on the home screen
- User swipes right on the nav region (instead of up)
Also fix issues with continuous quick switch gestures by setting
the appropriate end target NEW_TASK instead of HOME.
Bug: 140467002
Change-Id: I8f327638b48cf4c0acb1ebe265b7846afac6759b
Improving state events accounting hasn't completely solved flakiness.
I've noticed that swiping up in 0-button mode sometimes doesn't open
Overview.
Bug: 143488140
Change-Id: I660885ed556aa2953c17d491fde267734b95890b
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
Checking for events whenever Launcher sends them.
Checking for correct events (final events, not for events from
intermediate state changes).
This should simplify diagnosing of bugs involving TAPL.
This is also supposed to fix Fallback overview tests.
Bug: 143488140
Change-Id: If053ed808ec71bf2b652ab680be5bdfe9ff8cbb9
Also keep the 3P launcher's alpha at 0 during the gesture, and
don't send the home intent if user touches during the transition.
Bug: 139682945
Change-Id: Ie758f0b337bb173b34f5585ec1915b7ea1145094
This just crashes since we can't access SharedPreferences, and we don't
addPluginListener until onUserUnlocked() anyway.
Change-Id: I705498f859857a52a2cb5735201a652973b26d0b
- The bug is caused by cancelling of the RectFSpringAnim before the
StaggeredWorkspaceAnim has started.
- Instead of having logic in StaggeredWorkspaceAnim control the visibility
of the icon, we instead maintain all the visibility within the
FloatingIconView class itself.
Bug: 142120338
Change-Id: I94f3a066d395f9c3b97dc6ee9fc836e9401650a5
Merged-In: I082291ca9b288f57701cc00d61a9b3a84da8b084
- The bug is caused by cancelling of the RectFSpringAnim before the
StaggeredWorkspaceAnim has started.
- Instead of having logic in StaggeredWorkspaceAnim control the visibility
of the icon, we instead maintain all the visibility within the
FloatingIconView class itself.
Bug: 142120338
Change-Id: I082291ca9b288f57701cc00d61a9b3a84da8b084
When flinging up and to the right, we previously always returned
home. Now, if the right velocity is stronger, we quick switch.
Bug: 126596417
Change-Id: I14fa0584399bb90f2e07e0b296fc5932d8224fbf
We were previously offsetting the launcher animation progress based
on when we got onGestureStart, which meant it would lag behind if
onGestureStart came late. Now that we track the window instead of
the launcher shelf, and we don't show the launcher animation right
away in fully gestural mode anyway, we should remove this to ensure
the launcher part of the animation always lines up with the app
window.
We also reapply state whenever predictions are enabled, e.g. when
launcher starts after being force stopped, and previously this was
canceling the existing state animation. We don't want to do that
because predictions can be enabled at any point on a cold start,
and cancelling the existing state animation means that RecentsView
shows up in fullscreen and not attached to the app window for the
duration of the gesture.
Bug: 144454486
Change-Id: I65a2c71c9acd2f5345941ea2cff7d32c04b7be3f
Merged-In: I65a2c71c9acd2f5345941ea2cff7d32c04b7be3f