When the animation get canceled, cleanupScreenshot() should
be run instantly because it does something like removing
pending animations. The switchToScreenshot() attaches it to
RtFrameCallback which only be called on frame update. This
is leading to problems as the next frame update may only
happened when the next gesture starts, which means all the
pending animations will be removed on next gesture. And then
the next gesture freezed.
Fixes randomly gesture freeze since 12L.
Change-Id: I10247294a2dcae467706c434685b299f8b525888
Signed-off-by: LibXZR <i@xzr.moe>
Signed-off-by: Pranav <npv12@iitbbs.ac.in>
- Also have Taskbar report itself as MANDATORY_GESTURE_INSETS
Test: Able to drag bottom workspace items
Bug: 205493938
Change-Id: I014991b1cc6dbd66fa275a7766304ebd92171328
The swiping up gesture will never return an app in All Apps,
so we can ignore All Apps state in those cases.
This fixes an edge case where user swipes up and launcher state
is still in All Apps. This causes us to animate the icon to
where it would be in All Apps, even though by the time the
animation starts we are actually in Normal state.
Bug: 222124240
Test: open app from all apps then quickly swipe up to go home
Change-Id: I756a870660a397d6629aec82e4f5ec4914ed0669
(cherry picked from commit b42e124f5b)
The launch cookie can now be transfered via the broadcast
Fixes: 220290671
Test: add Photos widget, return properly to widget
Merged-In: Ibfe9e5232317837f3111459212a4b016b5828ef4
Change-Id: Ibfe9e5232317837f3111459212a4b016b5828ef4
- 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
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
(cherry picked from commit db767aa575)
Merged-In:Iaec77d15c9533edccd9c82164143af8fa522158f
- 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
(cherry picked from commit bb530e9058)
Merged-In:I1b1296fab316b979f441ebb474d1475e3fa68f95
- 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
(cherry picked from commit eff9a120c6)
Merged-In:I5f8cfd357ff13971fe172ce1d0179535479cd26c
* 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
