For both NoButtonNavbarToOverviewTouchController and
NavBarToHomeTouchController:
- Have consistent resistance applied such that RecentsView scales
down and translates up slightly (but not as much as from an app)
- Have consistent animation to home if you fling to that state
rather than stay in overview. This is handled by a new class,
OverviewToHomeAnim, which consolidates logic from NBTHTC and
overrides some interpolators such that RecentsView doesn't fade
out or translate downwards during the animation (it just slides
off the screen while the home animation plays).
Also make overview actions not clickable when alpha == 0, so that
you can tap the hotseat/qsb during the transition from home to
overview.
Bug: 144170434
Change-Id: Ic291f285ff2f63c477633c48d4fadb23cf70c28a
Event IDs were generated by command line on my workstation by uieventscli.
Manually added to StatsLogManager.
Test: local
Bug: 161273376
Change-Id: Iee36c450ddb207f87653a8da2355c720369caa34
Now recents view follows your finger all the way to the top of the
screen. Specifically, your finger tracks the bottom of the window
until resistance starts (when RecentsView is at 75% scale), then
we add translation to compensate for the slower rate of scaling
down, such that your finger slips to the top of the window by the
time it reaches the top of the screen.
Also reset this translation back to 0 in the state handlers.
Bug: 149934536
Fixes: 158701272
Change-Id: Iaee58da758d422f0173c29d002f5c451ce0c1809
Before, the adjacent tasks were coming in from the top and bottom
of the screen rather than the sides.
Bug: 149934536
Change-Id: Id6e57dcbc1967d70869df06068d25717de116934
- Temporarily work around issue with activity recreation while started
but not resumed by deferring recreating the activity on theme
change until after launcher has resumed.
Bug: 162812884
Test: Switch dark mode via QuickSettings, Settings
Test: Change system theme
Change-Id: Ifbc0d538907a30d6b23176cd67353a81b6f8c617
- Rename "pullback" to "resistance" to reduce confusion.
- Remove mDragLengthFactorStartPullback & mDragLengthFactorMaxPullback
- Add AnimatorControllerWithResistance, which has 2 controllers, one
for the normal shift to overview, then one to apply the resistance
when swiping beyond that.
- Don't hack animator interpolators/progress; insteaad, allow progress
to go > 1 (which will run the separate resistance animator).
- Don't start launcher controller separately from window controller;
instead, both are controlled by mCurrentShift in updateFinalShift().
- The resistance animation logic is shared by both the active window
and launcher (RecentsView).
Bug: 149934536
Change-Id: Ib0f9da18e10cc9ddf1a2f82ed767f237c89d3a41
Merged-In: Ib0f9da18e10cc9ddf1a2f82ed767f237c89d3a41
Instead of calculating an overall distance for tasks to translate
based on RecentsView width, calculate the distance for the tasks
to the left and right of the midpoint based on how far the first
adjacent tasks in those directions are from being offscreen.
Changes made to make "distance to offscreen" calculations possible:
- Update TaskView curve scale to reach final scale as soon as it is
completely offscreen. Before, it would reach its final scale just
shy of that point (calculations were off).
- As we update RecentsView scale, calculate how much the new scale
will push out tasks that are just offscreen.
- With both above, we can calculate the scale and position of a
TaskView such that it is just offscreen, and interpolate
between its current position and that position.
Tests:
- Task comes in immediately when quick switching from home, and
doesn't shift as you swipe directly upwards.
- When swiping far up from an app, tasks come in from all the way
offscreen, and cover distance appropriately (e.g. if you're
scrolled a bit to the right when you pause, the left adjacent
app will move faster to cover the farther distance).
- Task modalness: entering Select mode now animates adjacent tasks
at the same rate as the scaling up, because they move only the
distance needed to get offscreen (before they moved way too far
and thus seemed to be much faster than the rest of the animation).
Bug: 149934536
Change-Id: Ie3fffe0e5c304cb16e7637f058f5ce72cee40aeb
Merged-In: Ie3fffe0e5c304cb16e7637f058f5ce72cee40aeb
This reverts commit a8c08584a7.
Reason for revert: "caused a regression with quick switch from home: if you start the gesture then swipe back to the left, it ends up launching the task anyway"
Change-Id: I8e12e2de46b6fc6a3faeb0336762da08080c61d6
When user swipes up to home, Launcher will receive a onNewIntent
callwith a bundle-extra gesture_nav_contract_v1. It will contain
the componentName & UserHandle of the closing app & a callback.
Launcher can use the callback to return the final position where
the app should animate to and an optional surface to be used for
crossFade animation. The surface cleanup can be handled in
onEnterAnimationComplete.
Change-Id: I76fdd810fdcb80b71f7d7588ccac8976d9dfe278
The internal implementation of PendingAppWidgetHostView#getDefaultViews
uses the same view across updates which causes the exception in
AppWidgetHostView#applyContent when it tries to call addView() because
the view has already been added to its parent view in previous iteration.
Bug: 151901506
Test: manual
Change-Id: Ieccec814ac514e592d0d4f196b60ba89aec0d661
The fix is to prevent re-arrangement if the views are already unbound.
This is caused when:
- Folder is open
- Item has deep shortcuts
- Long press on deep shortcut to create DragView that could land in the
folder if the folder did not auto close. This is important because it
starts a drag within the folder
The folder unbinds all views as part of the Folder close complete callback.
And then the folder exit alarm gets triggered (because we drag DragView
outside of the folder) which causes the folder items to get
rearranged and added back to the folder's CellLayout.
Bug: 161559911
Change-Id: I142589b2c541dc21c47a67c20a93e627732107ef
Launcher stores ItemInfos for cached predictions in list BgDataModel.cachedPredictedItems on Launcher start (LoaderTask#run). The list reused if launcher has to rebind UI. Hence, the list should be cleared if launcher receives empty predictions.
Bug: 161245294
Test: Manual
Change-Id: I275655d5f52f6a6e5297473dd2f642728c1964a6
With the second swipe, we never complete the swipe to Overview
NoButtonNavbarToOverviewTouchController#maybeSwipeInteractionToOverviewComplete
- mReachedOverview = true
- mDetector.isSettlingState = false
And then the second swipe starts the state transition to Hint but then
it never gets completed because:
1. The animation starts
2. Gets cancelled
3. Starts again
4. Finishes, but is not marked as success since the cancel in #2 was never
set back to false
Bug: 160759508
Change-Id: I8c3972e6209c3d5a4a0bdd9f9b7683de18105d57
Test: swipe up from an app in landscape, seascape, and portrait,
and verify the window tracks with the finger 1:1 until pullback
Bug: 149934536
Change-Id: Ia469877e7152c8135e0b9153f69c191ba86cbd14
(cherry picked from commit f0a1b2ccd8)
After breaking down the time we spend in rendering preview under a different grid setting, I found out that we spend a huge amount of time loading the workspace. It takes a long time in non preview case (launcher workspace init), so to optimize we should try to cut down things that are not necessary for preview. Widget model loading (widget and shortcut updates) takes half of the time, and can be optimized with minimal risks / code changes.
Bug: 160662425
Test: Manual
Change-Id: I89029d0ddf6e2517077a0ba3fbbcfdcd60b268d9
This ensures that the cell contents always fit.
Bug: 160716074
Change-Id: I3d85adec3e7e3652fe4a258bd659382a3e696211
(cherry picked from commit 3535944395)
This happens when you drag an app into a folder when the current page is
already full. The new page has no apps in it until you drop the one you
want to add.
Fixes: 161040039
Change-Id: Iaa857e7a114e859fa7e6a0653028856a3a8a94a6
There's currently a bug prevents Launcher release drag lock for two step
widgets. Supposedly, onDeferredResume should release the drag lock; However,
in 3-button navigation mode, the transition from Overview -> Normal is
triggered in Launcher#onNewIntent, which happens after onDeferredResume.
This issue is not reproducible with gesture navigation because its
transition from Overview -> Normal is handled in NavBarToHomeTouchController
Test: manual verified with following steps
1. Enable 3-button navigation
2. Long press in WorkSpace -> Widgets
3. Drag Settings Widget to WorkSpace
4. When the config activity is shown, press "recents" button to see Overview
5. press "home" button to go back to workspace
6. repeat 2 and 3, verify the widget can be dragged
Bug: 149659788
Change-Id: I396ffa8a7db44bf3872a10de4208340a99a7efe8
(cherry picked from commit 3bf889a02f)
Also fixed another bug where the wrong layout
orientation was being applied when overview rotated
when launcher was in fixed portrait orientation.
Fixes: 160182914
Test: Tested w/ PIP, split screen,
w/o split screen w/ and w/o home rotation
Change-Id: Iccffb637ae5c22d07745f2108facd4de716dc8d3
> Using a separate View as icon, instead of the taskView
> Updating swipe animation logic to abstract out FloatingIconView dependency
Change-Id: Ib466262afead11ebe4ca035d589f0382c37e3e97
Tony Wickham
Becky Qiu
TreeHugger Robot
Winson Chung
Sreyas
Jonathan Miranda
Samuel Fufa
thiruram
Pinyao Ting
Sunny Goyal
Tracy Zhou
Andy Wickham
Vinit Nayak