There are 3 places we can block a fling:
- Swiping from home to all apps (through overview)
- Swiping from an app to all apps (through overview)
- Dismissing a task (in the same gesture that started by swiping down)
In all of these cases, we block the fling when crossing the threshold
to a new state (e.g. OVERVIEW), but unblock if the user pauses their
drag. With this change, the logic is consistent:
- Unblock the fling after pausing a short amount of time
- If a fling was blocked, increase the settling duration based on
velocity
Bug: 78089840
Bug: 78658678
Change-Id: I5ef52b74229418b867b26c3c6d3db2cf6e48914b
Previously, user-controlled animations weren't properly being canceled when a
non-user-controlled animation started, e.g. when hitting home. Thus, we could
end in the wrong or inconsistent state because the user-controlled animation's
end runnable was still used. Now we add a cleanup callback for when we reset
the user-controlled animation for one that isn't user-controlled.
Also fixed a couple typos.
Tests (easier with animation durations extended):
- Swipe up and hit home before reaching overview -> land on home
- Go to overview, swipe down slightly (before threshold to go to workspace)
and let go -> return to overview without flash (recents was resetting)
- Swipe up, press home while swiping -> goes home, stops responding to drag
- Start dismissing task and hit home before it finishes (or while dragging)
-> goes home, stops responding to drag
Bug: 78249220
Change-Id: If11d8999e3fadba38c987b25af67cd2304cd859b
I'm not sure how/when this case occurs (perhaps during some transition/state
change), but manually removing the floating view matches the symptoms in the
bug.
Bug: 72996404
Change-Id: I1e7c1a338fcd16c8e07b3c49fb9c9b2097eb2708
Previously we only allowed dragging the forefront task. Now you can
swipe up to dismiss the second task as well, but can't drag it down to
launch.
Also cleaned up page-scroll-while-dismissing logic to ensure it works
correctly in RTL and for new cases with dismissing adjacent pages.
Bug: 73187449
Change-Id: I1fe873c4cf1380b951dd3b2e396ab401ca1f7470
We now pass the log action (e.g. SWIPE or FLING) to the pending
animation, so that the end listener can log appropriately. This
is used when swiping down or up on a task, for example.
Bug: 73783784
Change-Id: I5c2eee24e8b23cf4af68d503d3435a6d8088dd8a
If you're ever in overview and swipe down on the hotseat, it will launch
the focused task *unless* you entered overview from the workspace and
have not scrolled past the first task. This is a hidden state to allow
for reversibility of the swipe up from workspace.
Also moved PendingAnimation from quickstep to launcher3.
Change-Id: Iea077bc0ef7c74f6bf7b98d0a638892b9c5fe36c
> Wallpaper based theme support
> Light/dark system UI
> Swipe gestures to start and dismiss a task
> Fixing insets and task preview size
Bug: 75979063
Change-Id: Id402e6ac50551a7c0849742e3a0e77df3ead5aa2
recents view and related classes.
This allows the common animation to be used in fallback activity.
Bug: 75979063
Change-Id: I2b5bf5e66406621305b9a076793434f9c5cecdfd
Sunny Goyal
Tony Wickham
Jon Miranda