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
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
