Android Accessibility Services are intended to assist users with disabilities. Using an accessibility service you may for example change the input focus, scroll a list or press a button. Interestingly this can be done not only for your own app, but for any app on the device. Of course your app must request permission for this.

Scenario

This article describes the usage of accessibility services for the following sample use case:

1. Open calculator app
2. Press button “1”
3. Press button “+”
4. Press button “2”
5. Press button “=”
6. Read the result
7. Go back and display result

Although this is not really the intended use of an accessibility service, this simple use case should demonstrate the functionality in an easy way.

Service configuration

1. Configure accessibility service
   In a separate XML file we need to configure our accessibility service. Here we need to declare that our service wants to retrieve the active window content. The file should be placed in the resource directory of the application (<project_dir>/res/xml/myaccessibilityservice.xml).
   
   myaccessibilityservice.xml

   <?xml version="1.0" encoding="utf-8"?> <accessibility-service xmlns:android="http://schemas.android.com/apk/res/android" android:canRetrieveWindowContent="true" />

   1 2 3 4

   <?xml version="1.0" encoding="utf-8"?> <accessibility-service     xmlns:android="http://schemas.android.com/apk/res/android"     android:canRetrieveWindowContent="true" />

2. Edit AndroidManifest.xml
   Our accessibility service must be declared in the application element of the manifest. In the meta-data tag we reference the previously created accessibility service configuration.
   
   AndroidManifest.xml

   ... <service android:name="MyAccessibilityService" android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"> <intent-filter> <action android:name="android.accessibilityservice.AccessibilityService" /> </intent-filter> <meta-data android:name="android.accessibilityservice" android:resource="@xml/myaccessibilityservice" /> </service> ...

   1 2 3 4 5 6 7 8

   ... <service android:name="MyAccessibilityService" android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">     <intent-filter>         <action android:name="android.accessibilityservice.AccessibilityService" />     </intent-filter>     <meta-data android:name="android.accessibilityservice" android:resource="@xml/myaccessibilityservice" /> </service> ...

Implementation

MyActivity.java

From the main activity (MyActivity.java) we just start the calculator demo (CalculatorDemo.java)..

MyAccessibilityService.java

To implement our accessibility service (MyAccessibilityService.java) we need to derive from the abstract class AccessibilityService. For the calculator demo we just override the onServiceConnected method in order to get a reference of the accessibility service. For the sake of simplicity we just inject it directly to our CalculatorDemo class.

CalculatorDemo.java

Finally the main functionality is implemented in CalculatorDemo.java.

Using the method getRootInActiveWindow of the accessibility service we can access the view hierarchy of the current window. The view hierarchy is represented as a hierarchy of AccessibilityNodeInfo instances. We use the method findAccessibilityNodeInfosByViewId to find the relevant child nodes.

Relevant nodes (and view ID’s) can be found by traversing the node hierarchy. Once we have the relevant nodes, actions can be performed by calling performAction on the specific node.

Full implementation

The following code shows the full implementation of all relevant parts for this demo.

Enable accessibility service

After installing the CalculatorDemo APK, the service must be enabled in the Android settings:

1. Open Android settings
2. Go to “Accessibility”
3. In the “Services” section tap the service (e.g. “CalculatorDemo”)
4. Enable the service

Now the CalculatorDemo APK is ready to be run.

If you’re using JUnit, Mockito and PowerMock to write unit tests in Android Studio you probably often need to mock calls to android.util.Log. That’s because by default in Android Studio unit tests are executed against a modified version of the android.jar library which contains stubs only. If anywhere in your tested code you have a log statement that you don’t mock you will get a RuntimeException.

For example a call like

will throw a RuntimeException:

Wouldn’t it be nice if just all the log message would be redirected automatically to the unit test output?

Fortunately PowerMockito provides the possibility to create MockPolicies. Using a mock policy we can setup the log redirection once and then just use an annotation (on the class containing the test cases) to apply it.

Usage example:

To create a log redirection mock policy we need to implement the PowerMockPolicy interface. The two methods on this interface allow us to apply a class loading policy and an interception policy.

In the first method we need to tell PowerMock which classes should be modified by the mock class loader before these classes are loaded. In our case it’s just the android.util.Log class. In the second method we create the mocks for the methods of the Log class which should just redirect the messages to the standard output.

The following code shows a sample implementation for a mock policy that redirects all log calls to the standard output.