- Don't lock when making WM calls (only lock when resetting), and use own
executor since the background executor is fixed to only two threads and
other things can be running on them already (like task loading).
Bug: 78585335
Change-Id: I73dfc380dd99908cfc30ff7c164a9677a5a126e0
- Don't lock when making WM calls (only lock when resetting), and use own
executor since the background executor is fixed to only two threads and
other things can be running on them already (like task loading).
Bug: 78585335
Change-Id: I56e24fbbdeb3b673837982df3fa67e485d03b3b2
> Caret is only visible when the accessibility is enabled
> It is visible in NOTMAL and OVERVIEW state and moves out of the
scrim along with the scrim.
> Acts as an accessible target for various options
Bug: 78172350
Bug: 79215734
Change-Id: I8a968b67e36901859649546295f6491d49cc9ce9
Previously we were ending the atomic animation with the assumption
that it should be complete/almost complete by the time you drag to
the next state. However, it is very easy to drag quickly enough where
that assumption doesn't hold, and thus you just see the atomic
animation pop to the end (i.e. recents showing without animation).
Now instead of ending the atomic animation, we let it continue. But
because the new state animation will have an atomic component that
interferes with the still playing atomic animation, we have to
control the atomic component separately; we control the non-atomic
components until the atomic animation ends, at which point we create
a separate controller to control the atomic components.
Bug: 76449024
Change-Id: Ia4bf19e26d0838f952d9e500fbdd8aba19856a41
State handlers can now specify atomic and non-atomic components of
their animations to states, which can be specified when creating a
new animation. There is now one atomic animation, when going from
NORMAL to OVERVIEW (and in reverse):
- RecentsViewStateController's animation (scale/alpha) is all atomic
- WorkspaceStateTransitionAnimation has atomic and non-atomic:
- Hotseat and workspace alpha is atomic, as is workspace scale
- Everything else (scrim, translation, qsb and drag handle alpha) is
non-atomic
- All apps progress is non-atomic
Also simplified dragging through overview; no longer pulls against you,
so we use an OvershootInterpolator when flinging instead of our custom
interpolator for the spring effect.
Bug: 76449024
Bug: 78089840
Change-Id: Iafac84d0c2b99ee9cf9dd5b30e2218286713b449
- Scale icon down/up atomically at a threshold
- Fix scale of tasks to properly take curve/zoom scale into account
Bug: 78779525
Change-Id: I5909c63b18a993433de7a38b9641f4f38a219807
This is more common for tall devices where cell height is relatively larger
than the icon size.
Bug: 78598193
Change-Id: I2835794e4dbe799d0fadefaa723360145d134550
> Converting the scrim to View, to better avoid overdraw
> Overview and Spring loaded state have different scrim alpha
> When going from overview to all-apps, there is a color scrim drawn over the overview panel.
The slef color is merged with this color to prevent overdraw, and the remaining screen is drawn
with a cut-out round rect path
Bug: 79111591
Change-Id: I26801fde13dd6adb4b06110bbe8087e35cc31847
Insets may not correctly indicate seascape configuration in multi-window or
when the presence of device-cutouts
Bug: 79376298
Change-Id: I8268efca0001fe527a0ffefe48cc71e774fad01c
Winson Chung
TreeHugger Robot
Tony Wickham
Sunny Goyal
Vadim Tryshev
Hyunyoung Song
Tracy Zhou
android-build-team Robot
Jon Miranda
Mehdi Alizadeh
Bill Yi