Expand the bubble bar when the user taps on the flyout view.
Flag: com.android.wm.shell.enable_bubble_bar
Bug: 277815200
Test: atest BubbleBarViewAnimatorTest
Test: atest BubbleBarFlyoutControllerTest
Change-Id: I156acfa663d6a00bc70dd7bbfc35642643902d83
Added a method to the device profile to calculate the vertical center of
the hotseat icons. Simplified the logic for positioning the bubble bar.
Test: TransientBubbleStashControllerTest
Test: PersistentBubbleStashControllerTest
Test: Visual. Go to home page, check that bubble bar is vertically
center aligned with the hotseat
Bug: 345491493
Flag: com.android.wm.shell.enable_bubble_bar
Change-Id: I52f1b94de79f6c912f43a88fcc5c884e20e56310
If a user pins the taskbar and immediately swipes to home, this would
show the taskbar edu tooltip on the home screen. This change checks that
taskbar isn't transitioning to home to prevent that scenario.
Fix: 369061563
Test: Reset Search Taskbar edu, pin taskbar, then swipe to home
immediately. Ensure that the edu doesn't show up on home
Flag: EXEMPT bugfix
Change-Id: I9948189df880b3ed318c4952a8f715cf9a7fa708
Creates a new view for the taskbar overflow button that draws up to 4
recent item previews. The items are stacked on top of each other in
counter clockwise order, with overlapping bounds, recent items closer
to the top. The item icons have a 2 dip ring around them, of the taskbar
background color.
Adjusts logic to calculate which items become part of the overflow
button, so more recent items get shown in the taskbar.
Initial consideration was to usse FolderIcon to represent the overflow
button, but decided against it because:
* FolderIcon is fairly entangled with the associated folder view
* item information uses different data structure (ItemInfo) than
recent items (GroupTasks)
* item preview layout within the main icon is similar, but
sufficiently different that using clipped folder layout rules felt
like hacking around assumptions made for folder icon UI
Bug: 368119679
Test: Keep opening apps until the task bar enters overflow - verify that
overview button shows up, and contains least recent task
representations. Keep adding items, then closing windows, and verify
the icon gets updated accordingly. Done in landscape and portrait, and
ltr and rtl layout.
Flag: com.android.launcher3.taskbar_overflow
Change-Id: I2824cb0db1f7516ebd74361ce00fb8887857325d
Bug: 368119679
Test: open KQS via taskbar and observe the bounds change
Flag: com.android.launcher3.taskbar_overflow
Change-Id: I5060a339cf0cdf70a2a11b57a325767405772ef8
Removed calls that were stashing and unstashing the hotseat bar.
Flag: com.android.wm.shell.enable_bubble_bar
Test: Manual. Be on Launcher home, have some bubbles. Expand / collapse
bubble bar. Hotseat remains behind the scream view.
Fixes: 373429249
Change-Id: I1a9ba39c8ca11d49340f217f095d5e872b06105b
Continued quick switch couldn't work using existing infrastructure until RecentsWindowManager could be properly tracked by ActivityTracker. Refactored ActivityTracker into ContextTracker to support this.
Also refactored ActivityInitListener into ContextInitListener to fit the updated pattern.
Flag: com.android.launcher3.enable_fallback_overview_in_window
Fixes: 366023051
Test: RecentsWindowSwipeHandlerTestCase; Attempted continued quick switch from home and launched app
Change-Id: Ic38ebf3611ef22fbfd1ddeb79d72d8a3621940a0
Fixes the condition that defines which task should be the focused task when grid-only is enabled and desktop windowing is the running task.
In some cases, when the user adds or removes a task from Desktop Window, the DesktopTaskView does not get updated with the new list of tasks. This causes a mismatch of tasks that are inside the DesktopTaskView and the actual Desktop Windowing. So, RecentsView can't match the previous DesktopTaskView with the current running tasks, entering a specific condition to update the runningTaskViewId. The method called in this condition (showCurrentTask) also updates the focusedTaskViewId for some situations. This CL fixes the conditions which focusedTaskViewId is set to prevent it to replace the focused task id when it's not needed.
Fix: 370736395
Flag: com.android.launcher3.enable_large_desktop_windowing_tile
Test: Manual
Change-Id: I25f5bd67ee0486f6754673eec404832779fc0498
* changes:
Set task properties to prevent the task being null. This behaviour is expected by existing callers and was likely broken by ag/28151977
TaskRepository performance improvement
When laying out its contents, TaskBarView generally lays the icons so
they get centered in the task bar - this is done by calculating the
total size of all icons during layout (this will generally be transient
taskbar icon sizes), and substracting extra margins that get removed
from the divider view. After initial layout, `TaskbarViewController`
adjusts the icon view positions to match expected icon sizes (it
offsets icons horizontally reducing margins between icons to match
intended icon sizes for the taskbar type). Additionally,
`TaskbarViewController` translates all apps button container - this
transformation is asymetric, and causes the task bar contents to become
off-center. To account for this, update taskbar layout to reduce the
total icon size used for centering icons by the amount all apps button
is offset. This makes the taskbar off-center after initial layout, but
by the amount by which all apps button is eventually offset (resulting
in centered taskbar content).
This alone worked for left-to-right UI direction, but not right-to-left.
To fix this, correct the reference point from which
TaskBarViewController offsets icon positions. The offset used to be
calculated by distance of an icon index from half of the icon count -
instead offset needs to be calculated relative to mid-index.
For example, icon at index i needs to be offset by
(mid_index - i) * difference_in_icon_size: ((n-1) / 2 - i) * diff).
Code used to work for LTR UI layout because the list of icons contained
invisible qsb view, which incresed both n and indices by 1, so
(n' / 2 - i') * diff_in_icon_size worked fine, as it evaluated to
((n + 1) / 2 - i - 1) * diff = ((n - 1) / - i) * diff
Bug: 372567501
Test: Verify that taskbar icons are centered when it needs to be, both
with ltr and rtl language UI.
Flag: EXEMPT bugfix
Change-Id: Ic06873cc225a4361d9140d72c055db23f446a1ad
This CL improves Overview's performance by preventing multiple thumbnail and icon fetches for visible tasks. It introduces manual cancellation and removal of tasks that are no longer visible to prevent fetching and listening to changes in such tasks.
- Renamed 'augmentedTasks' to 'tasks' and updated it to be a MutableStateFlow with a map of Task Id and Task.
- When a new task becomes visible, the task is added to a list of requests along with a Job that fetches the Thumbnail and Icon. Additionally, 'taskVisualChangesDelegated' is added and removed for that task per request.
- When a task becomes invisible, the Job is canceled to prevent fetching the Thumbnail and Icon. The thumbnail and icon are cleared from the list of tasks, and the listener from 'taskVisualChangesDelegated' is unregistered.
- The list of tasks is updated when the list of visible tasks changes and a new thumbnail or icon is updated. This list is also updated when a force fresh from getAllTaskData is requested.
Fix: 373361888
Flag: com.android.launcher3.enable_refactor_task_thumbnail
Test: TasksRepositoryTest
Change-Id: Ifd9c54fdfcb85463c043c121fb829dec3e9faedc
When opening 5 instances of Chrome in Desktop Windowing, navigating back to Overview and trying to split a new Chrome instance from the Taskbar resulted in a crash.
This happened because SplitSelectStateController searches for the last active task of the app chosen to be in split. Then, it returns its taskId that is used in RecentsView to find the TaskView to be animated to split.
However, after the 5th Chrome instance in opened in Desktop Windowing, the last active taskId is no longer visible in Overview or Desktop Windowing. Then, RecentsView won't find any TaskView with that taskId and mSplitHiddenTaskView will be null. This will result in a crash because we have some if-else conditions assuming that is not null because of mSplitSelectStateController has a task to be dismissed during the split animation.
More info in the bug report.
Bug: 372400577
Flag: EXEMPT bugfix
Test: Manual. Steps in the bug report.
Test: Manual. Open 5 windows of Chrome in Desktop Windowing. Go Home. Open a Fullscreen App. Go Overview. Split a new Chrome instance from the Taskbar.
Change-Id: I0f3757e898b606b4e0a180f43c73f1e2d887e996
This CL didn't improve the performance metrics significantly enough to use Executors.MAIN. b/366077002#comment12
This reverts commit 7eae20bcb1.
Reason for revert: 366077002
Change-Id: Ic92b83a65aef7f8cd5c00110fb1ab7343d4b12b6
- Added comments to clarify pivot/drawBelowRecents is only needed if live tile isn't launching
- Otherwise TaskViewUtils.createRecentsWindowAnimator already take cares of the scrol offset and drawsBelowRecents.
Fix: 361744056
Test: manual
Flag: EXEMPT refactor
Change-Id: I10e7d72daaa13787a9fd19524f7f45c4b0d31642
The number of tasks to show should not be limited when KQS gets shown in
desktop windowing - instead of enforcing the limit on tasks shown in the
KQS view itself, trust the KeyboardQuickSwitchController to pass in
correctly sized list of tasks to show (KeyboardQuickSwitchController
does limit the task list size passed to the view).
Bug: 374329990
Test: Open 6+ tasks in fullscreen, and in desktop windowing. Verify that
the number of tasks shown in KQS is limited to 6 when shown from a
fullscreen app context, and not limited when shown when in desktop
windowing.
Flag: EXEMPT bugfix
Change-Id: I245d05239f2fc025ef40085aff4bece694e0f76c
When a bubble is created or updated we now animate the flyout view
as part of the bar animation.
Note that the flyout is not clickable yet, and that we're not yet
handling bubble notifications interrupting each other.
Flag: com.android.wm.shell.enable_bubble_bar
Bug: 277815200
Test: atest BubbleBarViewAnimatorTest
Test: atest BubbleBarFlyoutControllerTest
Test: manual
- verify flyout view is showing when creating bubble
- on home
- in app
- when bubble bar is empty
Change-Id: I315e46c89a4d20aaaa22972f0d71290a63481d9d
- If the TIS instance is destroyed, then we should remove any queued
user-unlocked runnables to ensure that they do not attempt to run
again
Flag: EXEMPT bugfix
Bug: 373671447
Test: atest NexusLauncherTests
Change-Id: I8ca3cdfa6f849bce5d347f14038e1ebd6bc6ff06
Mykola Podolian
Brandon Dayauon
Saumya Prakash
Wen-chien Wang
Liran Binyamin
Treehugger Robot
Sihua Ma
Toni Barzic
Schneider Victor-Tulias
Jordan Silva
Artsiom Mitrokhin
Uwais Ashraf
Sunny Goyal
Orhan Uysal
Alex Chau
Winson Chung