Docs

Android 17 Accessibility Service Restriction Tracking

Android 17's Advanced Protection Mode blocks non-a11y apps from the AccessibilityService API — track which SDK features silently stop working.

Analytics

Android 17 shipped a security change with a wide blast radius for anything that isn’t a screen reader: under Advanced Protection Mode, only apps flagged isAccessibilityTool="true" — screen readers, switch-access tools, voice-input systems, Braille displays — keep access to the AccessibilityService API. Everything else loses it, including apps that had the permission granted before the change. The motivation is sound: accessibility permissions are abused in the overwhelming majority of Android banking trojans, and this closes a well-worn malware path. The side effect is that a surprising number of legitimate features quietly depend on the same API.

Session-replay tools, some UI-automation and QA frameworks, custom launchers, notification managers, and a handful of analytics SDKs that capture on-screen element hierarchies for heatmaps or rage-tap detection all lean on AccessibilityService under the hood. None of those qualify as accessibility tools under Google’s new criteria, so on any device with Advanced Protection Mode enabled, that instrumentation doesn’t error — it just stops producing events. If nobody’s watching for the gap, “engagement dropped on Android” quietly becomes the story instead of “our screen-capture events silently zeroed out on a subset of devices.”

Data Points to Track

  • AccessibilityService-dependent event volume, isolated per feature — session replay frames, tap-heatmap capture, UI-automation test hooks — tracked separately from core SDK events that don’t touch the API
  • Advanced Protection Mode adoption rate among your Android install base, since it’s opt-in per device and directly predicts how much of your traffic will lose accessibility-based capture
  • Permission-revocation events — apps that previously held AccessibilityService access losing it automatically when AAPM is enabled, logged as a distinct state change rather than inferred from a data gap
  • Feature-level fallback usage — how often a screen-capture or automation feature falls back to a degraded or manual mode versus failing invisibly
  • Android version and OEM split on any accessibility-dependent event stream, since rollout pacing varies by manufacturer through 2026

Setup Steps

  1. Audit every SDK and internal tool that touches AccessibilityService, not just your own code — third-party session-replay and QA libraries are the most common hidden dependency.
  2. Add a device-level flag for Advanced Protection Mode status where obtainable, so accessibility-dependent event streams can be segmented against it instead of aggregated with everything else.
  3. Instrument a heartbeat event for each accessibility-dependent feature — a periodic “still active” ping — so a dead feature shows up as a heartbeat gap instead of just a slow decline in derived metrics.
  4. Log permission state transitions explicitly, distinguishing “never granted,” “granted then revoked by AAPM,” and “granted and active,” rather than treating all three as the same null case downstream.
  5. Build a fallback path for critical features — degrade to a non-accessibility-based capture method where one exists, and track how often that fallback fires versus the primary method.

Actionable Insights

A heartbeat gap that lines up with Android 17 rollout timing and correlates with Advanced Protection Mode adoption confirms the cause quickly — without it, teams tend to chase the wrong hypothesis (a release regression, a network issue) for days before finding the real one. A feature with a high fallback-fire rate is a candidate for rebuilding on a supported API rather than continuing to patch around a permission that most of your Android base will never grant it again.

Segmenting by Android version and OEM also tells you how fast the problem grows: if Advanced Protection Mode adoption is still low on your install base, this is a small-scale fix today and a much bigger one in six months if the dependency isn’t removed first.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert