An accessibility service runs in the background and receives callbacks by the system
when {@link AccessibilityEvent}s are fired. Such events denote some state transition
in the user interface, for example, the focus has changed, a button has been clicked,
etc. Such a service can optionally request the capability for querying the content
of the active window. Development of an accessibility service requires extending this
class and implementing its abstract methods.
Developer Guides
For more information about creating AccessibilityServices, read the
Accessibility
developer guide.
Lifecycle
The lifecycle of an accessibility service is managed exclusively by the system and
follows the established service life cycle. Additionally, starting or stopping an
accessibility service is triggered exclusively by an explicit user action through
enabling or disabling it in the device settings. After the system binds to a service it
calls {@link AccessibilityService#onServiceConnected()}. This method can be
overriden by clients that want to perform post binding setup.
Declaration
An accessibility is declared as any other service in an AndroidManifest.xml but it
must also specify that it handles the "android.accessibilityservice.AccessibilityService"
{@link android.content.Intent}. Failure to declare this intent will cause the system to
ignore the accessibility service. Additionally an accessibility service must request the
{@link android.Manifest.permission#BIND_ACCESSIBILITY_SERVICE} permission to ensure
that only the system
can bind to it. Failure to declare this intent will cause the system to ignore the
accessibility service. Following is an example declaration:
<service android:name=".MyAccessibilityService"
android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
. . .
</service>
Configuration
An accessibility service can be configured to receive specific types of accessibility events,
listen only to specific packages, get events from each type only once in a given time frame,
retrieve window content, specify a settings activity, etc.
There are two approaches for configuring an accessibility service:
-
Providing a {@link #SERVICE_META_DATA meta-data} entry in the manifest when declaring
the service. A service declaration with a meta-data tag is presented below:
<service android:name=".MyAccessibilityService">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
<meta-data android:name="android.accessibilityservice" android:resource="@xml/accessibilityservice" />
</service>
Note: This approach enables setting all properties.
For more details refer to {@link #SERVICE_META_DATA} and
<{@link android.R.styleable#AccessibilityService accessibility-service}>.
-
Calling {@link AccessibilityService#setServiceInfo(AccessibilityServiceInfo)}. Note
that this method can be called any time to dynamically change the service configuration.
Note: This approach enables setting only dynamically configurable properties:
{@link AccessibilityServiceInfo#eventTypes},
{@link AccessibilityServiceInfo#feedbackType},
{@link AccessibilityServiceInfo#flags},
{@link AccessibilityServiceInfo#notificationTimeout},
{@link AccessibilityServiceInfo#packageNames}
For more details refer to {@link AccessibilityServiceInfo}.
Retrieving window content
A service can specify in its declaration that it can retrieve the active window
content which is represented as a tree of {@link AccessibilityNodeInfo}. Note that
declaring this capability requires that the service declares its configuration via
an XML resource referenced by {@link #SERVICE_META_DATA}.
For security purposes an accessibility service can retrieve only the content of the
currently active window. The currently active window is defined as the window from
which was fired the last event of the following types:
{@link AccessibilityEvent#TYPE_WINDOW_STATE_CHANGED},
{@link AccessibilityEvent#TYPE_VIEW_HOVER_ENTER},
{@link AccessibilityEvent#TYPE_VIEW_HOVER_EXIT},
In other words, the last window that was shown or the last window that the user has touched
during touch exploration.
The entry point for retrieving window content is through calling
{@link AccessibilityEvent#getSource() AccessibilityEvent.getSource()} of the last received
event of the above types or a previous event from the same window
(see {@link AccessibilityEvent#getWindowId() AccessibilityEvent.getWindowId()}). Invoking
this method will return an {@link AccessibilityNodeInfo} that can be used to traverse the
window content which represented as a tree of such objects.
Note An accessibility service may have requested to be notified for
a subset of the event types, thus be unaware that the active window has changed. Therefore
accessibility service that would like to retrieve window content should:
-
Register for all event types with no notification timeout and keep track for the active
window by calling {@link AccessibilityEvent#getWindowId()} of the last received event and
compare this with the {@link AccessibilityNodeInfo#getWindowId()} before calling retrieval
methods on the latter.
-
Prepare that a retrieval method on {@link AccessibilityNodeInfo} may fail since the
active window has changed and the service did not get the accessibility event yet. Note
that it is possible to have a retrieval method failing even adopting the strategy
specified in the previous bullet because the accessibility event dispatch is asynchronous
and crosses process boundaries.
Notification strategy
For each feedback type only one accessibility service is notified. Services are notified
in the order of registration. Hence, if two services are registered for the same
feedback type in the same package the first one wins. It is possible however, to
register a service as the default one for a given feedback type. In such a case this
service is invoked if no other service was interested in the event. In other words, default
services do not compete with other services and are notified last regardless of the
registration order. This enables "generic" accessibility services that work reasonably
well with most applications to coexist with "polished" ones that are targeted for
specific applications.
Note: The event notification timeout is useful to avoid propagating
events to the client too frequently since this is accomplished via an expensive
interprocess call. One can think of the timeout as a criteria to determine when
event generation has settled down.
Event types
- {@link AccessibilityEvent#TYPE_VIEW_CLICKED}
- {@link AccessibilityEvent#TYPE_VIEW_LONG_CLICKED}
- {@link AccessibilityEvent#TYPE_VIEW_FOCUSED}
- {@link AccessibilityEvent#TYPE_VIEW_SELECTED}
- {@link AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED}
- {@link AccessibilityEvent#TYPE_WINDOW_STATE_CHANGED}
- {@link AccessibilityEvent#TYPE_NOTIFICATION_STATE_CHANGED}
- {@link AccessibilityEvent#TYPE_TOUCH_EXPLORATION_GESTURE_START}
- {@link AccessibilityEvent#TYPE_TOUCH_EXPLORATION_GESTURE_END}
- {@link AccessibilityEvent#TYPE_VIEW_HOVER_ENTER}
- {@link AccessibilityEvent#TYPE_VIEW_HOVER_EXIT}
- {@link AccessibilityEvent#TYPE_VIEW_SCROLLED}
- {@link AccessibilityEvent#TYPE_VIEW_TEXT_SELECTION_CHANGED}
- {@link AccessibilityEvent#TYPE_WINDOW_CONTENT_CHANGED}
- {@link AccessibilityEvent#TYPE_ANNOUNCEMENT}
- {@link AccessibilityEvent#TYPE_GESTURE_DETECTION_START}
- {@link AccessibilityEvent#TYPE_GESTURE_DETECTION_END}
- {@link AccessibilityEvent#TYPE_TOUCH_INTERACTION_START}
- {@link AccessibilityEvent#TYPE_TOUCH_INTERACTION_END}
- {@link AccessibilityEvent#TYPE_VIEW_ACCESSIBILITY_FOCUSED}
- {@link AccessibilityEvent#TYPE_WINDOWS_CHANGED}
- {@link AccessibilityEvent#TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED}
Feedback types
- {@link AccessibilityServiceInfo#FEEDBACK_AUDIBLE}
- {@link AccessibilityServiceInfo#FEEDBACK_HAPTIC}
- {@link AccessibilityServiceInfo#FEEDBACK_AUDIBLE}
- {@link AccessibilityServiceInfo#FEEDBACK_VISUAL}
- {@link AccessibilityServiceInfo#FEEDBACK_GENERIC}
- {@link AccessibilityServiceInfo#FEEDBACK_BRAILLE}
| 