If the local state and mLastDispatchedState are the same, the logic in
onStateChanged will skip updating the requested state. This could be an
issue, for example, a new focused window requested to hide status bar,
but status bar has already been hidden by the previous focused window,
so the new focused window will never send the requested state to server.
This can easily happen when an immersive activity is re-created due to
the configuration change.
This CL updates the requested state if any visibility within it is not
the same as the requested visibility of the source consumer, while
receiving controls.
Fix: 160854328
Test: atest InsetsControllerTest
Test: Swipe to show transient bars after rotating an immersive activity
Change-Id: I5d9acb1b59252fa80e66070db86b2555764588da
In a normal case, the app will get either a visibility changed to
false or stopped from system server to indicate that the content
should be cleaned up. In those cases, it will request a relayout
to WM, which will notify VRI that the surface is gone. Since the
VRI surface is removed, the SV and bounds layer will get notified
that they should be destroyed. On the next relayout, the VRI will
get a new surface and notify SV and the bounds layer to create
new surfaces.
The scenario in the bug happens when VRI receives a visibility change to
false, but doesn't process the information fast enough. By the time it
calls relayout, WMS is in the state where the client is visible again. This
time the relayout will return a valid surface so the SV and bounds layer
will not get cleaned up. The reason this causes issues is VRI now has a
new main surface. The bounds layer is parented to the old layer that's been
deleted so it's not parented to anything. The SurfaceView is a child of
the bounds layer so it also renders offscreen.
The reparent needs to be done on the client side since WMS won't
reparent the children to the new surface if it thinks the app is
closing. WMS gets the signal that the app is stopping, but on the client
side, it doesn't get stopped since it's restarted quick enough. WMS
doesn't want to keep around old children since they will leak when the
client creates new children.
This change will reparent the bounds layer to the new VRI surface. It's
possible WMS will take care of this in certain cases where the app
isn't stopped. But for those cases, the reparent will not have
any effect since the bounds layer will be correctly parented.
Fixes: 159545768
Test: Can no longer repro black SV in maps
Test: Test app with SV and delay in onPause no longer has the same issue
Change-Id: I616652e1cc4380ebbcb386586d8d5889fcc19497
Fixes a flicker that occurs during transitions between windows.
This happens for two reasons:
1.) Control is immediately transferred to the new window, and the
previous window didn't get a chance to play the animation.
This is addressed by adding logic to keep control on the
exiting window for the duration of the transition - similar to
what we do with the target for z-ordering purposes.
2.) Upon the input connection being severed, the InputMethodService
immediately hides its window, preventing any animations whenever
the input connection changes
This is addressed by moving hiding of the surface into the
controlling windows - where upon receiving control, we now
trigger removal of the IME surface if we don't show it.
Additionally:
- Now ensures that any requests from the ImeInsetsSourceConsumer
ensure that they come from the window that is currently served
by IMM.
- Removes the transparancy clause from isImeTargetFromDisplayContentAndImeSame
to match the updated IME target computation in DisplayContent in [1].
[1]: Iedd5f7407926167f4891ce9b7e9a79e22751e668
Fixes: 153145997
Fixes: 150902448
Test: atest WindowInsetsAnimationControllerTests
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: Open app with IME, press HOME button, verify IME smoothly animates away
Test: Open Messages, open a thread, open IME. Click search icon, verify IME opens in the search activity
Change-Id: I4910c2a06cc67b0470477b245fc1de54b75f10f9
When config_remoteInsetsControllerControlsSystemBars is true,
DisplaySystemBarsController provides its own policy of how system
bars are displayed for specific packages. Currently limited to
only auto versions of Android.
Bug: 149585273
Test: Manual, atest BarControlPolicyTest, atest InsetsPolicyTest,
atest DisplaySystemBarsControllerTest
Change-Id: Ie6b1cc3e2760cbc9e48d62dfbd8bc3e23ffca20c
Merged-In: Ie6b1cc3e2760cbc9e48d62dfbd8bc3e23ffca20c
When config_remoteInsetsControllerControlsSystemBars is true,
DisplaySystemBarsController provides its own policy of how system
bars are displayed for specific packages. Currently limited to
only auto versions of Android.
Bug: 149585273
Test: Manual, atest BarControlPolicyTest, atest InsetsPolicyTest,
atest DisplaySystemBarsControllerTest
Change-Id: Ie6b1cc3e2760cbc9e48d62dfbd8bc3e23ffca20c
If a requestLayout happens on a child view after the measure
pass, before the layout pass then the child view will not layout.
This can happen if a view calls requestLayout during measure
or during SurfaceView surface destroyed callback.
This fix addresses the second scenario by moving the callback
to after the layout pass.
Bug: 159183008
Test: Repro steps in bug
Test: go/wm-smoke
Change-Id: Ie2794a3751c99cabf6e07445c91159e35eeb1729
Making the A11y event sending to A11y services when a view becomes
invisible if the ancestors of this view are all visible, and this view
becomes invisible from visible.
Bug: 130273130
Test: a11y CTS & unit tests
Change-Id: I836d3e34c7a9cba31843d34922b7ba02a8a062f0
This broke several apps because it means certain NON_FOCUSABLE windows
are now layered wrong w.r.t the IME, and also no longer get IME insets.
Originally, this was introduced because the IME target was used to
compute which window gets control, but this is now computed based on
the window actually connecting to the IME as reported per IMMS.
Reverts I941571c97145d77b0a59d030cf2a8c8318f3b59f.
Bug: 143898978
Bug: 140641950
Bug: 145812508
Bug: 141738570
Bug: 144619551
Fixes: 159438771
Test: atest WindowStateTests
atest FocusHandlingTest
atest WindowManager_LayoutParamsTest
Also manually using steps:
1. Launch gmail compose activity
2. start typing in receipient field
3. verify that even thoug the suggestions popup
window w/ FLAG_NOT_FOCUSABLE becomes the
IME target, control and insets still work.
Change-Id: If451276b1a8c485ec88965d8d30ec8fd3836620f
We utilize mTmpTransaction without locking from the main thread. The
callback info inside the transaction stores an sp to the SurfaceControl.
If we apply the Transaction from two threads independently we may
implicitly call reset() on the same sp instance twice in an overlapping
fashion. While the reference count is itself atomic, that wont stop us
from decrementing it twice here, when we only had one reference.
This leads to an early free and a crash later.
Bug: 159333209
Test: Existing tests pass
Change-Id: I898bef0b6b8c1cf34891410bbadf63fe2f840697
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
