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
