Adding various-pitch earcorns that depend on the scroll state and
position in the list notifications. This is for Talkback.
Bug: 72222505
Test: Manual
Change-Id: I99ffe553f7a20d057940197d97506bc1a14a193e
> Hiding the caret in fast overview state
> Hiding caret in task swipe down interaction
Bug: 79700605
Change-Id: I984d535bc75802501e8aeb13c8f37387f331e5bc
Keyboard navigation of AllAppsContainerView is broken in TOT; disabling
focusing there is necessary for Recents.
Bug: 72222505
Test: Manual
Change-Id: I85d544f7c8dbdaf12e49de51c6626bbc3dc32917
- Certain animations can run after the launcher state has changed,
triggering loading of task data even when the overview state is not
visible. Only allow re/loading of this data when we are in the overview
state.
Bug: 76162466
Change-Id: Ie1f492ef712ea4aa2db6f2e1bc7ba4390742875b
Add BackButtonAlphaHandler to set back button alpha, instead of setting
it from multiple places.
Also force back button alpha to be 1 if swipe up is disabled (b/80091187)
Change-Id: I49b63a0e6b033a3a947a847669a398f1b9ff0564
Now that we use OvershootInterpolator for the atomic recents animation,
it's possible to get alpha > 1. The drawable and text paint used in the
empty recents state doesn't handle this well, causing alpha to jump to 0
in this case. Instead, we'll just force it to clamp to 1 ourselves.
Bug: 80004542
Change-Id: Id0177caf63cd349f6f27c9dfaf0e8995447e70fc
This will result in the focus going to the second from the right task
upon opening Recents. This will be mitigated by implementing in near
future announcements like Task 6 out of 7.
Besides this, due to (presumably) problems external to Launcher, the
focus may stay on Home button or completely disappear upon opening
Recents.
Bug: 72222505
Change-Id: I0e5ac62bfa0e1c0db2d17a6014e61f82cfccf252
Testing: Manual
> Skipping quick scrub, if its already in progress, or is waiting on previous task launch
> Restoring to proper state is the task animation is cancelled before launcher gets onStop
> Crash when using quickscrub before last list has loaded
Bug: 77289180
Bug: 77856587
Bug: 79919440
Change-Id: I8db127bf9539cfc8f47c1e86c5030637845749d4
- Better than using the threshold ourselves, we should just use the callback
from the system.
Bug: 79970627
Change-Id: Ida15cfdaa2463f9fa15e222c55e483eb145c2716
- We were previously using the drag threshold (10dp) for both gesture start
and drag start, when we should be using the touch threshold (24dp) for
the deferred gesture start to ensure it coincides with the touch threshold
for the buttons in the nav bar.
Bug: 79970627
Test: Swipe up over the back button, ensure that we don't both start the
animation and also trigger back press
Change-Id: Ib4b2a3e2492da144485f87be5477eabf3e96e843
Back button changes opacity when moving the shelf during swipe up
between home screen and overview. The alpha changes depending on the
progress of the swipe up animation. When going from app to home and vice
versa, the fade animation does not tie with the swipe up progress. The
fade animation also masks the back button drawable when ime visibility
changes.
Change-Id: I51e42930640ba711e81880b385bb722d7ee8ad33
Fixes: 74581837
Fixes: 76900236
Test: swipe up from home screen to overview
- Don't update the animation to go from 0 to 1; instead, update the
interpolator to clamp to the remaining progress (b/79773309)
- Fix NPE that can happen in a race between the atomic animation
ending and the non-atomic animation canceling/ending
Change-Id: I313251dc5cbd7b931b043fc3e840bb4ab368a790
- Was missing additional checks and unconditionally removing the task
whenever the task was removed from the active tasks in AM. Instead, check
that the app still exists both in the system and in the recents list
before removing.
Bug: 79698015
Test: a) get incoming call, go to overview, end call and ensure removed
b) install app, open app, go to overview, uninstall app and ensure removed
Change-Id: I8901cb232ef7ff0759923d6a98f65df4e4adf88b
When we enter overview (overview appears, workspace disappears):
- Workspace scales down from 1f to .8f with OvershootInterpolator(1.2f) at 200 ms
- Workspace fades from 1f to 0 with OvershootInterpolator(1.2f) at 200 ms
- Overview scales down from 1.33f to 1f with OvershootInterpolator(1.2f) at 200 ms
- Overview fades from 0 to 1f with OvershootInterpolator(1.2f) at 200 ms
When we exit overview (overview disappears, workspace appears):
- Workspace scales up from .92f to .1f with DecelerateInterpolator() at 200 ms
- Workspace fades from 0 to 1f with AccelerateInterpolator() at 200 ms
- Overview scales up from 1f to 1.1f with AccelerateInterpolator() at 180ms
- Overview fades from 1f to 0 with DecelerateInterpolator(1.7f) at 200 ms
Parallax while the finger moves: Workspace translates half the distance as the shelf
Bug: 79776746
Change-Id: I319d982cf202bcd6dbbcd68ffc5c0c7853629c7e
Implements the following logic:
if config_swipe_up_gesture_setting_available is false, always use the
default value in config_swipe_up_gesture_default and ignore
Settings.Secure
if config_swipe_up_gesture_setting_available is true, use
config_swipe_up_gesture_default as the default value for
Settings.Secure, and respect Settings.Secure if user makes any changes.
Bug: 78641268
Test: Manual test
Change-Id: I586083b6655ccb3c94f08a911ed0de80f4738d62
There are 3 places we can block a fling:
- Swiping from home to all apps (through overview)
- Swiping from an app to all apps (through overview)
- Dismissing a task (in the same gesture that started by swiping down)
In all of these cases, we block the fling when crossing the threshold
to a new state (e.g. OVERVIEW), but unblock if the user pauses their
drag. With this change, the logic is consistent:
- Unblock the fling after pausing a short amount of time
- If a fling was blocked, increase the settling duration based on
velocity
Bug: 78089840
Bug: 78658678
Change-Id: I5ef52b74229418b867b26c3c6d3db2cf6e48914b
