| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| |
| | |
ub-launcher3-qt-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While removing unused files in Go version of quickstep, I removed
QuickstepProcessInitializer which seemed unused but is actually
initialized as a resource based ovverride. This CL puts it back as
common src so that both Launcher3GoIconRecents and the rest of the
variants all use this class.
Bug: 135472635
Test: Run Launcher3GoIconRecents => no exception
Test: Run Launcher3 => no exception
Change-Id: I56f319bac536ec4da96285fab932fe574afa4520
|
|/
|
|
|
|
| |
Bug: 135473571
Test: Manual, try restarting with no default launcher set?
Change-Id: Ibb68070ee95ca856b38a74823bcbfbc7890f329e
|
|
|
|
|
|
|
| |
For app close, we already load the icon as soon as we can.
Bug: 135130011
Change-Id: Ia2c45737cf24d1ab5911b222ae097d7a1f9d6a31
|
|\
| |
| |
| | |
ub-launcher3-qt-dev
|
| |
| |
| |
| |
| | |
Bug: 133443741
Change-Id: Ifd6a289b7f49d52efe0767b600cecc2b460a87fc
|
|\ \
| | |
| | |
| | | |
ub-launcher3-qt-dev
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When quick switching from home or overview, go to OverviewState if the
task launch failed. Otherwise we get stuck in BackgroundAppState.
Bug: 135038270
Change-Id: I42785c261cef0df95666bc106ec5ca6ef0553cc7
|
|/ /
| |
| |
| |
| | |
Bug: 134725160
Change-Id: Ia4c5e0eefc4d8b869840645f403d943831c471f1
|
|/
|
|
|
|
|
|
| |
When attaching recents, translate it offscreen and use a spring to pull it
into position. When detaching, use the same spring to pull it back offscreen.
Bug: 129985827
Change-Id: I05339e2ec0932070365023bfafc83cbf2a4e178e
|
|
|
|
|
| |
Bug: 134095068
Change-Id: I8603e49a85b5524a02c9085485a180b022e3f91e
|
|
|
|
|
| |
Bug: 123900446
Change-Id: Ia8ff74eb6b65affbf5c6c1599f4d168b459f324e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When ending in recents, we reapply the state - therefore, it's important
to make sure we are in OverviewState before onSwipeUpComplete(). This is
done by mLauncherTransitionController, which sets OverviewState on end.
We already force mLauncherTransitionController to end before calling
onSwipeUpComplete(), but in this case we were calling cancel() and
setting mLauncherTransitionController = null, which meant we could never
call end() on it. Instead, we should always call end() if we set it to
null.
Also ensure mLauncherTransitionController is created even if the gesture
is completed, if an existing controller isn't already running. This can
happen if you swipe up quickly enough that we get onGestureEnd before
launcher is drawn, and in that case we still want the launcher component
to animate once its ready. This is even more important for 2-button
mode, because again, we rely on mLauncherTransitionController to set the
state to OverviewState before we reapply it.
Finally, clarified some methods by renaming "swipeUp" to
"swipeUpToRecents".
Bug: 132757019
Change-Id: Ieb24a4f36a39780e5d64d7bc312791608db474d1
|
|
|
|
|
|
|
|
| |
* Mostly value changes.
* Added a way to round the corners during swipe up to home animation.
Bug: 123900446
Change-Id: Id61d241d919ba51ced0633585e36b7d93efe30b0
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: 123900446
Change-Id: I3d08985f8362038f50728e91e2fedf1c97e326ff
|
|/
|
|
|
| |
Bug: 123900446
Change-Id: I275e34c6dca5b026f272ab216b18651c0df27bc4
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- If screen pinning is enabled, disable gestures and wrap with input
consumer to break out of screen pinning (existing logic)
- If Home & Overview are both disabled, disable gestures completely
- If only Home is disabled, then always launch the user into fallback
recents (to simplify logic around breaking out of overview into Home)
- If only Overview is disabled, then prevent swiping from going into
overview or from triggering overview from home
- Switch to using screen pinning flag check instead of binder call
Bug: 133113732
Bug: 131698989
Change-Id: Ie6f447520d4cc3fa1eaaf8427ee014851688bf37
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Previously, we clamped the progress to 1 when reaching mTransitionDragLength.
Now, we allow dragging all the way to the top of the screen, and store this
new top progress in mDragLengthFactor (> 1f).
- Because the launcher animation controller is inherently bound to a progress
between 0 and 1, we have to do a bit of trickery involving interpolators.
Specifically, we normalize the progress to 0 to 1 by dividing by
mDragLengthFactor, but then we set the interpolators to multiply their
progress by mDragLengthFactor. The result is that the animation progress
appears to go from 0 to mDragLengthFactor, just like the window progress.
- To avoid scaling too small, we start interpolating the progress at a certain
point, ending at a specified max progress when reaching the top of the screen.
Bug: 131741395
Change-Id: Ie8b4b56d37249cd1456f93c110c26c78fe052dc0
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This eliminates an unreliable timeout.
Also removing an unnecessary check for harness that is done by the
called method.
Change-Id: If954580060415cbb2952532c16ea0ae4dc7b9469
|
| |
| |
| |
| |
| |
| |
| |
| | |
testing Launcher3 without quickstep
Also keeping the provider as disabled until needed
Change-Id: Ib5f459e02ae551724b390f3b74f43d601568d749
|
|\ \
| | |
| | |
| | | |
ub-launcher3-qt-dev
|
| |/
| |
| |
| |
| | |
Bug: 122345781
Change-Id: I9a939e0b19c06c1089c1ceb515f8b97fb5dbb49e
|
|/
|
|
|
| |
Bug: 132900132
Change-Id: I9c5bb51e49f865ea1e1d3d2209a8dfb149f66e87
|
|
|
|
|
|
|
|
|
| |
We had a resolved case in the past where an app's context menu didn't
open on a long click (thanks to app updates), now the menu opens, but
the drag gesture doesn't drag the icon.
Bug: 133009122
Change-Id: I45d104a92fab6556ecd937aef76f0a8147e67f56
|
|
|
|
|
|
|
| |
This ensures that the home task is never blocked by a different task
Bug: 74500048
Change-Id: I01fd26f1d6242e39b2d8fabac5e064b748aebe62
|
|
|
|
|
|
| |
Bug: 123900446
Bug: 124510042
Change-Id: I3db80d6f8064ce26f97cdede63c0d25499416e98
|
|\
| |
| |
| | |
ub-launcher3-qt-dev
|
| |
| |
| |
| |
| |
| |
| |
| | |
- Also reset the task thumbnail as the task views are recycled
Bug: 132309376
Change-Id: Ic2cc846e451b6b59ae76326930cb4b85627e95c4
|
|/
|
|
|
|
| |
Bug: 130451254
Change-Id: I36d885a2b0247f1bb84cb98073459853ae723331
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the issue where overview doesn't come in from offscreen
the first time you enter overview from home.
Test:
- Force stop launcher, quick switch from home
- Force stop launcher, swipe up and hold
Change-Id: Ia4dbd36267008bc199cff088833979606238d3eb
|
|\
| |
| |
| | |
ub-launcher3-qt-dev
|
| |
| |
| |
| |
| |
| |
| |
| | |
* Rect and radius now match the app window size.
Bug: 124510042
Bug: 122843905
Change-Id: Ibc85bfe1d75d01cefe00b6bf32557e04a0ee4716
|
|/
|
|
|
|
|
| |
When screen pinning is active, swipe up and hold to stop it.
Bug: 130828539
Change-Id: I343050d2a224ac723143cd3be4f78bc321f1a026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Workspace and hotseat are drawn in rotated UI giving the impression that the
device is in Portrait, even though it is in landscape
Bug: 131360075
Change-Id: I29c4068af25fd4dcf7039b9a45886e864a137977
|
|
|
|
|
|
| |
Bug: 129434166
Bug: 131170582
Change-Id: Ia9b356594001d96c69ffbb7f8b767b2f54ed5feb
|
|
|
|
|
| |
Bug: 130828765
Change-Id: Ic447d05a8fe2097a6afd0bfec73039a62bbf5a4b
|
|
|
|
|
| |
Bug: 123874711
Change-Id: I9c06723a3e5d4a23b8a6c60352806bb12daba598
|
|
|
|
|
|
|
|
|
| |
Change: ag/7199900
Test: manual
Fixes: 129497226
Change-Id: Ibf0b1d4ade8ef5a2f0ceb545df505e9de419ec50
(cherry picked from commit cad531248e639a60fd3f0ce89b8fdbeb82cb8ea5)
|
|\
| |
| |
| | |
ub-launcher3-qt-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add setRecentsAttachedToWindow(boolean attached, boolean animate) with
the following conditions:
Conditions for attached
- Motion is paused and shelf is peeking
- xDisplacement > yDisplacement (to ensure seamless quick switch)
- We are continuing the previous quick switch gesture
- Gesture has ended and endTarget is RECENTS or NEW_TASK
Conditions for animate
- Recents is visible. Since the running task is invisible, this is
true if either an adjacent TaskView is visible, or if we’re
continuing the previous gesture
Currently the attach/detatch animation is just fading recents in/out.
Test:
- Swipe up to go home does not show the recents list at all. Instead,
all the visuals/motion focus on the app window animating into the
home screen.
- Recents appears when swiping and holding, to indicate that letting
go will land in recents. The shelf also appears with haptic feedback
in this case to reinforce this.
- The next task is immediately visible when quick switching (swiping
left to right on the nav bar).
Bug: 129985827
Change-Id: Ib0c16f583bfd5b02d2f9f68c9688edc980a39d75
|
| |
| |
| |
| |
| |
| |
| | |
Test: manual
Bug: 112934365
Fixes: 129497226
Change-Id: Id128eee4eaa620f0b9c461ef5adf0a16e9ea9a2c
|
|\ \
| | |
| | |
| | | |
ub-launcher3-qt-dev
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug: 130851537
Bug: 119992316
Change-Id: I3de7c1d910d1aecd80b47a85284565c79fe0e2cc
|
| |/
|/|
| |
| | |
Change-Id: Iabc3a3aac85bcf426ab18437e006cc95fa89fbc0
|
|\ \
| | |
| | |
| | | |
ub-launcher3-qt-dev
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are 2 conditions that we force the MotionPauseDetector to treat
the motion as not paused:
1. If we haven't passed a small displacement (48dp before, 36dp now)
2. If we have moved mostly orthogonally
These existed soley for the OtherActivityInputConsumer case, because
1. We only need the displacement requirement to make room for the
peeking shelf, which doesn't exist in other cases (it's already there on
home for example)
2. We can only move orthogonally for quick switch, which again doesn't
exist for other users of MotionPauseDetector.
So now instead of checking min displacement and orthogonal distance
inside MotionPauseDetector, we let callers setDisallowPause()
before adding positions to their MotionPauseDetector.
The only user visible change is that you no longer have to swipe up 48dp
before we allow pause to overview from home. This also paves the way to
using the same logic that determines to disallowPause to also detach
recents from the window while swiping up from an app.
Bug: 129985827
Change-Id: Ie690aa314da3260aff2209341a29638604f9501c
|
|/
|
|
|
|
|
| |
Bug: 122700646
Bug: 127840207
Change-Id: I5862c8950565df172a933114e1fb2f9c4575593e
|