Launcher preview rendering fails on AOSP Launcher3 because the search
bar (AppsSearchContainerLayout) tries to find BaseDraggingActivity
during inflation, which doesn't exist in the preview hierarchy.
Remove the search bar from the launcher preview layout entirely to fix
the issue. This is actually more consistent with our real launcher
appearance because it doesn't have a search bar to begin with.
Change-Id: Ic549fd9d592bc702e0c12285fb016b908e49d514
Test: Set TaskView#EDGE_SCALE_DOWN_FACTOR = 0.2f, then swipe
down on the centermost TaskView; ensure it fills the screen.
Alternatively, touch and hold the nav bar and ensure there is
no jump in scale on the app window.
Fixes: 169259407
Change-Id: Ib3cfba6ebafbcb90de9c6b1ab79f53605d995321
(cherry picked from commit 82ff64530e)
Invert the condition check in IconCache so that, if a shortcut is
already using a non-default icon, do not replace it with default icon
again.
Bug: 162783875
Test: add weather shortcut, backup, restore, verify its icon is not
replaced by default droid icon
Change-Id: Idaf4ce4afa84d21f7192a2f4ce41a6f8daa8d3f2
(cherry picked from commit 61e8ae1d9d)
Animating this new property allows us to adjust the scrim without
competing with other state animations that could be setting the
scrim progress. Also reset scrimMultipler = 1 for state transitions.
Test: Swipe from home to overview, then during that transition swipe
from overview to home; when the former transition ends while the
second is still in progress, ensure scrim value doesn't jump
Bug: 144170434
Change-Id: I44b57ced1c6902e558fe1818bcbf11ceb4ff2f6f
Merged-In: I44b57ced1c6902e558fe1818bcbf11ceb4ff2f6f
Introduces a separate database for minimal device mode.
When minimal device mode is enabled/disabled:
1. WellbeingModel receives onChange event from ContentObserver
2. WellbeingModel called DWB's ContentProvider for latest state in
minimal device mode
3. Based on the state, WellbeingModel calls LauncherProvider to put
launcher into normal/minimal mode.
4. When going from normal -> minimal, Launcher switches to a different
database, namely minimal.db, then proceed to database initialization.
5. If the database hasn't been initialized yet, Launcher will call
ContentResolver#openInputStream with following uri:
content://com.google.android.apps.wellbeing.api/launcher_layout
to get the default layout xml.
6. The default layout is then saved in database, and the database is
considered initialized and doesn't need to go through step 5 again in
the future.
7. In case of minimal -> normal, Launcher switches back to its original
database (e.g. launcher.db if the grid size is 5x5), then reload launcher.
Bug: 161462256
Change-Id: I6bafa66440da23281f63454b698ea56b15960022
This way we mark the the current state as NORMAL at the start of
the animation, and cancel it as part of other state transitions.
This allows us to interact with launcher (e.g. to go to all apps
or pull down the notification shade) during the animation.
Also use OverviewToHomeAnim from RecentsView#startHome() to
ensure the animation is consistent, e.g. doesn't fade out
RecentsView, scrolls to page 1, etc.
Bug: 144170434
Change-Id: I5348565b9e705d8ffba39818dde9efe82b16bb7a
Merged-In: I5348565b9e705d8ffba39818dde9efe82b16bb7a
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
Patryk Michalik
Kshitij Gupta
Danny Lin
Sunny Goyal
Samuel Fufa
Winson Chung
Hyunyoung Song
Tony Wickham
Tracy Zhou
TreeHugger Robot
Pinyao Ting
Zak Cohen
Becky Qiu
Sreyas
Jonathan Miranda
thiruram