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
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
Sunny Goyal
TreeHugger Robot
Vadim Tryshev
Jon Miranda
Tony Wickham
Zak Cohen
Winson Chung
Perumaal Shanmugam
Hyunyoung Song