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
Currently, we are maintaining a list of appInfos to report the number of Accessibility recycler-view items. This could be done by maintaining an int.
Bug: 162480567
Test: Manual
Change-Id: I9de8e1d4ac6e1a674d1e19b591dedad0dd4cc536
- 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
- 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
unmodifiableList is backed up by the original list and is not suitable
to passing to different thead.
Bug: 162518472
Change-Id: I71774ced89d64acc7176269e107cfcf47627f7c4
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
Predictions are loaded and managed by Launcher model and follow
the model lifecycle. They are then bound to the callback which
handles the UI
Bug: 160748731
Change-Id: I4a3ea0698d80fafe94afb4ce66ffa7f4a6a91c68
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
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
Currently, SecondDisplayLauncher doesn't specify ActivityOption to
launch on second display, so application will launch on main display
even the user tries to launch APP from SecondDisplayLauncher.
So need to specify ActivityOption then activity can launch on the correct
display
Bug: 162042798
Test: manual testing
Change-Id: Iceb4e01b725834983a5d01cf54350f61851ad172
(cherry picked from commit 3a8075366c)
Ignoring state events from NexusLauncher in Launcher3 tests.
Improving diags for failed app launch.
Change-Id: I3ffb49c598edef7b6698b48ba7b63e6163ef25b4
Tony Wickham
Samuel Fufa
TreeHugger Robot
Andy Wickham
Winson Chung
Sunny Goyal
Raman Tenneti
Sreyas
Jonathan Miranda
Hyunyoung Song
thiruram
andychou
vadimt