The attaching animation can take longer than the transition to recents
when you let go, and the ADJACENT_PAGE_OFFSET calculation is different
when there's a running task vs not. So after the transition to recents
ended, the calculation of the still playing attaching animation would
change, causing the jump you see in the bug. Now we make sure to end
the attaching animation if it's still running when we settle on an
end target to avoid this issue.
Fixes: 168563692
Change-Id: I3f37aecf9c93f2ec63dbdce561e7f5ba11be89cc
Merged-In: I3f37aecf9c93f2ec63dbdce561e7f5ba11be89cc
(cherry picked from commit 1cc12ebc12)
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
Merged-In: Ib3cfba6ebafbcb90de9c6b1ab79f53605d995321
- The canRecentsActivityRotate() also checks whether system rotation
is enabled which prevents us from using the right layout orientation
when home rotation is enabled while system rotation is disabled.
Bug: 168278832
Test: Tested menu visibility in combination of
Auto rotate setting x Home rotation setting X Device orientation
Change-Id: If74a38b1ec51abd2ea7f3ba3de23f0b2c4cab0ab
Merged-In: If74a38b1ec51abd2ea7f3ba3de23f0b2c4cab0ab
- In fake portrait, fade out instead of translating offscreen, as
the orientation doesn't map to where RecentsView actually lives
- From OverviewModalTaskState, start from > 1 scale, and use
OverviewToHomeAnim (to ensure RecentsView doesn't fade out etc)
- To keep parameter list sane, added RecentsParams to
AnimatorControllerWithResistance which has the new startScale
(set to current scale for modal state) and renames the old
RecentsParams to RecentsResistanceParams. Sorry if that's
confusing.
Bug: 144170434
Change-Id: Id36ebde440b398159cef50d95822627fca761527
Merged-In: I437f0d18cad4c94feea25954aed3390acedcaed5
Test: go to overview, dismiss a task, swipe up to go home during the
transition (easier to try with animation duraation scaled up)
Bug: 144170434
Change-Id: I28b846b43260179aeac877351a7069743f66f3ea
Merged-In: I28b846b43260179aeac877351a7069743f66f3ea
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
We need to do this before potentially starting another
interaction during the animation, or we could end up in
an inconsistent state.
Fixes: 160759508
Change-Id: Ia28dceddcc258679fc0b968f5a83fae5ef3f5acb
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
The loss of precision was causing us to miscalculate the age of
events, and thus not detecting any pause due to denominator = 0.
Test: have a device that hasn't been rebooted for a certain
amount of time such that SystemClock#uptimeMillis can't be
accurately converted to a float, then try to swipe up and hold
Fixes: 160568387
Change-Id: Idef112187f34a18feea7e6a0b77258626f9d0ed4
Make the overlay factory a member of the recents view.
Before the factory was static. The factory has references to activity
objects so was causing leaks.
Bug: 162012217
Tested: local, factory still works
Change-Id: I2283134f3008b630ba2056f07e65ac042957cdbd
Separate out the overscroll plugin from the task overlay.
These two classes aren't really related.
Bug: 162012217
Tested: checked plugin still works
Change-Id: Id89eff1ad2ae9766efaaecd8cfc66d6521b9ca8c
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
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
We use the interpolated progress of the animation contoller target
to determine success, but only the child animation had the
interpolator set. Updating the parent to use the same interpolator
ensures getInterpolatedProgress() returns the same one used to
play the haptic.
Fixes: 161536946
Change-Id: Ibc2aef67f53efa01f2b185cf03140bad4bb5c421
This allows the running task to follow the finger freely until motion
pause is detected (or when trying to quick switch in a direciton that
has no tasks, as RecentsView is still attached until you swipe up).
Bug: 149934536
Change-Id: If68166e962af9f28c56017838f720e15ddb96560
Hyunyoung Song
Tony Wickham
TreeHugger Robot
Samuel Fufa
Winson Chung
Bill Yi
Sreyas
Pinyao Ting
Becky Qiu
Zak Cohen
Sunny Goyal