We had a resolved case in the past where an app's context menu didn't
open on a long click (thanks to app updates), now the menu opens, but
the drag gesture doesn't drag the icon.
Bug: 133009122
Change-Id: I45d104a92fab6556ecd937aef76f0a8147e67f56
Insets are dispatched to all views. We never consume the insets and
let each view decide what to do with it.
Also fixing scrim in all-apps when in full-gesture navigation
Change-Id: Ib1c6bef5b32aac0c6ea03078b5138d2d0408c6d8
Workspace and hotseat are drawn in rotated UI giving the impression that the
device is in Portrait, even though it is in landscape
Bug: 131360075
Change-Id: I29c4068af25fd4dcf7039b9a45886e864a137977
In draglayer, we always dispatch touch events to child views. If the
touch originated from gesture area, when we dont route it through touch
controllers.
The proxy events are only send to touch controller. If any controller consumes
the event, then we cancel the view touch (pilferPointers)
This allows the controllers to work outside the dragView area, and prevents normal
view interaction when there is a window on top (like keyboard) while keeping our
activity focused
Bug: 131088901
Bug: 130618737
Change-Id: If033dde3a0f9cb6a6e449c9586c1fa050af5bdcb
It was obstructing views under it.
Solves both Talkback and Switch Access issues.
Bug: 80192025
Test: Manual
Change-Id: Ia7fad91e1fcb857afbf68f879550c670279cee68
> Using common logic for announcing a floating view for widgets and folders
Bug: 79091095
Bug: 79748886
Change-Id: Ibb3fe48e68e724f50d69f51a03d3b35ad0baf625
I'm not sure how/when this case occurs (perhaps during some transition/state
change), but manually removing the floating view matches the symptoms in the
bug.
Bug: 72996404
Change-Id: I1e7c1a338fcd16c8e07b3c49fb9c9b2097eb2708
> Extracting common methods from Launcher & DragLauncher to base classes
> Remoting some dependencies on Launcher and using the base class instead
Change-Id: I121cacf8a14190b4703cda60bdeb4f79eee69ded
