An service can option to finish the session once all views that it
declared as important. Views that are important are all autofillable
views of any partition and the saveable fields of the last partition.
Test: CtsAutoFillServiceTestCases
Fixes: 35708237
Change-Id: I0ccade8ebb427e5d8928697ef0007c75d3f83df0
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
In my previous CL [1] a new flag IME_FLAG_NO_PERSONALIZED_LEARNING
was added for EditorInfo.imeOptions. What was missed in the
previous CL is that new flag definition for layout XML and as a
result currently IME_FLAG_NO_PERSONALIZED_LEARNING is the only
IME option flag that cannot be specified in layout XML.
For instance, EditorInfo.IME_FLAG_FORCE_ASCII can be specified as
follows.
<EditText
android:id="@+id/edittext_force_ascii"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:imeOptions="actionSend|flagForceAscii" />
With this CL, application developers can specify
IME_FLAG_NO_PERSONALIZED_LEARNING as follows.
<EditText
android:id="@+id/edittext_no_personalized_learning"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:imeOptions="actionSend|flagNoPersonalizedLearning" />
[1]: Ibf5ac3d2b8f39542baf2635c0cadbe242b059f81
5959af13d0
Bug: 28157942
Fixes: 37305520
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: Ifca0b13bf336cdc609af820aadcdb1b45ca1d5ba
- The session might be gone by the time the handler is called, hence check
the sessionID
- Access getClientLocked() and mSession only under mLock.
Test: cts-tradefed run cts-dev AutoFillServiceTestsCases
Change-Id: I445a24557589afadb1f5372b63ef9db88021b609
See accompanying frameworks/native commit
"SurfaceFlinger: Add parent-less relative layering" for a full explanation.
Test: Manual of bug repro steps. Plus tests for new SurfaceControl functionality included in frameworks/native.
Bug: 36693738
Change-Id: Ic54598117c1f44a206d33f03d0cc463fbef43fcc
Previously views were ordered strictly by their tops. This
lead to many cases of tab-focus moving "backwards". For example
a horizontal row of views with different heights would not
always move start-to-end.
Bug: 34854951
Bug: 33848452
Test: Run against UX-provided localized focus-orders to make sure
it improves behavior. Added a sanity-check CTS test for
well-behaved (simple) layouts.
Change-Id: I5b01a301e0bbcbcad472ffdb26ebf4fbb6380756
* changes:
Fix broken CTS tests.
Draw a default focus highlight if needed.
Add a public API defaultFocusHighlightEnabled.
Detect unhandled keyboard focused state.
A more targeted version of "ViewRootImpl: Fix child lifetime".
In this version we avoid hijacking the window visibility callback
and introduce a new path.
Our contract has been that at any time after returning from
onStop, the WindowManager may destroy the clients Surface. We
see in setWindowStopped, we set the stopped state on the hardware
renderer in order to prevent further use of the Surface. However
there is nothing synchronously dispatching this change to child views
and so SurfaceView is not necessarily informed to release it's Surface
in time. Typically SurfaceView will be informed through the
onWindowVisibilityChanged callback. The signal producing this
is emitted from SystemServer prior to onStop but has to pass
through the clients handler thread. It seems this has always been
broken, and we have always had intermittent reports of EGL_BAD_ALLOC
scenarios. I speculate that elevation of WindowManager scheduling during
app close scenarios is perhaps making this more severe, as it seems to
ensure the WindowManger will win the race to destroy the Surface before
the client handler thread process onWindowVisibilityChanged (unless
the FIFO timeout is surpassed).
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: I9233ba8151c7f577b1d1044afc0c2ac3a65be4b4
The default focus highlight should be necessary when the view is
attached to window.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases -t
android.view.cts.ViewTest
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsWidgetTestCases -t
android.widget.cts.MediaControllerTest
Bug: 37082416
Change-Id: I5d6b0c00b5ba03c8f62e4f71be9336823a73134b
This commit draws a default highlight for a focused
View if it's detected to have no state_focused defined
and its useDefaultFocusHighlight attribute is true.
When we detect a default highlight is needed, we show it
on top of the view to. Once we detect that it's no longer
needed, we remove it.
Test: Check that views without a focused_state in its
state spec have a default highlight when they get focused.
Bug: 35096940
Change-Id: Ifbe4bb9e1297d98845314e24d8b758f14e5987a9
This commit adds a public API to turn on/off default
focus highlights. When a focused View is detected to
have no state_focused defined, we can use this API to
decide wether we should show a default highlight for it.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases
-t android.view.cts.View_DefaultFocusHighlightTest
Bug: 35096940
Change-Id: I76b45d6bf5761641a0ed7f4d0b04cb325ed72b52
We now have a software feature for autofill which can be used
by partners to disable it on low-end devices or form factors
for which autofill doesn't make sense.
bug:35956220
Test: manual (requires a custom build)
Change-Id: I6c06462ed9ca3ae93331700dce38a8c08dfd0722
This reverts commit ba29dbc3b3.
The original commit causes apps such as phone and clock to not wake the
device.
Fixes: 37197491
Change-Id: I1b45cafbcbf12991d8e1e716e4d1751cd077c556
Also:
- Give the session an integer ID as the activityToken is not stable over
restarts of the activity
- Verify that session is only accessed by one UID
- stabilize AccessibilityViewIds over activity lifecycle at least for
the IDs we can do that. This required to split the ID namespace in
"per-app" and "per-activity" views. Only the later ones can be
restored.
- Do not end session when app is killed (as it can be restarted)
Bug: 35484143
Fixes: 36392498
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases --test=android.autofillservice.cts.SessionLifecycleTest
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
Change-Id: I229acc1b3ce35fb57262da7d7466b5d4328b49d4
AdapterViews (and other dynamic layouts) inflate views which
can lead to multiple views with the same id. The original
user-specified focus logic assumed that id's were unique causing
focus loops. This now uses the full "insideOut" id-search
instead of an id->view map.
Bug: 32647147
Test: FocusFinderTest still passes. Added #testDuplicateId
specifically for this scenario
Change-Id: Iaed98438f5ad70c866dd72e699453eab0ac0cf58
As far as I can tell this has always been broken. We've always had
intermittent reports of buffer-queue-abandoned as well (a recent bug
came with some reports from N). During onStop SurfaceView relies on
onWindowVisibilityChanged, to trigger a visibility change. At this
point SurfaceView will emit the SurfaceDestroyed callback in order to
stop the client from further use of the Surface. The contract we've
been using with ViewRootImpl is at any point following
Activity.performStop returning the WindowManager was free to destroy
the Surfaces. This is why in setWindowsStopped we destroy the hardware
resources for the ViewRoot. However we aren't dispatching anything to
the SurfaceView. The WindowManager will send an app visibility
notification, but that would go through the handler. This means by the
time we return from Stop, there is no guarantee that the
onWindowVisibilityChanged callbacks have been invoked at all. It
seemed most sensible to dispatch the visibility callbacks directly. We
also ensure that getHostVisibility will return false after this point,
so that performTraversals will not reverse our visibility request if
it occurs again prior to the window visibility notification from the
WindowManager. We also guard against emitting a second window
visibility changed callback in the traversals. I don't know at this
point what value the window visibility notification provides but I
don't feel excited about removing it in this CL at this point in
the development cycle.
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: Id1673561b2299d477b2761b3ac6afa14eabbf7fb
Fix a bug where a malformed Parceled representation
of an AccessibilityNodeInfo could be used to mess with
Bundles as they get reparceled.
Bug: 36491278
Test: Verified that POC no longer works, a11y cts still passes.
Change-Id: I10f24747e3ab87d77cd1deba56db4526e3aa5441
(cherry picked from commit 687bb44b43)
This partially reverts CL I0f6b130a7df57557e40b52a7b7ac00be965a17c3.
Fixes: 34133139
Test: Confirm that unit test passed.
adb install out/target/product/.../data/app/FrameworksCoreTests/FrameworksCoreTests.apk
adb shell am instrument -w \
-e class android.view.inputmethod.InputMethodInfoTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I2b94263b2a0bf330bf9973567fea2d35176754d7
1) Switch AccessibilityButtonChooserActivity to non-exported
2) Update AccessibilityButtonChooserActivity's intent action to
be CTS-compliant
3) Switches to correct permission to validate a click of the
accessibility button originated from the status bar service
Bug: 36866328
Bug: 36976440
Test: Manual / Created app to validate launch protection
Change-Id: Ifcd5e8dbbe683dc99bb900a5870a9ba374fbd5d4
It happened when views provided an Accessibility node that had children.
Bug: 37078783
Fixes: 37009008
Test: LoginActivityTest#testAutoFillWhenViewHasChildAccessibilityNodes
Change-Id: Ie694094afe9129b933096a385eb867baf4550e7f
