Fix drag surface would be stuck (1/2)

- If a window is removing, and perform drag-drop at same time,
  transferTouchFocus would fail because the window can't be found in the
  inputflinger.

- If there is no touch down on the drag window, it should not allow to
  drag.

- If perform drag successful, and a touch up sent out at same time,
  the transferTouchFocus might fail because there is no touch state for
  the calling window.

This patch would add syncInputTransactions to ensure input windows
information has been propagated to native InputManager.
So transferTouchFocus can base on current input windows information
to check if it should allow the drag-drop.

Also use the same transaction to control drag surface to prevent wrong
order cause surface can't be dismissed.

Bug: 137819199
Test: atest WmTests:TaskPositioningControllerTests
Test: atest DragDropTest
Change-Id: I382bc1fb04e1f4469df2c512f9e0f2542bbd2390
Merged-In: I382bc1fb04e1f4469df2c512f9e0f2542bbd2390
(cherry picked from commit b62e500e63e60463adb7b35f7543fd8c82273026)

0 files changed, 0 insertions, 0 deletions