> 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
=> 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
In disabled states, dragLayer should not receive touch anyway. Removing
the additional check to avoid user getting stuck.
Bug: 134062513
Change-Id: Id31a31254377e9a737ecd6e9905e66c54e4eb740
* Mostly value changes.
* Added a way to round the corners during swipe up to home animation.
Bug: 123900446
Change-Id: Id61d241d919ba51ced0633585e36b7d93efe30b0
notifying LauncherCallback accordingly
During quick switch Launcher can get resumed only to be paused again
when launching a new app. Updating the logic for deferred resume to
account for that and moving some additional calls to deferredResume
Bug: 134062513
Change-Id: Ia607f178bc17d45d53fb032a06cd70f9abc6b513
This time, Launcher doesn't send a completion event upon switching from
Home to all apps.
Bug: 133867119
Change-Id: I3738cf10a14ea288df2dfda387aafda022beb349
During AppWidgetRestoredReceiver, we call forceReload from worker thread
which in turn starts the loader while holding mLock. This causes other
loader calls on UI thread to cause ANR
Bug: 133651528
Change-Id: Iabf983c4319bd6e6ef88e74fe6076289294454f9
The bug is caused by launcher saving the grid name and using that grid name
to look for matching display options. This makes sense when changing the grid
size, but doesn't work well when changing the display size.
Example: Initial Pixel display size is set to Default, so we save "normal" as
the KEY_IDP_GRID_NAME. When we change display size to Largest, the
KEY_IDP_GRID_NAME is still "normal" and so we only look at display options
under "normal". Before this, Pixel with display size set to Largest would be
set to "reasonable".
This should be safe change for Q, and we can have a proper fix when we
officially support changing grid size.
Bug: 131867841
Change-Id: If5f3b0a13b90069973e929024b26bd9b9c45a7d8
This eliminates an unreliable timeout.
Also removing an unnecessary check for harness that is done by the
called method.
Change-Id: If954580060415cbb2952532c16ea0ae4dc7b9469