Extremely rarely, All Apps will get stuck in a non-updating state even
after the interaction ends.
It would be impractical to try drilling to the root cause of this,
so it's better to just allow All Apps updates while the user interacts
with it.
Bug: 139384936
Change-Id: I2ed7fb052da77a9e47ef9b9aa7800499071b98c3
This CL adds a very low risk because most (but not all) changes affect
only Launcher behavior during the test.
This should fix a lab-only flake when all apps keeps changing while
the test is working with it.
Example: test figures out which icon to click, by the moment it clicks
there, there is another icon there, or the icon is under the search box,
and clicking opens IME.
Switching test devices to airplane mode didn't help. The earlier change
that prevents popup menu cancellation is not general enough.
Now the tests are given an API to explicitly freeze and unfreeze
all-apps, which should be a final solution.
Bug: 132900132
Bug: 133765434
Change-Id: I8b81cc9be004482beb6cdcdd05406e2d9b4c7629
This will reduce confusion with the other "badging" concept we use for,
e.g. work profiles. It is also consistent with the external name
"notification dots".
Change-Id: I2a2c9d96dc0d6284eb0c48adc78a856271caad4d
We were only deferring full apps binds and not partial updates which could cause
the model to go out of sync with Launcher.
Bug: 72051234
Change-Id: I20db0e86aadd1e6a518237026f6dfb03e469eb87
Derivative projects can extend the FloatingHeader to add support
to custom content in all-apps screen.
Change-Id: I4e29221a72e5a077a756713a6774cda7ecde8f1b
vadimt
Sunny Goyal
Tony Wickham