- Also remove old tinting based on textColorPrimary, as it's no longer necessary with dark intensity tinting.
Test: Run SetupWizardTestActivity in both dark and light theme, ensure back button visible
Fixes: 204384193
Change-Id: I2dc2e94bc0318ded62419b9ae0eed719db289d7f
* With new split screen running two active tasks for
a given gesture, we need to get all running task
infos instead of the single most recent used one
* TODO(b/210903248) for proper refactoring for
GestureState
Fixes: 205675364
Test: Swiping up on overview no longer crashes
Change-Id: Iea1f193149657182311a97f46007b4d43e8ad549
- Finish recents controller to app rather than to launcher, to ensure taskbar state uses in-app configuration
- Also fix an issue when a gesture completes before onLauncherStart, which happens in 3 button mode. The error I saw in the test was:
java.lang.AssertionError: http://go/tapl test failure: Failed to receive an event for the state change: expected [Overview], actual: [Background, Normal];
Context: want to switch from background to overview, clicking Recents button; now visible state is Background
(This also accurately describes what I saw on the device, where the LauncherState went to Normal but the task was still running in the live tile)
Test: testStressSwipeToOverview
Fixes: 203577620
Change-Id: I19616f7921c9821f1b45a90a3e4bec4fb3b8a9d3
Merged-In: I19616f7921c9821f1b45a90a3e4bec4fb3b8a9d3
(cherry picked from commit ce6bf7dd7f)
- Fix logic for canceling animation for continued quick switch, so that this case (starting a new gesture before onRecentsAnimationStart() of the previous gesture) instead goes to the STATE_FINISH_WITH_NO_END flow.
- Update the end target so that we go to that state instead of always overview state if swipe was past the halfway threshold when we call endLauncherTransitionController(). This is specifically so we don't use OverviewInputConsumer on the second gesture, given the first one was canceled and didn't actually go to overview.
- GestureState#isRecentsAnimationRunning() now checks for STATE_RECENTS_ANIMATION_STARTED rather than _INITIALIZED, to be consistent with its javadoc and TaskAnimationManager#isRecentsAnimationRunning(). This also ensures we can correctly calculate continued quick switch (see above).
- Call cleanUpRecentsAnimation() before creating a new one in TaskAnimationManager. This ensures that the previous listener doesn't immediately cleanup the new gesture when it gets onRecentsAnimationCanceled() due to the new recents animation starting.
Test: swipe to home twice from the app, locally ignoring the onRecentsAnimationStart() from the first one, and ensure the second one responds normally
Bug: 193851085
Change-Id: I76e27c96b54293805546c0d6c82e77f975c69d7a
Merged-In: I76e27c96b54293805546c0d6c82e77f975c69d7a
(cherry picked from commit 66ed0ff23e)
This makes the animation consistent with what happens
when swiping up to home.
Bug: 208292857
Test: open app, swipe back to close, test on portrait and landscape
Change-Id: I096b20fe3d3398001e442d41981350e7b0321a46
The original calculation was including spacing in the the
hotseatCellSize, but that causes us to incorrectly compute the
hotseatIconCenter. If we take advantage of
DeviceProfile.calculateCellWidth, we get the width without the spacing.
Then we can add spacing for every icon to the left of the current one
when figuring out the center.
Test: Manual on tablet using device types tablet and multi display.
Fix: 210123477
Change-Id: Ie182718ad3a229ffa8bae031f3ac7f73f8539f49
- Mainly a test issue where we destroy the activity and immediately
enter overview without preloading launcher. In this case, the task
bar does not animate due to the delayed cycled of activity create
-> bind service -> service connected -> taskbar ui controller init.
As a result, the bar can occlude content from Launcher preventing
the test from finding the overview actions.
Instead, in cases where we need to animate with launcher, we wait
for Launcher to be created (generally already the case) and the
service has bound before proceeding.
Bug: 189807374
Bug: 204891006
Test: atest NexusLauncherTests:com.android.quickstep.StartLauncherViaGestureTests
Change-Id: I2cfccae67ac0e5a591639c6c99df032451dae16d
Fixes: 208802276
Test: drag from all apps to normal, and the task bar doesn't stash until the user releases their finger
Change-Id: I53133cc80749bdc62e77d858b5714ae32facbd1d
- Update FLAG_IN_APP to account for setup state to ensure that the
stashed state is correct. This needs to be done in the stash
controller since SUW is the home activity on startup and the
launcher state controller will not be initialized until after
SUW finishes
- Initialize the launcher state and resumed flags in case Launcher
restarts while another app is resumed
Bug: 204384193
Test: Run through SUW, ensure the background is not visible
Change-Id: I5ce061ad16e79226c8428339ccd0b5ac55c07205
Also only reloadIfNeeded() instead of always reloading in showCurrentTask(), which is called twice as the gesture starts and could contribute to jank.
Test: quickly quick switch from app A to B, ensure no jumpcut back to A
Bug: 205499708
Change-Id: I516020551d3f76eb4025df848bf4c88adf5499b7
Task bar draws fake rouned corner above itself and it should notify
system to report that fake ones to apps.
Bug: 196387239
Test: make
Change-Id: I1d9732de71fbe653ed56e468e211b1bfb4dd2b37
LauncherActivity uses FLAG_SLIPPERY for certain interactions. For
example, when home screen is shown, and the user pulls down from not the
top of the screen, and notification shade is getting displayed, then the
touch should be getting transferred to the NotificationShade using
FLAG_SLIPPERY.
The newly introduced permission is added to launcher in order for this
flag to be applied to the window.
Bug: 206188649
Bug: 157929241
Test: reviewed logs, ensure that NexusLauncherActivity has FLAG_SLIPPERY
Test: re-ran the performance regression test
Change-Id: I8d05fa3663687b5382a59b0d47cdac404844c3b7
This CL adds toggle notification panel function for new buttons in Kingyo taskbar.
Bug: 199333223
Test: m, verify that clicking the new buttons will expand/collapse quick settings and notification panel
Recall: http://recall/clips/993bc14b-98a7-4d7d-98c4-17ba271d4da9
Change-Id: I8c7383d2efa6f15de10a50173cfff86ab20ebb4c
Cherry picked from commit 53db50dd0b2bd6ed1842b25396c9c52b7abe1157
after resolving conflicts
The CL adds two new buttons for desktop usage.
No listeners are registered yet.
Recall: http://recall/clips/f52b70ed-c437-4374-a492-e4b7c802520a
Bug: 198355239
Test: m, verify that new buttons are added
Change-Id: I1d4a12da3041e113a978c37c9e36ec085d15e8b3
This avoids changing them when going from an app to launcher (most obvious when going to overview).
This also allows us to not change insets on apps when opening/closing IME, which reduces potential jumpiness.
Finally, also use this logic for 3P launchers by calling directly from TaskbarDragLayerController instead of TaskbarUIController (which was only overridden by LauncherTaskbarUIController). This fixes some bad issues like sending fullscreen insets when opening a folder from taskbar.
Test: Open Calculator, unstash taskbar, go to overview and ensure no jump as taskbar stashes.
Fixes: 200805319
Change-Id: I4f1cc187398d0051863ff44ea90b7ab9c6aaa8f9
We set mIconAlignmentForResumedState in endGestureStateOverride(), but then we call applyState() which might aniamte mIAFRS to a different value. To avoid this, set it after applyState() instead.
Specific repro:
1. Open Calculator
2. Go to Overview
3. Dismiss Calculator
3a. This calls endGestureStateOverride() because the running tile ends
3b. Previously, we called mIAFRS.updateValue(1) but then applyState() animated it to 0 because we're still in Overview which is an unstashed state. Now the animation to 0 is before setting explicitly to 1.
4. Go home (this sets mIconAlignmentForLauncherState = 1)
5. Open Calculator again. Previously, mIAFRS was already 0 so animating to 0 was ignored. Now, mIAFRS starts at 1 (which is right since launcher is resumed).
Test: see above
Fixes: 210109500
Change-Id: I13f40908f8636291d63ef4b885ac9d08bbf4d393
- In split select there is no overview actions, and focused task's snappign position is not centered, it's weird to snap so avoid it
- Follow-up of ag/16378986
Bug: 208644826
Test: manual
Change-Id: I260b5c6164db562717346396b1830af02d408944
Also, pass a PictureInPictureSurfaceTransaction to hide the tasks in
split-screen from Launcher to WM to avoid flicker when any one of the
tasks enters PiP.
Bug: 190855091
Bug: 205894095
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/42RWtayanp2qG0mHSf4Q5
Test: manual, enter PiP from split-screen, see Video
Change-Id: Ia8b6243c0d95c2be8007beeefa2083acc856e404
TreeHugger Robot
Vinit Nayak
Tony Wickham
Jon Miranda
Winson Chung
Brian Isganitis
Shuming Hao
Tracy Zhou
Shawn Lin
Siarhei Vishniakou
Daichi Hirono
Alex Chau
Hongwei Wang