WindowState: Avoid destroying surface during relayout
It's hard to find any reason for why this line of code needs
to exist in the present system. Prior to the removal of detachChildren
we needed to ensure we destroyed the surface when cancelling an
animation (as the old surface would be detached and no longer usable),
however in the current state I struggle to find any reason. It seems
the situation is creating some confusion with the BLASTBufferQueue
callback handling when the ViewRoot swaps out the SurfaceControl of
an existing BLASTBufferQueue. We need to understand this situation
more but the easiest way to stop bugs will be to prevent it from
happening in the first place.
Bug: 180194022
Test: Existing tests pass, manual testing of cancelling animations while
slowing down
Change-Id: Id450d49951bd276d3c8a8c16705568e9c328a698
Change-Id: I1e8f56ae6e7280325c0622dd13e5f1d77c4aabde
1 file changed