- Refactored Taskbar animation duration to under one method and added logic to sync animation duration according to enableScalingRevealHomeAnimation.
- Change the interpolator for TaskbarLauncherStateController based on enableScalingRevealHomeAnimation.
Test: Presubmit, Manual
Bug: 369378541
Flag: EXEMPT Bug Fix
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:0a65c5bd72d755856148faeb070a5d2ad2c79cb0)
Merged-In: I942829b475f91e9102801b758eb7ee0d27eee912
Change-Id: I942829b475f91e9102801b758eb7ee0d27eee912
* 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
Does not implement any animations.
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Fix: 356394053
Test: go/testedequals
Change-Id: If8e319b605beedd0e9b14dc37da1b5ffa12f3c9f
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
- 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
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:a9355d4dba3f0bf93cb1a28eb738c6c05dc43ca9)
Merged-In: I8ca3cdfa6f849bce5d347f14038e1ebd6bc6ff06
Change-Id: I8ca3cdfa6f849bce5d347f14038e1ebd6bc6ff06
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
Marcelo Arteiro
Mykola Podolian
Anushree Ganjam
Artsiom Mitrokhin
Android Build Coastguard Worker
Jagrut Desai
Uwais Ashraf
Treehugger Robot
Toni Barzic
Brian Isganitis
Brandon Dayauon
Sunny Goyal
Jordan Silva
Orhan Uysal
Alex Chau
Liran Binyamin
Winson Chung
Randy Pfohl
Schneider Victor-tulias
Charlie Anderson