This was a rare case (made less rare by rocket gesture) which was
not actually updating the UI correctly.
Expected flow:
1. All Apps is inflated with a single recyclerview for apps (as
defined in xml).
2. Later, rebindAdapters() is called, and if there are work apps,
the recyclerview is removed and replaced by a viewpager with 2
children recyclerviews (one for personal and one for work).
3. At any point if you start searching, the app rv or viewpager
is hidden and the search rv is shown.
Actual flow in the error case:
- Same as above, but if you were searching when 2 happens, we
returned early, so we never replaced the app rv with the
viewpager, so all the apps were dumped in the single rv, and
the header with tabs showed above it.
Fix: 272575605
Test: Manually force first rebind ta happen while searching, and
verify this bug was hit before the fix but not after.
Change-Id: I25b8991564645368840a390733aa893dee4cd10e
> Using a single layout for the all-apps content
> Removing some unnecessary themes
> Fixing search chashes in SecondaryDisplayLauncher
Bug: 259733681
Test: Existing TAPL tests verify that Launcher/AllApps work properly
Change-Id: Icd5310316499cd421bc039cdbd4d398b813cd477
This and the other change in the topic are protected by a new feature
flag (included here).
Bug: 229297414
Bug: 248006105
Test: manual (see screenshots and recordings in the second bug)
Change-Id: I3478d7e194ee5d3bc4f8affdadbec969c033d084
This is the more comprehensive version of ag/20119299.
Improvements compared to that change:
- Icons on the same row animate together (as opposed to the
first icon on the row animating separately)
- Multiple rows of predicted apps are supported (any beyond
the first row are animated like everything else)
--- Original description ---
Example BubbleTextView: WhatsApp/Gmail conversation shortcuts.
The issue was we were treating these the same as the top app
row, but we were assuming there would only be 1 such row, which
messed up the measurement logic. At the same time, the logic
specific to that app row was redundant with the new logic for
rows containing mulitple items.
This solution does 2 things:
- Removes special logic for app row (it now uses the same
logic as other rows with multiple items, i.e. uses the span
index to determine the height of the row)
- Keeps the scale/alpha at 1 for the first row of app icons.
This currently only applies to predicted apps, but if there
were multiple app rows in the future, the additional rows
would animate the same way as other rows (see demo videos
for an example with double predicted apps in 0 state). In
the conversation case, the other icons are deep shortcuts.
The result is the app row still does what it did before (stays
fixed at full size/opacity), and deep shortcuts like the ones
used for WhatsApp and Gmail animate like other rows of items,
such as screenshots.
Demo videos: https://drive.google.com/drive/folders/1GPQNIwMfuj9ZdAbRrh-K75C5xJYT4Gzo?resourcekey=0-ojO6VGetEBy5YTq4roFmlw&usp=sharing
Test: Manual with and without inject_web_top (which moves app row)
for WhatsApp and Gmail with AiAi fishfood.
Bug: 239927522
Change-Id: Ib2ca97b93798cb57eb55545eeba8be9322484f7d
This is a simplified version of ag/20118087. It fixes the bug
with rows of shortcuts being in the search results (e.g. Gmail
and WhatsApp conversations), but it will not handle cases where
there are multiple rows of app icons. Currently I do not know of
any cases where that would happen.
Test: Manual with and without inject_web_top (which moves app row)
for WhatsApp and Gmail with AiAi fishfood.
Bug: 239927522
Change-Id: Ie9c62c0ee81086801942328c8770f37d5bf622c3
This prevents touches on the profile buttons (which were already
hidden due to the header view having alpha 0, but touches were
still registered).
Fix: 248338523
Test: Manually tap where the work profile button is before and
after this change. Before: switches to work profile. Afer: does
nothing in 0 state; otherwise launches item at that position.
Change-Id: Ie30661146d25740000d7a9cbe79234ac15347253