Test: Manual
Bug:122345781 P1 Inflation happens and a binder call during swipe up gesture, that may cause jank
Bug:123900446 P1 App to home animation should zoom into the app icon
Bug:132209249 P1 Gesture bar interferes with Messenger chat heads.
Bug:132815672 P1 -1 to home swipe up gesture
Bug:132886768 P1 Swipe home animation sometimes drops frames
Bug:133009122 P2 Rare flake: dragged launchable to workspace, but the current state is not WORKSPACE; Can't find a launcher object; selector: BySelector [RES='\Qcom.google.android.apps.nexuslauncher:id/apps_view\E']
Bug:133226418 P1 [Gesture Nav] App launch animation has has incorrect origin when launched in Overview
Bug:133508173 P1 App switching is very janky on QT
Bug:133871965 P1 (V35 20190528.00_RC00):Unable to unlock/minimize phone app during ongoing call
Bug:134095068 P1 Shouldn't use seamless rotation in another case
Bug:134166337 P1 3P Launcher Breaks Overview (Standalone)
Bug:134172603 P1 Tracing for lab-only flakes
Bug:134517106 P1 Swipe up to home should fade out scrim
Bug:134532571 P1 Launcher flake: java.lang.AssertionError: http://go/tapl : want to switch from background to overview, but the current state is not BASE_OVERVIEW; Can't find a launcher object; selector: BySelector [RES='\Qcom.google.android.apps.nexuslauncher:id/overview_panel\E']
Bug:134674880 P1 App group name in expanded view is invisible with white wallpaper
Change-Id: I9bca7db0f03bd4c0581ce946646bf5209e8f6c79
When Launcher is not focused and we try to dispatch events to Launcher, it
can lead to a inconsistent state. For eg, NavBarTouchController was trying
to take launcher from NORMAL to NORMAL state causing the endCallback to be
called immediately, which in turn didn't clear Swipedetetor state
Bug: 132209249
Bug: 132815672
Change-Id: I82e4fdcb8fd5339e82fc8551f3a6e0b046d906f8
Here's what was happening:
- When animating to a new task, the launcher controller ends first (when
quick switching it likely ends immediately since we're already scaled up).
- Then we get onApplyWindowInsets(), which re-builds the launcher controller.
- Finally, the window animation ends, invalidating the handler and ending
the new controller, which sets the state to OVERVIEW.
To fix this, never create a new controller if it has ever been started.
Bug: 133508173
Change-Id: Ibd0e18e488353df73159ffbdd9a3b335bed57d98
This layout is handled by the provider of the hints now.
Bug: 132886768
Test: manual
Change-Id: Ifc0db2395a7503b1b03dcb796961ef6647c0413b
(cherry picked from commit f3231f417d)
> Only creating task overlay for one view at a time
> Fixing setOverviewStateEnabled called twice when going
between OVERVIEW and BACKGROUND state
Bug: 132815672
Bug: 122345781
Change-Id: I51ac5b0744af87194eca08e07fd2c75b8fa0d3e0
Test: Manual
Bug:119330044 P1 [STOPSHIP] Add back shape detection in Launcher icons
Bug:123900446 P1 App to home animation should zoom into the app icon
Bug:132298752 P1 Adding widget locks home screen page
Bug:132757019 P1 Swipe up twice quickly from app in 2 button mode; can't access all apps
Bug:133518678 P1 In 2 button mode, flinging up strongly favours quickswitch
Bug:133806285 P1 All apps causes overview to peek in
Bug:133844237 P1 Respect limited width Exclusion Rects in bottom area?
Bug:133867119 P2 Lab-only flake: want to switch from workspace to all apps; Swipe failed to receive an event for the swipe end
Bug:134062513 P1 Quickswitch sends lifecycle events to -1
Bug:134094839 P1 Launcher kept crashing on OTA update
Bug:134096917 P1 Launcher animation component gets stuck during swipe up
Bug:134164918 P1 STOPSHIP: Disable chips hard-coded value in qt_dev Launcher
Bug:134172603 P1 Tracing for lab-only flakes
Bug:134442147 P1 Sometimes All Apps won't update on app install/uninstall/update
Change-Id: Ia530fbf9bb5fa67b602ce44aef0cc4a1d1494e13
Normally, if all apps is open, and an app installs/uninstalls/updates,
All Apps will immediately reflect this.
However, depending on something subtle in the intensity of the swipe
gesture that brought All Apps, all apps will freeze, and won't update.
This frozen state will go away after scrolling in all apps, iteration
with an icon and, generally, any tap interaction with All Apps.
Otherwise, it will stay until it's closed and opened again via a gesture
with a different pattern.
The reason is in the code that freezes All Apps updates during user
interactions with all apps.
For example, during scrolls. Or while the user holds an icon, expecting
to see a context menu; in this case an update would cause the menu to
not appear, which is somewhat annoying.
The motivation to add this code was to solve a category of lab-only
flakes when a context menu couldn't open because the lab device was busy
with post-flash activities.
The code incorrectly assumed that after ACTION_DOWN, we are guaranteed
to get either UP or CANCEL, which is wrong.
It's after *consumed* ACTION_DOWN that we'll get these events.
The fix still solves the user's and tests' problems that the code was
supposed to solve.
Bug: 134442147
Change-Id: I9db74a33ecf93b1dc6bc69df301f7f542dea2a40
The process will crash anyway when loading sharedPreference. So
we do not need any extra check to cause the same crash.
Bug: 134094839
Change-Id: Icfd4406ff601d6b9a75bd95ddcecb9869f7e7fa2
Maintaining a boolean corresponding to overview or QuickSwitch which
updates the visuals for RecentsView accordingly
Bug: 134166337
Change-Id: If1aec99257de4db1796335f2cf39d2d35789915b
=> The WorkspaceTouchListener was relying on receiving TOUCH_DOWN in order to
clear its state. This is not guaranteed; ie. when touches begin above
children of the workspace (icons or widgets)
=> Any invocation of the Workspace long press menu would trigger this issue
and it would persist until a touch went directly onto the Workspace in a
location without any children.
Bug 132298752
Change-Id: Id8617baaa1ce59dc84758a7c82049329323b04cc
When ending in recents, we reapply the state - therefore, it's important
to make sure we are in OverviewState before onSwipeUpComplete(). This is
done by mLauncherTransitionController, which sets OverviewState on end.
We already force mLauncherTransitionController to end before calling
onSwipeUpComplete(), but in this case we were calling cancel() and
setting mLauncherTransitionController = null, which meant we could never
call end() on it. Instead, we should always call end() if we set it to
null.
Also ensure mLauncherTransitionController is created even if the gesture
is completed, if an existing controller isn't already running. This can
happen if you swipe up quickly enough that we get onGestureEnd before
launcher is drawn, and in that case we still want the launcher component
to animate once its ready. This is even more important for 2-button
mode, because again, we rely on mLauncherTransitionController to set the
state to OverviewState before we reapply it.
Finally, clarified some methods by renaming "swipeUp" to
"swipeUpToRecents".
Bug: 132757019
Change-Id: Ieb24a4f36a39780e5d64d7bc312791608db474d1
Winson Chung
vadimt
TreeHugger Robot
Hyunyoung Song
Sunny Goyal
Tony Wickham
Zak Cohen
Jon Miranda
Adam Cohen
Perumaal S