If a dataset needs to be authenticated the fill service
may not have the values but needs to tell the system for
which fields to show the fill UI. We now allow passing
a null value to mean the view is a part of the dataset
semantically but its value should remain unchanged.
If a dataset has no values, i.e. the related autofill ids
are mapped to null, we cannot properly filter. In this case
we always match such items regardless what the user typed.
While at this improved accessibility support for filtering
to announce when the number of items being filtered changes.
Also while at this allowed a dataset authentication to return
a response which replaces the current response and refreshes
the UI. Matching datasets with null values to any text plus
allowing a response to be returned from a dataset auth enables
the use case where there is always "Import" item at the
end of the list which when clicked can show arbitrarily more
data entries associated to other apps.
Another change is that we now provide the client state
bundle on both request and dataset auth.
Finally, this change gets rid of dataset waiting auth and
response waiting auth concepts since the reference to the
response and the dataset is piped with the auth request.
Fixed a bug where the width of the autofill UI was not
properly measured by going over all items in the adapter.
Now we measure enough height to fit the first three and the
width id the width of the widest item in the adapter.
Test: Added LoginActivityTest#testDatasetAuthTwoFieldsReplaceResponse
Added LoginActivityTest#testDatasetAuthTwoFieldsNoValues
Added LiginActivityTest#filterTextNullValuesAlwaysMatched
All autofill CTS tests pass
bug:37724701
bug:37424539
Change-Id: Ic19e5d7cbdbb7d110c9e7da0ad60b540cbf1aecf
This javadoc was confusing the TalkBack team, so I've
clarified that these events can come from either a
notification or a toast. I also removed a note that I
found confusing and, as far as I could tell, was not
correct anyway.
Bug: 34851364
Test: Docs changes only. Relying on TreeHugger.
Change-Id: Ie5c6efd6e32ce1e33f8cc45c795cda7d7b2e6583
we have a link to the client which is enough to find the views.
Also there was some cases where the windowToken was not updated
properly. This is moot now.
Also: Read a array of views from the client to speed up the
client<->AutofillManager communication.
Fixes: 38070352
Test: CtsAutoFillServiceTestCases
1 Started autofill, saw fill UI
2 Home button
3 Kill activity in background
4 Recents -> back to activity
5 Saw fill UI restored
Change-Id: I7c2c9411204fa5d65867efae9b7296399121c3a2
Only IDs beyond LAST_APP_ACCESSIBILITY_ID can be reliably used for
autofilling. Other ids might change occasionally.
All Views attached to activities get usable IDs. Hence if a
ContextWrapper wraps an activity forward the goodness.
Also make sure that we don't accidentially autofill an unsafe view.
Test: Before the messaging handed out unusable Ids because it uses a
Contextwrapper. Now it hands out good ideas (accoring to dumpsys)
CtsAutoFillServiceTestCases
Bug: 38070352
Change-Id: Ibc72c84d77197019939abd231e8960988af7a592
Not so drastic as we were releasing the Server side resources
anyway but the close guard is producing a strict mode warning.
Bug: 35955183
Test: cts-tradefed run cts -m CtsViewTestCases -t android.view.cts.SurfaceViewTest#surfaceInvalidatedWhileDetaching
Change-Id: Id250fff8d001d5d82458af1a732c0e123f925dad
If parents of a view got suppressed in the autofill structure the left
and top value are not relative to their direct parents anymore. They
need to be relative to the next non-suppressed parent.
This does not change any values for assist structures.
Fixes: 36060132, 37444334
Test: CtsAutoFillServiceTestCases + new ones that check for the left and
top parameters of view nodes.
Change-Id: I914ad028c7ed2f93ce44210cbe1a2a710673cbbb
Using the same method as getBoundsInScreen.
Bug: 35095925
Test: Manually verified location with test app, ran a11y cts
Change-Id: I1eee2a4eb23912698be61c9030d92bbade1d743a
- The aim is to be defensive and prefer to reject a selection if
it is likely to be wrong.
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Bug: 38019270
Change-Id: I35ebc84fb102373949366296434a31d899edfef3
Caused by bad data from an app where a node was its own ancestor.
When the node changed, the copy in the cache was recycled while
flushing the descendants. Now recovering more gracefully.
Bug: 37674439
Test: Adding a unit test for this case, ran a11y cts and unit tests,
verified that the app reporting bad data no longer crashes TalkBack.
Change-Id: I10bc9df2b4821529334a19aa27719c1510187690
For AssistStructure, and AutofillValue, create a copy of the text in
setText and forText methods if it is a Spanned.
Fixes: 36838999
Test: cts-tradefed run cts -m CtsAutoFillServiceTestCases
Test: cts-tradefed run cts -m CtsAssistTestCases
Test: cts-tradefed run cts --test android.widget.cts.TextViewTest -m \
CtsWidgetTestCases
Change-Id: I52e780fa9baa17c375d3945dc714171f41fd7db5
- Sending scroll events for accessibility.
- Sending text update events when state changes.
- Blocking text updates during fling to reduce number of events.
- Making widget focusable by default, which keeps focus from
moving to the rest of the UI when the text box becomes invisible.
- Managing visibility of the text box alongside IME state, so the
IME won't decide to display the password keyboard during a fling.
Bug: 21494380
Bug: 37016501
Test: Ran NumberPicker CTS
Change-Id: I459d37d4a54c91e1cb5c7ec68fe0f012b25fb740
While searching for next user-specified focus, skip over any
views which are not visible. This will continue searching down
the chain until it either finds a visible view or until the
chain ends (at which point the normal findNextFocus search is
used).
This was causing problems in apps like the wallpaper selector
where focus would get stuck because calling requestFocus on an
invisible view is a no-op.
Bug: 37789849
Test: Added CTS. Checked that focus no-longer gets stuck in
wallpaper app.
Change-Id: I1a52143bd6c63364418fe6250e6c3f83e2e1c726
- Moves logic to detect devices capable of supporting the
accessibility button into AccessibilityManager from
SettingsLib to avoid issues with resource shifting in the
SUW binary
Bug: 37650567
Test: Existing Robolectric / Manual
Merged-In: Ibb2aaa3c2f79570df768cfa796fa890988ef82cc
Change-Id: I83bbecdf7836ae0de32ce7d39155ac0c111a8f15
