Using Android Accessibility Service for Black‑Box Automation Testing

This article introduces the use of Android Accessibility Service as a black‑box automation testing tool, which can achieve functions that standard UiAutomator 1.0/2.0 frameworks cannot, and discusses its advantages, limitations, and practical implementation.

Features of Accessibility Service for black‑box testing

Can run alongside UiAutomator test cases; when a UiAutomator test case finishes, the service resumes.

Automatically starts after device reboot on most devices, enabling testing of app auto‑start behavior.

As an app‑level solution, it can read SMS messages and intercept verification codes for login automation.

High priority and strong keep‑alive capability.

Limitations

Runs in a different process from the app under test, thus only supports black‑box testing.

Permission issues on various Android versions prevent access to system information such as recent apps or current activity.

performAction works only on nodes with clickable=true ; otherwise it fails.

Direct screen manipulation requires the gesture API; key events are limited to Home, Back, notification, quick settings, and power dialogs.

On newer Android versions, launching other apps may fail due to stricter background‑start restrictions.

When the service crashes, the user must manually re‑enable it in settings.

Service configuration and initialization

Define a custom AccessibilityService and override onServiceConnected() to configure the service:

AccessibilityServiceInfo accessibilityServiceInfo = getServiceInfo();
if (accessibilityServiceInfo == null) {
    accessibilityServiceInfo = new AccessibilityServiceInfo();
    setServiceInfo(accessibilityServiceInfo);
}

Set the event types you want to listen to:

accessibilityServiceInfo.eventTypes |= AccessibilityEvent.TYPE_VIEW_CLICKED;
accessibilityServiceInfo.eventTypes |= AccessibilityEvent.TYPE_VIEW_SELECTED;
accessibilityServiceInfo.eventTypes |= AccessibilityEvent.TYPE_VIEW_FOCUSED;
accessibilityServiceInfo.eventTypes |= AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED;

Enable additional flags, e.g., enhanced web accessibility:

accessibilityServiceInfo.flags |= AccessibilityServiceInfo.DEFAULT;
accessibilityServiceInfo.flags |= AccessibilityServiceInfo.FLAG_REQUEST_ENHANCED_WEB_ACCESSIBILITY;

Update the configuration with setServiceInfo(accessibilityServiceInfo) and implement onAccessibilityEvent() to react to UI changes.

Manifest declaration

<service
    android:label="辅助按键服务"
    android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"
    android:exported="true"
    android:directBootAware="true"
    android:name=".service.TaskAccessibilityService">
    <intent-filter>
        <action android:name="android.accessibilityservice.AccessibilityService"/>
    </intent-filter>
    <meta-data
        android:name="android.accessibilityservice"
        android:resource="@xml/accessibility_service_config"/>
</service>

Accessibility service XML configuration

<?xml version="1.0" encoding="utf-8"?>
<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:description="@string/accessibility_service_description"
    android:accessibilityFeedbackType="feedbackAllMask"
    android:canRetrieveWindowContent="true"
    android:canPerformGestures="true"
    android:notificationTimeout="100"
    android:accessibilityFlags="flagDefault"/>

Supported actions

The service can invoke methods such as performGlobalAction() and use dispatchGesture() to simulate clicks and swipes. For devices with SDK < 24, use AccessibilityNodeInfo.performAction() with actions like ACTION_CLICK , ACTION_LONG_CLICK , etc.

Gesture implementation for click and swipe

Path mPath = new Path();
mPath.moveTo(startX, startY); // start point
mPath.lineTo(endX, endY); // end point (if only moveTo, it performs a click)

dispatchGesture(new GestureDescription.Builder()
    .addStroke(new GestureDescription.StrokeDescription(mPath, 50, 500))
    .build(), new GestureResultCallback() {
        @Override
        public void onCompleted(GestureDescription gestureDescription) {
            super.onCompleted(gestureDescription);
            System.out.println("Gesture succeeded");
        }
        @Override
        public void onCancelled(GestureDescription gestureDescription) {
            super.onCancelled(gestureDescription);
            System.out.println("Gesture failed");
        }
    }, null);

If the SDK version is >= 24, you can also obtain the screen coordinates of a node and click directly:

Rect rect = new Rect();
nodeInfo.getBoundsInScreen(rect);
clickScreen(rect.centerX(), rect.centerY());

Handling performAction failures

When performAction fails, it is often because the target AccessibilityNodeInfo is not clickable. Two solutions are provided:

Traverse up the view hierarchy to find a parent node with isClickable() true and invoke performAction(ACTION_CLICK) .

On SDK >= 24, compute the node's screen coordinates and perform a click via the gesture API.

Choosing a testing approach

Three main solutions are compared:

UiAutomator 1.0 : Requires shell permissions, strong keep‑alive, suitable for multi‑app generic scripts; not compatible with Android R (11) emulators.

UiAutomator 2.0 : Runs in the same process as the app, shares its permissions, weaker keep‑alive; ideal for white‑box testing and unit tests.

Accessibility Service : Runs as a separate app with cross‑process capabilities, strong keep‑alive, useful for assistive apps, device maintenance, and automated environment setup.

Overall, the article provides a comprehensive guide to implementing black‑box automation testing using Android Accessibility Service, including configuration, code samples, limitations, and recommendations for selecting the appropriate testing framework.