Check relayoutCalled in updateSourceFrame

In some cases a WindowState could try to update its
InsetsSourceProviders sourceFrame before relayout was called. Even
though it does check that we don't given insets pending, this could pass
when the window is just being added. In this case each source provider
would update the frame on the server side only, and try to apply the
frame provider logic to potentially inset the result. However, we
wouldn't have any given content insets to apply to this frame before the
window is laid out, so the provider would be using the whole app frame
as its sourceFrame.

This would only remain on the server side initially, but will be sent to
the InsetsSource on the client side whenever the provider would become
serverVisible, which can happen before we get another updateSourceFrame
call to trigger applying the content insets after layout, when they
wouldn't be empty anymore.

In the IME source provider case, this could lead to the app receiving
full height IME insets, which will trigger a flicker as the app will
re-measure its contents with zero height. Additionally, this leads to
the app losing focus on the actual view, and focusing the DecorView
instead. If the window focus switches to a different app in this case,
while the IME is shown, and then back to the original app, we would hide
the IME as the focused view (DecorView) is not an EditText.

This fixes the case described above by ensuring the WindowState source
frame update also considers whether relayout was called before setting
the new frame.

Flag: EXEMPT bugfix
Test: atest WindowStateTests#testUpdateSourceFrameBeforeRelayout
  InsetsStateControllerTest#testImeForDispatch
  DisplayPolicyTests#testImeInsetsGivenContentFrame
  DisplayPolicyLayoutTests#addingWindow_withInsetsTypes
  DisplayPolicyLayoutTests#testFixedRotationInsetsSourceFrame
  DisplayPolicyLayoutTests#testSimulateLayoutDisplay
Bug: 359387875
Change-Id: I0c94f7bf7604d55b23e568cfa1a16433537395b7

0 files changed, 0 insertions, 0 deletions