- Refactor the util method to create the animator and track the existing
animation in AbsSwipeUpHandler to be able to cancel it if another call
to change the visbility comes in. Note that this doesn't address
the case where the launch animation overlaps with swipe up (though that
hopefully shouldn't happen in normal usage)
Bug: 213403679
Test: Tap in the gesture space while split
Change-Id: I078a7d0f22c2ef2ba847796ec79e740c789ce1ae
Merged-In: I078a7d0f22c2ef2ba847796ec79e740c789ce1ae
* Pass back an empty WorkspaceItemInfo with correct
itemType set on it so at least it can be identified
if remaining fields are missing.
Fixes: 218625473
Test: Wasn't able to repro crash
Change-Id: If20d8fa648edf6c210ad5398905bf78e173b23a1
* Other checks haven't changed, only pulled them out into
separate block
Fixes: 215699962
Test: Unable to repro the crash, I tried ending the
activity and starting via adb shell, but I was never
able to get into the original if-block that triggered the NPE
Change-Id: I83320634f1d059de610176f9031682ca287bd589
- Fixed icons disappearing when initiating dragging
- Fixed incorrect icon location when initiating dragging after rotating the screen to an orientation other than what launcher started in
Fixes: 215418478
Fixes: 214025075
Fixes: 210460544
Test: dragged icons from the workspace and taskbar
Change-Id: I848138af28802f7d806708c77c25b8de307c70d8
(cherry picked from commit 312b68fde4)
Merged-In: I848138af28802f7d806708c77c25b8de307c70d8
- In some cases WM won't callback the remote animation callbacks (neither
start nor cancel) and Launcher never finishes executing the pending
command (preventing the subsequent commands from running). For the time
being, just cancel the current state to allow the commands to be
processed.
Bug: 194011186
Test: Mash on overview and home buttons with a 3p launcher
Signed-off-by: Winson Chung <winsonc@google.com>
Change-Id: I1b1296fab316b979f441ebb474d1475e3fa68f95
Merged-In: I1b1296fab316b979f441ebb474d1475e3fa68f95
One way to reproduce this issue is to run `adb shell input keyevent KEYCODE_HOME`, which happens to pause and immediately resume launcher. For example, let's say we run this while in All Apps. Because the isResumed=true comes before the state transition to Normal, we behave as if we are still going to All Apps, specifically goingToUnstashedState = false (since we stash in All Apps). To fix this, we now listen to state changes while the resume alignment animation is playing, and update it if necessary.
Also did the same correction for the gesture alignment animation, though I don't have a specific repo for that.
Finally, because there are now more triggers for alignment animations to play, we add a check to only play them if it's not animating to the same value it's already animating towards. One notable experience this improves is swiping down from All Apps to home; if you do it quick enough, the state animation ends before the taskbar unstash animation, and thus the unstash animation would cancel and start again with the full duration, making it look laggy/disjointed (this behavior existed before this change as well).
Test: TaplTestsQuickstep
Test: Go to All Apps, run `adb shell input keyevent KEYCODE_HOME`, open an app and ensure taskbar icons are visible
Test: Quick switch from home when taskbar is present in apps, but instead go to overview; ensure no jump when taskbar stashes
Test: Swipe down quickly from All Apps, ensure taskbar unstashing doesn't slow down when reaching the end of the state transition
Fixes: 214562370
Change-Id: Ie0c6140e14186e41c7e4748dc745f87349b084fe
Merged-In: Ie0c6140e14186e41c7e4748dc745f87349b084fe
(cherry picked from commit 5fa2ed27bf)
- Touch explore uses hover events to focus views for accessibility, but
we were dropping these events when handling them through the input
consumer proxy. The reason this changed is that in sc-v2 we moved the
recents input consumer to the top of the task display area to ensure
that it was always above any of the tasks in splitscreen, but by doing
so, it was always above launcher even after settling in overview. The
existing path for handling motion events is heavily tied to touch
handling (action down/move/up) so we just add a separate path for
dispatching hover events through the normal mechanism to launcher via
the consumer.
Bug: 197043796
Change-Id: I5f8cfd357ff13971fe172ce1d0179535479cd26c
Issue is that All Apps is scaling during the animation, so when
FloatingIconView looks for it in the view hierarchy,
it's not in its final position.
This would be the cleanest approach for a scv2 fix
Bug: 213306709
Test: manual
Change-Id: Iaec77d15c9533edccd9c82164143af8fa522158f
Merged-In: Iaec77d15c9533edccd9c82164143af8fa522158f
Fixes: 211556489
Test: Go to overview with live tile. Turn on dark theme. Pull the panel back up. Make sure everything looks fine (live tile is ended).
Change-Id: I51cb81718a489ad7568c5e05ace0b3dbc6ca5443
A request to set a new depth is ignored if the surface is currently
invalid. We should cache what was the requested value, so it will be
applied once the surface is valid again.
Test: manual
Fixes: 209028986
Change-Id: I812816da4b0139c7ea7b53a9fb00f11265ecdea8
* Old code assumes there will only be a single
GroupedTaskView, removing those code paths helps
consolidate single and grouped task code flows
* Correctly check when we need to add a stub
taskView for GroupedTaskViews by checking each
individual taskId
Test: Swiping with multiple split pairs doesn't
cause a cycle
Fixes: 213355942
Change-Id: Ibb98ae0dfcd4f52b762685aec9d2ee6445b9ef54
* Non-apps leashes can contain non-divider targets, which
was creating null elements in the array when an index didn't
get assigned.
* With a list we don't have to worry about empty index gaps
* Also remove the animation for the divider for certain
gestures because the surface isn't always valid for the
full duration of the animation. We probably would need to
synchronize with rest of recents animation
Fixes: 212218930
Test: No longer crashes when swipe up, hold, then swipe down
Change-Id: Ia1fc4d66e73f21b55fdbfe59342af025e2a525d9
* Consolidate setState() and setStateWithAnimation()
to be handled in the same manner
* If no animation, we run the created
PendingAnimation right away
Fixes: 209935590
Test: Tested w/ and w/o animation
Change-Id: I1d6fdba21761b6721e6bd52234016178547cd437
* Whenever launcher setting is changed, only log the changed setting instead of all
Bug: 181703659
Test: wwdebug && wwlogcat AND statsd_testdrive 10108
Change-Id: I9c6b7a17d653038a91f885df455e5ebbb401b49a
Merged-In: I9c6b7a17d653038a91f885df455e5ebbb401b49a
(cherry picked from commit f7ebfb9a7f)
* Previously we were removing all targets except for
the app that was to be animated. That caused issues
because we look for the home app to determine if the
app leashes need to be drawn underneath or not.
* Now (assuming at most two non-home app leashes will
be sent) we add all the non-home targets along with
the desired app target by excluding 1 of the 2 non-home
apps
Bug: 199936292
Merged-In: I252d6c663e9ca145ef394ac08d9a32da02d4a03b
Change-Id: I252d6c663e9ca145ef394ac08d9a32da02d4a03b
- Skip updating nav button dark intensity if we're setting it manually
while SUW is running
- There should only be one alpha StatePropertyHolder for the same view
otherwise when updating the properties it can clobber a previous state
Bug: 204384193
Test: Disable dark mode on SUW and verify nav buttons show
Change-Id: I450c3a5697954d9b464bdd622847beb2d01f3802
