* Tracks either the top or bottom of the rect for the fling/spring in the
Y direction.
- This allows us to have the icon always animate downwards.
* Scales the spring velocity for the Y component.
Bug: 124510042
Change-Id: I47571f906c8aa1beca4dd703d67d013ab6a1161f
This reverts commit 904c429b99.
Bug: 130451254
Test: manual
Reason for revert: found a better way to extract scrim colors without going through OverviewProxy
Change-Id: I435b7b20f87fbf2fc4e6b7415b981ce2fa4f8eab
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
This reverts commit 426d3650ae.
Reason for revert: the revert CL can be cp'ed to ub-launcher3-master to fix the build breakage until new sdk drop happens on master.
Change-Id: I59dcbb20fc9b700623d72ba047a471745dfac847
This reverts commit d849ef084c.
Reason for revert: not needed
I was too eager to merge this CL. It turns out all I need is these
three constants and doesn't actually need the aidl change.
public static final int MAIN_COLOR_LIGHT = 0xffdadce0;
public static final int MAIN_COLOR_DARK = 0xff202124;
public static final int MAIN_COLOR_REGULAR = 0xff000000;
Change-Id: Iafd539a06455ba0878a6d3750f3c7194f8919fbf
Bug:129421797
Test: Flashed to QP1A.190508.001, installed launcher with change.
Observed both home and overview predictions were as expected.
Change-Id: I127d489eae382f4cee75afdd6d615d6d7a8227ee
Currently, we cannot support the split-screen mode on the secondary
display. To prevent confused,disallowing split-screen request on
non-primary display tasks first.
Bug: 118266305
Test: 1. Use the ActivityViewTest to launch an application on virtual display.
2. Check if the split-screen button exist on recent app.
Change-Id: Ifa6d70a1920aa4f33d260e37a3737e102949114e
We would like to assume a correct up-to-date layout for Go recents
before the remote animation begins to ensure correctness of the app to
overview transition and allow for animating all the newly laid out task
views in sync.
We do this by checking if recents is the remote target we are animating
to and if so, checking if the view is ready. If it is not, then we
delay the remote animation until the layout is finished and everything
is attached.
Bug: 132112131
Fix: 132108983
Test: Run Recents Go, have no tasks in recents, open app, press
overview to go to recents
Test: Test on AOSP and NexusLauncher that animations to Launcher work as
before (both to recents and to home)
Change-Id: Id74d90cffc9fe5db1dbb5fe63b8819c7436fef21
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
There were a couple cases where swiping up showed the adjacent task
even though we had set it as detached from the app window.
Test:
- Launch an app from all apps, swipe to home
- Force stop launcher, swipe to home
Bug: 129985827
Change-Id: Ib8a836e3cc467d44be601d81e3a7d04d6487c968
- 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