All input events coming into inputfilter from
InputDispatcher will now have FLAG_INPUTFILTER_TRUSTED set by default.
It is now up to the inputfilter (a11y) to remove this flag when appropriate.
One such case is where an unknown a11y service is injecting the events.
From auditing the a11y code, the only such place is MotionEventInjector.
Therefore, label all events coming out of MotionEventInjector as
"untrusted" by removing this new flag INPUTFILTER_TRUSTED.
Separately, a11y should be distinguishable from regularly injected input
events. To tell apart the events injected by a11y, add a new flag,
FLAG_INJECTED_FROM_ACCESSIBILITY. This flag requests InputDispatcher to
apply the device id = -2 for the injected events.
Test: atest CtsInputTestCases:android.input.cts.GamepadWithAccessibilityTest
Test: atest MotionEventInjectorTest
Bug: 175069843
Change-Id: I12d4a7bd6fbab8af202f5ae88b6be97ff9e1754c
Whenever an app makes a Text toast, this gets routed through systemUI
starting from R. Two A11yManagerClients are registered with
A11yManagerService for every toast. Since clients aren't removed until
the process is killed, there are a bunch of clients from systemui
hanging around and potentially cause the system to crash.
We add a way here to explicitly unregister a client
Test: build and flash,
atest android.view.accessibility.AccessibilityManagerTest
Bug: 189010828
Change-Id: I3f71bac475b4539c7be5b328adeb0be35a0b5543
ContextImpl checks the incorrect Context usage in S.
If non-ui context access window service, it would throw an
IllegalAccessException.
And the bug happened because the GestureDectectors in
PanningScalingHandler.class don't have the correct context.
So we have to apply using uiContext for the GestureDectectors
and MagnificationGestureHandler.
Bug: 185154435
Test: none
Change-Id: I942192011526d0e4ce68e6121855bd321c499f56
Adds install source checks for accessibility services. An
accessibility category service must be installed from the
given allow list or not from the default installer if no
allow list provided.
Bug: 182959209
Test: atest AccessibilitySecurityPolicyTest
Change-Id: I023c15b9ebd87785e2f7eb1e218bec4ad006e52f
This is the re re..re-merging of ag/12923546 (where most of that original
message is posted below). This includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches. We satisfy
at most one pending request.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
Messages should be added to PrivateHandler and
mPendingFindNodeIdMessages at the same time to avoid a race condition
where we try removing a message from the handler before it's actually
enqueued. This was causing double recycling
We call into AccessibilityCache from the Binder thread, now that the
cache doesn’t call out to the app main thread with a lock(ag/14020225)
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest
atest CtsAccessibilityServiceTestCases CtsAccessibilityTestCases
CtsUiAutomationTestCases
FrameworksServicesTests:com.android.server.accessibility
FrameworksCoreTests:com.android.internal.accessibility
FrameworksCoreTests:android.view.accessibility
Bug: b/184076735
Change-Id: Iaad1b9100655ec86a788ba1c89edd2dd8a7df1f6
Send componentName via extra instead of idenfifier for Accessibility
usage notification intents because the identifier is used to identify
different intents only. The formal way to send data is via extra, thus
the notification can be launched by adb command.
Bug: 176965357
Test: enable a11y service and execute adb command below.
adb shell am broadcast -a PolicyWarningUIController.ACTION_SEND_NOTIFICATION
-p android --receiver-permission android.permission.MANAGE_ACCESSIBILITY
--ei android.intent.extra.USER_ID 0
--ecn android.intent.extra.COMPONENT_NAME xxx/yyy
Change-Id: I898b66efc05f0144981dd16bd92d719c756b4c2d
For targetSdk < S. For S, they can use the new
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE action to dismiss the
notification shade.
Bug: 159334261
Test: Send Intent.ACSD from an a11y service and verify shade is
collapsed when targetSdk < S, and exception thrown when targetSdk
S+.
Change-Id: I0e4be3faef8efa53a0b8a08263e842e0c4b1553e
To switch magnification mode, a user has to click the magnifcation
button UI. However magnification button UI is visible only when
there is an user touch interaction or the magnification shortcut
triggered event.
However some a11y services like switch-access or voice-access
can only interact with magnification UI by performing
accessibility actions. To make magnification button showing and
able to interact with a user, we also trigger updating
magnification button UI when an accessibility action is performed.
Bug: 179442890
Test: atest WindowMagnificationControllerTest;
atest WindowMagnificationTest;atest MagnificationControllerTest;atest WindowMagnificationManagerTest
Change-Id: I8d762096c9cb6a4421d024a7a1af99b3a48a3462
In an effort to reduce unnecessary String operations and Binder calls
from AccessibilityInteractionClient, also add channels to propagate
tracing state to AccessibilityInteractionClient through
AccessibilityManager.
Bug: 157601519
Test: adb shell cmd accessibility start-trace
adb shell cmd accessibility stop-trace
Change-Id: Idfe220bc64a9c83679201b9a9a36b1c492f9d6cc
Display magnifier could be magipulated by public API. This request
should be treated as an user interaction. We should also update the
magnification button in such circumstance.
Besides, we also disable display magnification that is requested
by AccessibilityService when window magnification is enabled.
In the test part, we also verify the shorct trigged in full-screen
mode.
Bug: 179446412
Test: atest MagnificationControllerTest
manually Test: Use voice access to controll display magnifier
and chek if switch button is shown.
Change-Id: I729ea6fbf921ba6bd735c62198a2b8caee6ec4d7
Change icon to a11y asset and change string based on
String doc
Bug: 174336318
Test: 1. adb shell settings put secure \
accessibility_show_window_magnification_prompt 1
2. use full-screen magnification to see if it works well
atest WindowMagnificationPromptControllerTest
Change-Id: I110ca30b95e268bcad5e9109d7715e854118f0db
Uses the atom MagnificationModeWithImeOnReported in westworld to log
the activated mode when the IME window is shown on the screen.
Adding a new callback API in the MagnificationCallback to monitor the
IME window visibility changes. The A11y framework registers the
callback when the magnification is enabled. It logs the related
data when it receives the IME window visibility changes through
this callback and the magnification is in the activation.
Bug: 154021596
Test: a11y CTS & unit tests
Test: make statsd_testdrive && ./out/host/linux-x86/bin/statsd_testdrive 346
Merged-In: I49b02e00d5a1131b388eeb923440f59a2b4f81a6
Change-Id: I49b02e00d5a1131b388eeb923440f59a2b4f81a6
(cherry picked from commit 1aa113d8dd)
* changes:
Updates magnification button after magnification mode transition is done
Also regarded as magnification activated when it is forced to show magnification bounds
Prompts a notification for the non-accessibility category service after
24 hours enabled to alert users the service has powerful permissions to
view and control the device. And the notification won't be resend to
the same service by saving the dismiss record to Settings.
Bug: 176965357
Test: atest AccessibilitySecurityPolicyTest
atest PolicyWarningUIControllerTest
and manually test
Change-Id: Id5daf7b14dc88cf3f71a53f46fa9a8f1dee91822
Magnification button may be incorrect after magnification mode
transition is done. So just update magnification button with the target
mode after magnification mode transition is done.
The new UI behavior would keep magnification button showing when
the magnification mode transition is happened.
Bug: 181000039
Test: atest MagnificationControllerTest
Change-Id: Icbe34aead2e63c8a65c3238bdc62ebb30974ac6a
When fullscreen magnification is showing initially, it would force to
show magnification bounds but not not be magnifying first.
Then a user has to perform one tap to make the magnifier scaling.
For this case, we also think that it is magnification activated when the
magnification bounds are showing but not magnifying.
Bug: 181597348
Test: atest MagnificationControllerTest;atest FullScreenMagnificationControllerTest
Change-Id: I90b34cc25aca636d4ac84f6627d1a674faecbb1c
Uses the atom MagnificationUsageReported in westworld to log the
activated mode and its duration of the magnification.
The timing of logging the MagnificationUsageReported is
when the magnification feature is deactivated.
Bug: 154021596
Test: a11y CTS & unit tests
Test: make statsd_testdrive && ./out/host/linux-x86/bin/statsd_testdrive 345
Merged-In: I708e9731da23658774e462968a6b9df648b0ed19
Change-Id: I708e9731da23658774e462968a6b9df648b0ed19
(cherry picked from commit e19cdef475)
This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
Messages should be added to PrivateHandler and
mPendingFindNodeIdMessages at the same time to avoid a race condition
where we try removing a message from the handler before it's actually
enqueued. This was causing double recycling
UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal).
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing
Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505, b/181701570
Change-Id: I66902f995f33f0236003faa439925ec72fcf6952
This reverts commit f94c85b130.
Reason for revert: Causing app crashes and runtime restarts in tests. See b/181701570 for details.
Change-Id: I2b5f7b80f07f5d8f564acdf20fcdb1e9b5b9da19
This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal
once b/180957109 is fixed).
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing
Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505
Change-Id: I346a3f40c84c6697b8a1e1d84a636eada655b984
WindowMagnificationGestureHandler has higher priority to address
motion events. When the user put two fingers down on the screen,
magnification gesture detector will intercept all motion events.
It ends up the user couldn't perform any multi-finger gestures.
To fix it, we make magnification gesture detection more accurate:
1. swiping gesture sucesses only with one finger.
2. Regarding two-finger gesture, only swipe or stay on the screen
over a duration will be recognized.
Bug: 163016948
Test: manually test: enable Talback and perform 3-finger swipe gesture
atest com.android.server.accessibility.magnification
Change-Id: I310cf6e3fb2cb2b5b6fbc6a0ba9f0aa1d219b4df
(cherry picked from commit cb49d47bc6)
Merged-In: I310cf6e3fb2cb2b5b6fbc6a0ba9f0aa1d219b4df
This change fixes the issue where AccessibilityService was not able to
dispatch a gesture if a device doesn't have a touchscreen hardware
feature, resulting the behavior gap between CTS and framework.
With this CL, AccessibilityService can dispatch a gesture if the device
declares touchscreen or faketouch hardware features.
Bug: 177021722
Test: AccessibilityManagerServiceTest AccessibilityServiceConnectionTest
Test: CtsAccessibilityServiceTestCases on crosshatch and kindred
Change-Id: I8a1e4884d1283705d409ed38e35047ec2dcd89f0
Since WindowContext won't add WindowToken from the client side,
addWindowTokenWithOption is no more needed. Also remove the logic
to invoke removeWindowToken from the client side.
Bug: 159767464
Bug: 153369119
Test: atest WindowManagerServiceTests WindowManagerPermissionTests
Change-Id: Ib0c948dca223cf8d056865ce3a0d4adaef07d247
Cnfig flag, config_magnification_area, determines if the device
supports magnification area or not.
If OEM doesn't support magnification area, we should adjust the
magnification capability setting and window magnification prompt
setting.
Bug: 177371954
Test: atest SettingsBackupTest
Change-Id: I67947285eb6a73b8e0e21d1db866c426a0ea49d7
(cherry picked from commit f9d7150a5c)
Merged-In: I67947285eb6a73b8e0e21d1db866c426a0ea49d7
* changes:
Notifies updating magnification switch visibility when the magnification shortcut is triggered
Notifies showing magnification switch when the touch interaction starts or ends
Not need to show magnification switch UI when magnification scale is changed
When an A11y service is enabled, it would be added into the list
of the crashed services after doing force close. Then users can't
enable this service until users disable this service again based
on our crashed mechanism now.
The A11y service would be removed from the list of enabled
services after doing force close. We need to remove this service
from the list of the crashed service at the same time to make sure
users can enable this service next time immediately.
Bug: 174616279
Test: a11y CTS & unit tests
Test: manual testing by the steps in the bug
Change-Id: Ie09a11dd2eb2ed7237b580e69c46751ef404b96a
