This change is intended for the desktop use case.
Bug: 388898277
Test: Manual
Flag: com.android.launcher3.enable_mouse_interaction_changes
Change-Id: Ibbca58f1e98a6648be68fc7e3b6337f5c78160da
Separating various overrides to individual modules so that they can be reused in tests
Removing ContextualEduStatsManager and directly using SysUiProxy as all the usescases
are only in quickstep/
This avoids additional Module definition and delegation
Bug: 361850561
Test: Presubmit
Flag: EXEMPT dagger
Change-Id: I096459d638553991ed01766002b874589c6b976e
It should only update edu stats of home gesture when user swipe up to go home. It is already handled in AbsSwipeUpHandler.
This change avoids updating edu stats when users swipe down the all apps panel as it is not considered as home gesture.
Bug: 363480554
Test: Manual
Flag: com.android.systemui.keyboard_touchpad_contextual_education
Change-Id: Ib859cef5cbb2805fd2b596c6c40a67a5f21cceae
Update education stats when
- go overview and all apps by swiping up at homepage (AbstractStateChangeTouchController)
- go home from all apps by swiping down the all apps panel (AbstractStateChangeTouchController)
- go home from all apps or overview by swiping up from the bottom nav bar (NavBarToHomeTouchController)
- in 3 button navgiation mode (TaskbarNavButtonController)
NavBarToHomeTouchController does not inherit from AbstractStateChangeTouchController so logic are added separately.
Bug: 363480554
Test: TaskbarNavButtonControllerTest
Flag: com.android.systemui.keyboard_touchpad_contextual_education
Change-Id: I0662704a9093b9f5a4d2f086a8297429fbc49881
- Reuse existing TaskSwitcherContainer for Overview metric logging
- Log current orientation state for Overview when interacting with
gestures or via three button nav
- Log current orientation state on each phone rotation
Bug: 332870519
Test: Manual
Flag: NA
Change-Id: Ia10cf1acb809432175daab55151998f0d77362f9
Previously, the following would cause the All Apps panel to appear
in NORMAL state:
1. Start dragging to all apps
2. During the drag, something sets Launcher to NORMAL
3. Release finger -> animation to all apps completes, but state
is still NORMAL
Side effects of this:
- On large screens, All Apps draws its background on Launcher's
ScrimView only if the current state is All Apps. So in this
case, the apps just floated above the workspace.
- On handheld, touches are handled by workspace even though you
can see the All Apps list. So e.g. if you swipe down, the
notification shade appears rather than all apps panel hiding
(although it seems this touch issue was addressed separately).
I'm not sure if this is the main/only case of this state mismatch
happening, but verified with local async state changes that this
could in theory happen. We haven't been able to organically repro
the bug reliably. That being said, it feels plausible that a well
timed screen lock during the all apps transition could also hit
this case.
Demo videos with hard-coded state change to NORMAL 2 seconds after
you start swiping up to all apps (note I release my finger at the
end of each video):
https://drive.google.com/drive/folders/1ul8ep9N2M5oc6ZSbf_ZHQwp9IwTpz7GB?resourcekey=0-4LAufl0rkvtjvgZC0L-eMQ&usp=drive_link
Bug: 239394946
Bug: 331600490
Test: Manual with local async launcher state changes
Flag: NA
Change-Id: I6364dbde8aea67f5d1c525edf57ed7eb26096cf9
- Swipe up to pull up all apps
- Swipe down to pull down notifications
- Same gesture to close in reverse scrolling mode
Bug: 301966246
Bug: 301966690
Test: manual
Change-Id: Ia3770ce8b279d24b2de4844f441f14e0feaf57c7
Also updates some interpolators to make the manual and atomic
transitions more homogeneous.
Also also updates the commit point so it matches the transition point
between the two states exactly.
Note: the background scale is currently too much, and it needs to be 1/3
of the total distance to match the Workspace scaling. To do this, we
simply scale down the depth by a factor of 3 when calling the background
zoom-out API in the DepthController.
Bug: 254835725
Test: see videos in bug
Change-Id: I605546921e9ee4dfc852794c56495c72f0b916e1
Currently the overshoot only works when you first open all apps and try
to extend the all apps to the top (making it overshoot). This pull works
when you go mFromState:Normal -> mToState:AllApps. However once the all
apps is set and you move the surface down then up..that overshoot
animation jumps AFTER your finger goes all the way up and off the
screen. At this point, once all apps is completely opened.. the states are
mFromState:AllApps -> mToState:Normal.
Now with this change, it addresses the jumpiness by considering the
current states (mFromState==AllApps) by
including the same onPull() but with different calculations
bug: 240669628
test: manual - videos included in bug thread
Change-Id: I7873f1ec22574f87fab3d2f11d1f5a5f81dfb5bc
- Log Home -> Overview gesture
- Log Home -> quickswitch as LAUNCHER_QUICKSWITCH_RIGHT
Bug: 219686410
Test: Local log in StatsLogCompatManager
Change-Id: Ic88fefd5af58dc03779f77b12611843c40706b1c
- Remove PLAY_ATOMIC_OVERVIEW_SCALE and PLAY_ATOMIC_OVERVIEW_PEEK
- Remove complicated parallel atomic animation support from
AbstractStateChangeTouchController and subclasses
- Remove some code related to going between Overview <-> AllApps
Test: Swipe between states in all 3 navigation modes
Bug: 175137718
Change-Id: Ice314d46946c3a983cdc6ccf1a67effb5da9156e
Revert "Revert "Moving insets animation to StateHandler so that ..."
Revert submission 13823490-revert-13810332-insetcontroller-CLXXLCZAUM
Reason for revert: Fixed original error in ag/13823726
Reverted Changes:
Ie19a3fd90:Revert "Moving insets animation to StateHandler so...
I4eb33772a:Revert "Removing insets controller animation as pa...
Change-Id: I7fb395c51ea99081913bc99515257e98c0a32754
Revert "Moving insets animation to StateHandler so that it can b..."
Revert submission 13810332-insetcontroller
Reason for revert: QsbLayout#getEditText() return object is changed, but extended class HotseatQsbWidget wasn't updated.
https://android-build.googleplex.com/builds/submitted/7197042/aosp_crosshatch-userdebug/latest/view/logs/build_error.log
Reverted Changes:
If6a088d14:Removing insets controller animation as part of al...
I296415604:Moving insets animation to StateHandler so that it...
Change-Id: I4eb33772acd887d6e1d92a9ecde41cf1e0687896
- Use same swipe height as the tests use to get to Overview
- Use mStartState instead of fromState when determining
target state, to disallow swiping through states, i.e.
from NORMAL to OVERVIEW back to NORMAL in one long swipe
up gesture. Instead, now swipe up from NORMAL goes to
OVERVIEW and swipe up from OVERVIEW goes to NORMAL.
Fixes: 177316094
Change-Id: Ic8e9c8650d4cf11eec344802e3569413bfd5d7bc
(cherry picked from commit a24b9ff69d)
=> The entire DragLayer is translated during the -1 transition which creates a janky looking edge at the top of the screen
=> By bumping the scrim up a level, we avoid this
=> Separated WorkspaceAndHotseatScrim into two separate scrims, since only part of the scrim needed to be bumped up to a level. Further, it was an overloaded class.
=> We had previously been implicitly relying on the fact that the scrim was rendered in the Workspace parent; we need to make sure to propagate workspace inavlidations to the container of the scrim. While things would still work without this change, it's more correct to leave it, as we no longer assume a hierarchy for functinoality.
Bug: 178215332
Test: manual verification. See video in bug.
Change-Id: I0a76ddf35ceea8c9635367f69380ef24f42e9479
Also removed plugin support as if both the feature flag and
the plugin is turned on, there are object/resource contention
Bug: 161594550
Change-Id: I2cb98e83c46c7e47db96b90fa8d7cb9620643221
Haven't been able to reproduce it locally, but seems theoretically
possible if we get an onDrag() event right after something else
cancels the animation (which clears the animation controller).
Bug: 157900227
Change-Id: Ia134aa948e62d39f71e41dd4e6b98f3227ae0522
Added behind FeatureFlag.KEYGUARD_ANIMATION due to dependency on
Ie94ab8ecd35e9dcc28d0b8f7aaeb058e15b0f80b.
Added dynamic resource unlock_staggered_velocity_dp_per_s so that the
animation can be tuned.
Bug: 151238866
Change-Id: I4d349d32cc7d86be3cdc582c2a7c565be2931444
Using PendingAnimation for animation builder.
This will allow us to easily add SpringAnimation to stateAnimation
Change-Id: I8d88489a5da6fc85747ef9be7c13858b441cd28a