- Return the user to their previous state if quickscrub fails to launch
the new task (ie. if it finishes itself mid-launch).
Bug: 117163033
Change-Id: If03cf0431be40d9b81dfcc5dffcb2bf4844bbbd2
- Now that we are controlling the launcher app surface as well while
swiping up into overview, skip applying the crop to any opening
remote animation targets.
Bug: 70341013
Test: Swipe up, and ensure everything still works
Change-Id: I87b4021c0fc0e2997185d4d12f26b2e06999ff57
- Keep rudimentary log of the last few gestures for dumping with the BR
- Also renaming updateInteractionType since we only use it to change
to the quickscrub starting interaction type now, which is less
confusing
Bug: 112783625
Change-Id: Ic024684caf2841cd7c09df9481163ea0c0ae03bd
Bug: 115891474
Sending out the package name changing CL first before I make
LauncherIconsHandler and tests around it.
Change-Id: Ic10479a06333e1435b392a7072cd08782e710cbd
If for some reason, the animation is not created (eg in case of forced rotation),
we should also skip scaling down the icon so that the final UI is always in
a consistent state.
Bug: 78793089
Change-Id: Ie3e8b6d14b05ee983bc5e12401c1fa078034e392
This fixes the issue where dragging down on full screen apps was
offset by the status bar even though it shouldn't be.
Bug: 77979532
Change-Id: I8cb17778c4ae66b1821e86dd757626f875a27d2d
When controlling from launcher activtiy, there is no activity focus change, and rotation
lock is not required.
Bug: 114074832
Change-Id: Ia976f9daa9b0f87d3493138d12cb37a490b8b1bd
When using overview button, we skip the activtiy animation, which leads
to wrong state. Instead always running the animation and changing the endpoints
accordingly.
Change-Id: Id071b4e74da42c78760519aa29644621afc822e2
This makes is simpler to control the swipe to overview UI, and ties the
transition with the state machine
Bug: 113287120
Bug: 79755195
Bug: 112203163
Change-Id: I3041dbb659b46ccea6284855addc91e370815be6
- It can cause a deadlock with other synchronized calls on a background
thread that use a MainThreadInitializedObject
Bug: 112744388
Change-Id: Icbfe6fe84de41eeb19f68014905154dfca988288
- Offset distance based on where gesture started, so that the shelf is
always under your finger even if you swiped up high on the nav bar
- Use the same distance when swiping down to launch a task as we use for
swiping up from an app (so that the swipe feels more reversible)
- Allow swiping up in the gap between hotseat and overview, so there's
no "dead zone"
Bug: 109709720
Change-Id: I828d82e8feb250fd31e382d42aeefcb11d4a07d5
- Also move some allocations in ColorExtractor into thread locals to reduce
allocations
Bug: 78777731
Change-Id: I8819106d476a9af02e864135a2f44b55fe9219cd
Static dependency does not work in the presence of multiple activities and
when the main activity is not Launcher (eg in fallback recents). Instead
creating FirstFrameAnimatorHelper on demand for individual animations.
Change-Id: I17bb69bbaaca92f0db994fb56fd784302c57d543
(This cl reverts change-Id: I455edcd17bda83ab51c2c04fa40e66097a4d6975)
Various animations were marked for cancellation when launcher activity is
destroyed. This this does not work with multiple activities (Launcher,
fallback recents, shortcut confirmation). Also since launcher activity
handles configuration changes, the activity is not destroyed often.
Instead associating a target with various animations which automatically
cancels the animations when that target goes away.
Change-Id: I64cd095a28075561a9e20c9dcdeb9f90c18e1047
Now that pressing back launches the previously running task, it's
possible to get TaskView#launch() when the TaskView is not on the
screen (i.e. user scrolled before pressing back). In this case, we
shouldn't use the launch-from-recents animation, as that animation
assumes the task view is the current page or an adjacent one.
Change-Id: I7bec91c9437954061affdedc8cd9e48820ce7357
