ReusableWDVH: Do not update the view host of the child if already same.

The idea of the ReusableWDVH is to quickly swap out App Header<->Handle,
while reusing them without reinflating the views. The way it works is
that upon needing to swap, ReusableWDVH will remove all the child views
and add the new view as its child, removing the need to create a new one
just because the view hierarchy has changed.

However this process is called currently inside
DesktopModeWindowDecoration#relayout, which gets called in numerous
places. Two instances:

1) Dragging the app header while in freeform when not-focused (z-order
changes) 2) Dragging the app handle while in vertical splitscreen and
task is at the bottom (onTaskChange called because of Recents animation
launch)

Both of these cause a new transition change, which calls on a relayout,
in the middle of a gesture. When ReusableWDVH removes the children and
re-adds it back, despite removing/adding the same view (in this case,
the caption bar view), because of the removal, ViewGroup implementation
will cancel the on-going gesture on the caption bar thus stops the
entire gesture altogether. This causes issues for 1) where it brings it
to front focus but no longer draggable until user starts another
gesture, and 2) causes a cancel event to the decor view mid-dragzone
from splitscreen.

Instead, by not removing/re-adding the view if the ViewHost is already
the view's parent, then we can stop the gesture from being cancelled.

As an added note, this is not an issue for the regular drag-to-desktop
use case, since the gesture of that starts in the status bar, in which
the caption bar below it acts as a spy window, so ViewGroup actually
never sees the caption bar as the one actively receiving input; so the
cancel event, despite generated, does not go to the caption bar.

This also addresses an issue where our threshold for launching Recents
is always calculated from Y=0 since we assume it's dragged from the
status bar. In the vertical splitscreen case, it is actually the task's
top-Y coordinate, so we will use that as the offset.

Bug: 380208494
Bug: 391609332
Test: atest, Manual with tangor
Flag: com.android.window.flags.enable_desktop_windowing_scvh_cache_bug_fix
Change-Id: I5a4f1aba6318ea2d5343579125b6d84b5fde380f

0 files changed, 0 insertions, 0 deletions