See Also: AccessibilityService Members
An accessibility service runs in the background and receives callbacks by the system when Android.Views.Accessibility.AccessibilityEvents 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.
xml Example
<service android:name=".MyAccessibilityService"
android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
. . .
</service>xml Example
<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>For more information about creating AccessibilityServices, read the Accessibility developer guide.
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 AccessibilityService.OnServiceConnected. This method can be overriden by clients that want to perform post binding setup.
An accessibility is declared as any other service in an AndroidManifest.xml but it must also specify that it handles the "android.accessibilityservice.AccessibilityService" Android.Content.Intent. Failure to declare this intent will cause the system to ignore the accessibility service. Additionally an accessibility service must request the NoType:android/Manifest$permission;Href=../../../reference/android/Manifest.permission.html#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:
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:
Note: This approach enables setting all properties.
For more details refer to AccessibilityService.ServiceMetaData and <NoType:android/R$styleable;Href=../../../reference/android/R.styleable.html#AccessibilityService>.
Note: This approach enables setting only dynamically configurable properties: AccessibilityServiceInfo.EventTypes, AccessibilityServiceInfo.FeedbackType, AccessibilityServiceInfo.Flags, AccessibilityServiceInfo.NotificationTimeout, AccessibilityServiceInfo.PackageNames
For more details refer to Android.AccessibilityServices.AccessibilityServiceInfo.
A service can specify in its declaration that it can retrieve the active window content which is represented as a tree of Android.Views.Accessibility.AccessibilityNodeInfo. Note that declaring this capability requires that the service declares its configuration via an XML resource referenced by AccessibilityService.ServiceMetaData.
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: Android.Views.Accessibility.AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED, Android.Views.Accessibility.AccessibilityEvent.TYPE_VIEW_HOVER_ENTER, Android.Views.Accessibility.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 Android.Views.Accessibility.AccessibilityRecord.Source of the last received event of the above types or a previous event from the same window (see Android.Views.Accessibility.AccessibilityRecord.WindowId). Invoking this method will return an Android.Views.Accessibility.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:
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.