page.title=Building Accessibility Services parent.title=Accessibility parent.link=index.html @jd:body
An accessibility service is an application that provides user interface enhancements to assist users with disabilities, or who may temporarily be unable to fully interact with a device. For example, users who are driving, taking care of a young child or attending a very loud party might need additional or alternative interface feedback.
Android provides standard accessibility services, including TalkBack, and developers can create and distribute their own services. This document explains the basics of building an accessibility service.
The ability for you to build and deploy accessibility services was introduced with Android 1.6 (API Level 4) and received significant improvements with Android 4.0 (API Level 14). The Android Support Library was also updated with the release of Android 4.0 to provide support for these enhanced accessibility features back to Android 1.6. Developers aiming for widely compatible accessibility services are encouraged to use the Support Library and develop for the more advanced accessibility features introduced in Android 4.0.
Applications that provide accessibility services must include specific declarations in their application manifests in order to be treated as an accessibility service by an Android system. This section explains the required and optional settings for accessibility services.
In order to be treated as an accessibility service, your application must include the {@code service} element (rather than the {@code activity} element) within the {@code application} element in its manifest. In addition, within the {@code service} element, you must also include an accessibility service intent filter, as shown in the following sample:
<application> <service android:name=".MyAccessibilityService" android:label="@string/accessibility_service_label"> <intent-filter> <action android:name="android.accessibilityservice.AccessibilityService" /> </intent-filter> </service> </application>
These declarations are required for all accessibility services deployed on Android 1.6 (API Level 4) or higher.
Accessibility services must also provide a configuration which specifies the types of accessibility events that the service handles and additional information about the service. The configuration of an accessibility service is contained in the {@link android.accessibilityservice.AccessibilityServiceInfo} class. Your service can build and set a configuration using an instance of this class and {@link android.accessibilityservice.AccessibilityService#setServiceInfo setServiceInfo()} at runtime. However, not all configuration options are available using this method.
Beginning with Android 4.0, you can include a {@code <meta-data>} element in your manifest with a reference to a configuration file, which allows you to set the full range of options for your accessibility service, as shown in the following example:
<service android:name=".MyAccessibilityService"> ... <meta-data android:name="android.accessibilityservice" android:resource="@xml/accessibility_service_config" /> </service>
This meta-data element refers to an XML file that you create in your application’s resource directory ({@code <project_dir>/res/xml/accessibility_service_config.xml}). The following code shows example contents for the service configuration file:
<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/accessibility_service_description" android:packageNames="com.example.android.apis" android:accessibilityEventTypes="typeAllMask" android:accessibilityFlags="flagDefault" android:accessibilityFeedbackType="feedbackSpoken" android:notificationTimeout="100" android:canRetrieveWindowContent="true" android:settingsActivity="com.example.android.accessibility.ServiceSettingsActivity" />
One of the most important functions of the accessibility service configuration parameters is to allow you to specify what types of accessibility events your service can handle. Being able to specify this information enables accessibility services to cooperate with each other, and allows you as a developer the flexibility to handle only specific events types from specific applications. The event filtering can include the following criteria:
For more information about the XML attributes which can be used in the accessibility service configuration file, follow these links to the reference documentation:
For more information about which configuration settings can be dynamically set at runtime, see the {@link android.accessibilityservice.AccessibilityServiceInfo} reference documentation.
An application that provides accessibility service must extend the {@link android.accessibilityservice.AccessibilityService} class and override the following methods from that class. These methods are presented in the order in which they are called by the Android system, from when the service is started ({@link android.accessibilityservice.AccessibilityService#onServiceConnected onServiceConnected()}), while it is running ({@link android.accessibilityservice.AccessibilityService#onAccessibilityEvent onAccessibilityEvent()}, {@link android.accessibilityservice.AccessibilityService#onInterrupt onInterrupt()}) to when it is shut down ({@link android.accessibilityservice.AccessibilityService#onUnbind onUnbind()}).
These callback methods provide the basic structure for your accessibility service. It is up to you to decide on how to process data provided by the Android system in the form of {@link android.view.accessibility.AccessibilityEvent} objects and provide feedback to the user.
The Android system provides information to accessibility services about the user interface interaction through {@link android.view.accessibility.AccessibilityEvent} objects. Prior to Android 4.0, the information available in an accessibility event, while providing a significant amount of detail about a user interface control selected by the user, typically provided limited contextual information. In many cases, this missing context information might be critical to understanding the meaning of the selected control.
A typical example of an interface where context is of critical importance is a calendar or day planner. If a user selects a 4:00 PM time slot in a Monday to Friday day list and the accessibility service announces “4 PM”, but fails to indicate this is a Friday a Monday, the month or day, this is hardly ideal feedback for the user. In this case, the context of a user interface control is of critical importance to a user who wants to schedule a meeting.
Android 4.0 significantly extends the amount of information that an accessibility service can obtain about an user interface interaction by composing accessibility events based on the view hierarchy. A view hierarchy is the set of user interface components that contain the component (its parents) and the user interface elements that may be contained by that component (its children). In this way, the Android system can provide much richer detail about accessibility events, allowing accessibility services to provide more useful feedback to users.
An accessibility service gets information about an user interface event through an {@link android.view.accessibility.AccessibilityEvent} passed by the system to the service’s {@link android.accessibilityservice.AccessibilityService#onAccessibilityEvent onAccessibilityEvent()} callback method. This object provides details about the event, including the type of object being acted upon, its descriptive text and other details. Starting in Android 4.0 (and supported in previous releases through the {@link android.support.v4.view.accessibility.AccessibilityEventCompat} object in the Support Library), you can obtain additional information about the event using these calls:
Important: The ability to investigate the full view hierarchy from an {@link android.view.accessibility.AccessibilityEvent} potentially exposes private user information to your accessibility service. For this reason, your service must request this level of access through the accessibility service configuration XML file, by including the {@code canRetrieveWindowContent} attribute and setting it to {@code true}. If you do not include this setting in your service configuration xml file, calls to {@link android.view.accessibility.AccessibilityEvent#getSource getSource()} fail.
The API Demo project contains two samples which can be used as a starting point for generating accessibility services ({@code <sdk>/samples/<platform>/ApiDemos/src/com/example/android/apis/accessibility}):