This also enables the gesture when notification shade is down, as we do not have
a separate shate for that right now
Bug: 131847153
Change-Id: Ia1edaad197266fe01b5de7b2a6b46ca0ec6428bb
- Launcher always controlls sysui flags during quickstep gestures.
- If we passed window threshold (i.e. window isn't under system
bars), use same flags as home screen
- Else use sysui flags of the centermost TaskView
- Update sysui flags based on home animation progress as well
(otherwise we weren't applying home screen sysui flags until
the end of the animation if you ended the swipe before crossing
the window threshold).
- Update sysui flags for quick switch from home
- Specify that the activity controller animation is user-controlled
so we don't reapply state when re-setting it. This happens when
we get window insets, for instance, which we get when changing
sysui flags.
Bug: 131360249
Bug: 130020567
Change-Id: If82dbf75fe663fd690b816cdc1c4366cc2bf75b1
- Calculate point on icon path nearest to top right corner, and
use that as center for the dot
- Cleanup code related to dot offset
Test:
Set each style (different icon shape) and verify dot is in correct
placement for each of:
- Folders
- Icons in folders
- Icons in all apps
- Icons on workspace
Bug: 124414511
Change-Id: I036ed3677e8af222f00d4fad4a36a7e4d9b49ad9
- Detect when start of the next task is interrupted with another gesture
(after finishing the recents animation but before the next task is
launched), and ensure that the next gesture is continued with another
other activity input consumer (but without actual remote animation
targets)
Bug: 128376812
Test: Introduce artificial delay in recents animation finish, try to quick
switch quickly
Change-Id: I057a0b2c4b7e8636467e37f5bbc8800b46c24345
Don't wait for drag slop before determining whether we are likely
to quick switch (xDisplacement > yDisplacement). One glaring issue
is that we only pass drag slop when swiping up, not sideways...
so to pass drag slop going sideways we actually had to pass touch
slop (24dp vs 10dp) and by that point the adjacent task was probably
visible if you swiped fast, and thus we faded it in. Now we only
look at raw displacement for purposes of determining whether we are
likelyToStartNewTask, which should be much more consistent.
Bug: 129985827
Change-Id: I31f8a9830681851093de2ce159da1a1dc4f7ef6a
Comparing only widget provider class names, as package names (sometimes)
switch to the test package, not to the ones in Launcher.
Bug: 131116593
Change-Id: Ieeed69432303a86fcefb194d509cdaf9d4513f3a
It fails in the lab, and locally, when being run as a part of the whole
test suite.
Bug: 131772711
Change-Id: Ida5f384eb7115303e1315928822566150e1d852c
onConfigurationChanged is only passed down to views that are currently
attached. Naturally, a recycler view has some views in its pool that are
not attached and thus do not get the call when the orientation changes.
When this happens and the view is then attached later, it can be in an
incorrect orientation.
To fix this, we save the current orientation the task item is using and
check on attaching if it's still the same as the orientation the device
is in. If it isn't we then run the orientation change logic.
Bug: 131848689
Fix: 131848689
Test: Change orientation with some views not attached, see that they are
correct orientation when attached
Change-Id: I3dec501c332338444e321b4a50876c7840a5bc6e
Test (all in multi window and non-multi window):
- Quick switch from home screen
- Quick switch from an app
- Swipe up from an app (slowly)
- Swipe down on a task (slowly)
Bug: 131689686
Change-Id: I69bf6dd1a34904cdf5ec7febea8f858012e2a0ac
