We have this in guide but not in javadoc, but it would make
sense to have it in javadoc as well.
Test: presubmit
Change-Id: I585248cc40c44bfa90828f04e4b5bd34694c36fd
Bug: 139376317
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
* For the case where the pinned inline suggestion triggers an
pending intent through the auth flow, and it returns a dataset
to be autofilled, previously we would replace the existing
dataset with the returned dataset. However, this is causing
several potential issues:
1. if the returned dataset doesn't contain inline presentation
the the pinned icon will not show again
2. if the returned dataset contains inline presentation but not
the pending intent, then the pinned icon will show up again
but tapping on it will not launch the pending intent
3. if the returned dataset contains the inline presentaion and
the pending intent, then when we "autofill" it, it'll fire
the pending intent directly as opposed to filling in the
value
* We fix the issue by not replacing the old dataset if the dataset
is a pinned inline suggestion.
* One caveat of the approach is that: a dataset can potentially
have multiple fields, and it's possible that some of the fields'
has inline presentation and some don't. It's also possible that
some of the fields' inline presentation is pinned and some isn't.
So the concept of whether a Dataset is pinned or not is
ill-defined. Here we say a dataset is pinned if any of the field
has a pinned inline presentation in the dataset. It's not ideal
but hopefully it is sufficient for most of the cases.
* An alternative approach is to have the autofill provider telling
whether they want to replace the old dataset or not, through
a new field in the returned Bundle. But that requres an API change
so is infeasible at this time.
Test: atest android.autofillservice.cts.inline
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.LoginActivityTest
Test: atest android.autofillservice.cts.AuthenticationTest
Bug: 159367101
Change-Id: I6d162aeb88a4655989c1aa315df8304c0980ac60
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
* In case where there are multiple input fields in a single WebView,
switching focuses between input fields doesn't trigger an onFinishInput
from the previous field. But it always triggers an onStartInput in
the new field. So it's safer to clear the suggestions onStartInput
Test: atest android.autofillservice.cts.inline
Test: atest CtsInputMethodTestCases
Bug: 159479887
Bug: 157515522
Change-Id: Ie380db855fbc93600635790ef5adc1031d6f0787
SurfaceView doesn't respect the visibility of its ancestor so we need to
update it accordingly inside InlineContentView.
Test: manually
Bug: 158714351
Change-Id: If482747d6ae5d7628b46de837c11b6232406120c
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
The reason is passed to app exit info so a given app can get more
information about why their app was killed in the event of permission
revoke.
Test: atest RevokePermissionTest ActivityManagerAppExitInfoTest#testPermissionChangeWithReason
Fixes: 159659620
Change-Id: Id711667eb2c1579ecb2a1b83a62af3cc7862d5f6
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
