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
Merged-In: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
When an activity is stopped, there could still be some pending events in
the inputconsumer due to batching. Those events are supposed to be
handled when choreographer's 'CALLBACK_INPUT' occurs, but this will
never happen if the window is stopped.
There are two possible ways these events can occur:
1. The last input event happens before onStop, but at that point,
choreographer will already stop sending callbacks. The solution to this
is to add a call to "consumeImmediately" inside setWindowStopped.
2. Input events come in after window has already been stopped. At that
point, the callback we posted in 1. would already have executed (and
found that there's no events). The solution to this is to immediately
consume all input if mStopped=true. We do this by switching to
"unbuffered" mode for simplicity.
This is reproducible via monkey testing, but it's plausible that such
race condition can occur in real world usage.
Test: adb shell monkey --throttle 40 50000
Bug: 159239700
Change-Id: I74d8f55503ef7df2fd01931afb362d68e5026e86
Having whether something is currently scheduled get modified in the
actual processing logic and away from the scheduling logic makes it
unnecessarily more difficult to reason about.
In this case, we were only checking whether the Choreographer-aligned
runnable was actually scheduled before we'd consume input. When trying
to unbuffer dispatches so that things were no longer
Choreographer-aligned, however, we'd unschedule the that runnable just
before we tried to consume input and hence just before the check . This
meant we never actually consumed the batches until the next one came in
where we would then consume them immediately. Worse, if another one
never came in then we'd never actually consume the batch.
By removing the scheduling logic from the processing logic we avoid this
situation. Now only the schedule, unschedule, and actual runnable logic
touch their own scheduled state, so that we don't have to consider the
two pieces of logic together except in isolated places.
Bug: 158540186
Bug: 159239700
Test: manual, using app that injects unbuffered dispatch requests either
at ACTION_DOWN or first ACTION_MOVE
Change-Id: I7521a5a16ed52afc41261f501128b5498ea0602c
Revert "Verify IMS to get display and WM"
Revert submission 11823238-ims_ui_context
Reason for revert:
Broke the following tests:
android.os.cts.StrictModeTest#testIncorrectContextUse_GetDisplay
android.os.cts.StrictModeTest#testIncorrectContextUse_GetSystemService
android.os.cts.StrictModeTest#testIncorrectContextUse_GetViewConfiguration
But was submitted with a bypass.
Reverted Changes:
I688b46a92:Verify IMS to get display and WM
I172ceb2e1:Enable IMS and its config context to obtain UI com...
Bug: 157027563
Bug: 159795597
Change-Id: Id309faac0ac8f60ee0d92c26767a89f450ddc455
When an inline content view is reparented its surface is
getting offset and not being under the view itelf. This is
because the surface views manage the postion of their
surface and are assuming a location based off the window's
surface position. However after a reparenting the inline
content view's surface position becomes relative to that
of the new parent surface view. For example, two surface
views at position (10, 10) being reparented would reslut
in the surface of the parent being at (10, 10) while the
surface of the child being at (20, 20) while both views
would still be at (10, 10).
To address this we are intecepting when an inline content
view's surface is reparented and get a weak reference to
the view that owns the new parent surface. We then position
the inline content view's surface relative to the view that
owns the new parent surface, i.e. we position the surface
such that its location would not change because of the
fact it is being reparented.
While at this make sure the inline content view is marked
as not important for a11y to ernsure the a11y plugins don't
try to click on the view tree in the app's process but
insted on the views in the remote proccess, i.e. on the
embedded view tree.
bug:153826463
Test: atest android.widget.cts.inline.InlineContentViewTest#testReparenting
Change-Id: I2cff4b88d404a740bc447668e948eabccad084d2
We add new test in stage-aosp-rvc-ts-dev for R2, we need make this API
testable.
Bug: 156408900
Test: atest android.autofillservice.cts.inline.\
InlineAugmentedWebViewActivityTest
Change-Id: I27d1227f858aac83b3de1cb8ef719edf177524dc
Merged-In: I27d1227f858aac83b3de1cb8ef719edf177524dc
Floating IME or fullscreen IME won't cause insets (except the area
overlapped with navigation bar). It doesn't make much sense to let
apps move the IME at these cases.
Fix: 157777145
Test: atest InsetsSourceConsumerTest GlobalActionsImeTest
ImeInsetsControllerTest
Change-Id: Id70f59be7653beedc02d6c8bc3b1bd50a357f4fe
Activity was still referred from ImeInsetsSourceConsumer after
ViewRootImpl's mView was destroyed when ViewRoot's surface is cleared
using die signal.
This CL makes sure we still free-up resources at die signal.
Fix: 157955883
Test: atest NexusLauncherTests
Change-Id: Ia48f7b7a8cf6b867ce75b2b7393a60ba73b0c3d0
During transitions and while the IME is controlled by the app,
the IME may be "visible" as far as the IME framework is concerned,
but not actually perceptible by the user due to offsets or alpha
applied to the leash.
This may lead to out-of-place navbar symbols for the IME, especially
in gesture nav.
To avoid this, the ImeInsetsSourceConsumer now notifies the IMF of
whether it has made the IME unperceptible to the user.
For now, we ignore the cases where the IME is controlled by something
other than the client window - in that case, we just revert to the
previous behavior of it being always considered perceptible.
Fixes: 158079255
Test: manual, launch email compose activity, observe that back button only indicates once IME appears
Test: atest InsetsAnimationControlImplTest
Change-Id: I4dc9d6513d0559156f7da39244f3fc5ebc952ed4
CL[1] introduces new WINDOW_FOCUS_GAIN_REPORT_ONLY flows to notify
InputMethodService only reports IME input target to WM when focusing to
the next window and its input connection remains.
Originally in android Q and prior devices, we don't need such report
mechnism but just skip to start new input connection and ignore
onStartInput / onFinishInput for the above use case.
Since starts from Android R, new IME insets control APIs relying on this
mechanism (see CL[2]) to keep the actual IME input target up-to-date.
As we expected there should be no new input connection and additional
onFinishInput when CL[1] landed.
However, in IMMS, startInputUncheckedLocked will be called
to callback additional onStartInput for InputMethodService, which mostly
is not expected, except when focusing the same window after device
turned screen on, we need to start input and callback onStartInput to
align with the behavior of android Q or the prior platform.
Besides, to have more clear code logic and debugging concept of
ignoring onStartInput and onFinishInput only when focused the same editor
with input connection remains, we remove WINDOW_FOCUS_GAIN_REPORT_ONLY
reason and introduced 2 more start input reasons to distinguish the
different behavior:
- WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR
- WINDOW_FOCUS_GAIN_REPORT_WITHOUT_EDITOR
[1]: I45a9814d812ad906f417c24200fd4219959e2423
[2]: I9e8984b7e5aa989a53ece9e2576393f795b9ef94
Fix: 158624922
Test: atest FocusHandlingTest InputMethodStartInputLifecycleTest
Test: manual as below steps:
1. Use Gboard, Open the emoji keyboard
2. Swipe down to reveal notification shade
3. Swipe up to dismiss notifications
4. Expect the Emoji keyboard is still open without close
Change-Id: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
When IME has zero insets, it doesn't map to any side and doesn't have
can't be animated.
IME can have zero insets in following cases:
1. Floating IME
2. Fullscreen IME (in landscape)
3. IME doesn't overlap with IME target window.
In order to animate a type, it must have insets. We can animate IME
from negative insets to zero and vice-versa. This makes zero insets IME a
special case of ISIDE_BOTTOM.
Deprecate SIDE_FLOATING because it shouldn't logically map to a side.
Fix: 153909316
Test: atest WindowInsetsAnimationImeTests#testZeroInsetsImeAnimates
Change-Id: I6d1d3430888db4632cb2f93e9042f692b35ebaeb
If we don't explicitly go through the doDie process the
WindowManagerGlobal instance will hold the ViewRoot alive
indefinitely. This accidental leak could be very expensive so
we prevent it with a finalizer.
Bug: 157709599
Test: Existing tests pass
Change-Id: I4fdf368eed4b4e43faacd9f62b6d9fddfd9b7ef2
If we pass immediate=false to the doDie without
updating the visibility, we may destroy the hardware renderer
but then try to draw again anyway, and then crash. It seems
theres no reason we can't call immediate=true and
properly shut down immediately.
Bug: 159250432
Test: Existing tests pass
Change-Id: Ibc6be8901be10c0985681d83f4ce16dd1ab54925
- Replace InsetsState ArrayMap with simple array.
- Cache same values in InsetsPolicy.
- Only access Dimmer if dimming
Test: InsetsState test etc.
Bug: 159056748
Change-Id: I3e9e4f473eaa05b2013b7a6d0f37cd9c1fac81dd
Activity cannot be released because the context be holded by multiple
objects.
* Activity holds ContentCaptureManager.
* ContentCaptureManager holds the context and MainContextCaptureSession.
* MainContextCaptureSession holds the context and ContentCaptureManager.
* The system server holds some binder references to MainContentCaptureSession.
If the system service never released the binder references, then the
activity is also never GC'd.
To avoid the issue,
1. Make the session state receiver of MainContextCaptureSession to be
static and uses weak reference to MainContextCaptureSession.
2. The direct service vulture may miss to do unlinkToDeath(), do a checking
while the session destory.
Bug: 143210612
Test: manual check Objects on the meminfo
Test: Activities should be released after a period of time
Test: adb shell dumpsys meminfo com.google.android.dialer
Change-Id: I12037483addb1efe444c74fa189ef6afd15821dd
eEarlyWakeup flag is used as a hint to SurfaceFlinger to adjust its
offsets so it can wakeup earlier and have sufficient time to compose
more complex scenes.
This flag has been replaced with explicit start and stop flags which
ensure the SurfaceFlinger offsets remain consistent during animation.
Bug: 158127834
Test: go/wm-smoke
Test: systrace to verify new tracepoint and offset behavior
Change-Id: Ib9c35c01a6bf02f88ec7cb1778e01909bd2f9055
This call to updateRelativeZ may be triggered from the
RT frame callback which may be triggered after we are detached
from the Window and in that case will be null. If we are detached
we are also going invisible so there is no need
to set a relativeZ.
Bug: 158706756
Test: Existing tests pass
Change-Id: I46aa824807b7b275e6a015c428fe7467a72ca949
A11y service cannot get focus of bubbles because it's not a
System owned display. This patch makes System UI owned display
a trusted display. Moreover, this patch refactors the logic to
identify a trusted display by introducing FLAG_TRUSTED and
removes the trusted display check along with supportsSystemDecorations()
because the check has been included in supportsSystemDecorations().
fixes: 155823002
Bug: 152416787
Test: atest DisplayContentTests
Test: atest WindowFocusTests
Test: atest TaskDisplayAreaTests
Test: atest MultiDisplaySystemDecorationTests
Test: atest DisplayTest
Change-Id: Ie684c6488904e5aa8cae166a455c6d55455e5f55
