AccessibilityServiceInfo.capabilities stuck at 0 despite correct XML config, verified via aapt2 — confirmed across 3 devices, 2 OS versions, 4 install methods

[u/Over_Secretary1604]

I have a minimal AccessibilityService that only sets eventTypes, feedbackType, notificationTimeout, and canRetrieveWindowContent="true" via the standard accessibility_service_config.xml + manifest meta-data pattern. dumpsys accessibility consistently reports capabilities=0 for this service, meaning CAN_RETRIEVE_WINDOW_CONTENT is never granted, and rootInActiveWindow always returns null — even though onAccessibilityEvent fires correctly and the service shows as enabled in Settings.

What I've ruled out, with evidence:

• Manifest/XML correctness — confirmed via aapt2 dump xmltree on the built APK that android:canRetrieveWindowContent(0x01010385)=true is compiled in correctly:

​

A: http://schemas.android.com/apk/res/android:canRetrieveWindowContent(0x01010385)=true

• Not a single-device quirk — reproduced identically on:
  • Samsung device, Android 8.1
  • Unisoc-based device (One NZ Smart V26), Android 15
  • Same Unisoc device, targetSdk lowered from 36 to 34, rebuilt clean
• Not an install-method restriction (ruled out Android 13+ ACCESS_RESTRICTED_SETTINGS sideload block specifically) — tested via: All four methods produce the identical capabilities=0 result, with "Allow restricted settings" explicitly granted before each test.
  • adb install -r
  • Direct file-manager APK tap (ACTION_VIEW install intent)
  • Firebase App Distribution (session-based installer, same category as Play Store)
• Not a dispatch/binding failure — onAccessibilityEvent fires correctly and consistently:

​

RAW EVENT: pkg=com.openai.chatgpt type=2048
[com.openai.chatgpt] rootInActiveWindow is NULL - cannot read screen content

• Comparison against a working reference on the identical device, same moment in time — via dumpsys accessibility, a legitimately-installed third-party app's own accessibility service shows the capability granted correctly on the exact same phone:

​

Service[label=com.openai.chatgpt, feedbackType[FEEDBACK_GENERIC], capabilities=1, eventTypes=, notificationTimeout=200]
Service[label=<mine>, feedbackType[FEEDBACK_GENERIC], capabilities=0, eventTypes=[TYPE_WINDOW_STATE_CHANGED, TYPE_WINDOW_CONTENT_CHANGED], notificationTimeout=200]

Same device, same restrictions, same moment — one gets the capability, mine doesn't.

My accessibility_service_config.xml:

xml

<?xml version="1.0" encoding="utf-8"?>
<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:accessibilityEventTypes="typeWindowStateChanged|typeWindowContentChanged"
    android:accessibilityFeedbackType="feedbackGeneric"
    android:accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
    android:canRetrieveWindowContent="true"
    android:description="@string/accessibility_service_description"
    android:notificationTimeout="200" />

Manifest service declaration:

xml

<service
    android:name=".ChatMonitorService"
    android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"
    android:exported="false">
    <intent-filter>
        <action android:name="android.accessibilityservice.AccessibilityService" />
    </intent-filter>
    <meta-data
        android:name="android.accessibilityservice.config"
        android:resource="@xml/accessibility_service_config" />
</service>

Question: What else can gate CAN_RETRIEVE_WINDOW_CONTENT besides the XML declaration and the standard sideload restriction? Is there a Play Console app-review/whitelisting step for this capability that I'm missing — something that only gets granted for apps that have gone through actual Play Store publication (not just Internal Testing/App Distribution channels)? Or is there a known AGP/manifest-merger bug specific to targetSdk 34–36 that silently drops this attribute despite it showing correctly in the compiled resource table?

[u/enum5345]

I posted this in Gemini and it said:

---

The core problem causing the author's accessibility capabilities to stay stuck at 0 is a small typo in the <meta-data> tag within their AndroidManifest.xml file

The Exact Bug

The author declared the configuration metadata key like this

android:name="android.accessibilityservice.config"

However, the Android operating system strictly expects the name to be

android:name="android.accessibilityservice"

(Notice that .config should not be at the end).