Accessibility Service Abuse: Android 17 Changes What Attackers Can Do

Android’s accessibility framework exists so that assistive software can read the screen and act on a user’s behalf. It is a genuinely important feature, and it is also the single most valuable permission an attacker can obtain on a phone, which is what makes accessibility service abuse so attractive to banking malware.

Google is restricting it in Android 17. That is significant, and it is worth being precise about what the change does and does not solve for anyone who owns a banking or payments app.

Why This Permission Is the Prize

Granting accessibility gives an application two capabilities that are ordinarily impossible: it can read the content of other apps’ screens, and it can perform interactions as though the user had made them.

For assistive technology that is exactly right. For malware it removes most of the work.

That last row explains why telling a customer to delete the malicious app is not always sound advice. Researchers examining Android banking trojans have documented anti-removal logic across several families, including automatic re-granting of the accessibility permission.

What Android 17 Changes

Google is restricting accessibility access to applications that are genuinely accessibility tools, removing it from apps that are not labelled as such. In practice this narrows the pool of software that can request the permission at all, and it makes a request from an unrelated app look conspicuous.

This is a real improvement and the right direction. Two qualifications matter for planning.

The installed base turns over slowly. Android version adoption takes years to become dominant, and it is uneven across exactly the markets where mobile banking fraud is most active. Your customer base will include older versions for a long time.

Restriction is not elimination. Attackers respond to a narrowed category by presenting as something inside it, or by shifting to adjacent capabilities. The history of platform hardening is a history of technique migration rather than technique disappearance.

What Your App Should Do in the Meantime

Two apps can be running on the same device: yours, and something using accessibility to read it. Only one of them is in a position to notice.

Detect accessibility interaction with sensitive screens. Not as a permission audit but as a live signal, evaluated when it matters, which is at login, transfer and one-time password entry rather than at launch.

Respond proportionately. This control needs care, because genuine assistive users exist and blocking them outright is both a business and an ethical failure. Blocking the sensitive screen with a clear message, while leaving the rest of the app usable, gives real users a path and removes the attacker’s target.

Pair it with overlay and screen capture detection. Accessibility abuse rarely arrives alone. The same session usually involves an overlay, screen recording, or both.

Log every instance. An accessibility service reading a payment screen is one of the strongest fraud signals available on a mobile device. Aggregated across your install base, a cluster tells you a campaign has started.

The Regulatory Angle

Supervisors have moved on this. Malware and compromised environment detection requirements across BNM’s RMiT, the MAS Technology Risk Management Guidelines, HKMA guidance and the BSP circulars increasingly extend past root and jailbreak checks toward the conditions that actually precede fraud, of which accessibility abuse is the clearest example.

If your detection coverage list stops at rooted devices, expect a follow-up question.

Where SecIron Fits

Frequently asked questions

What is accessibility service abuse on Android?

Accessibility service abuse is malware using Android’s accessibility permission to read other apps’ screens and perform taps as though the user had. The permission is granted legitimately through a system dialog, so nothing is exploited. That lets a trojan harvest balances and one-time passwords and operate your app inside the victim’s session.

Does Android 17 stop accessibility service abuse?

Not entirely. Android 17 restricts accessibility access to apps that are genuinely accessibility tools, which narrows who can request it and makes other requests conspicuous. But the installed base turns over slowly and attackers migrate techniques rather than abandon them, so app-level detection is still needed.

How should a banking app respond when an accessibility service reads its screens?

Detect it as a live signal at login, transfer and one-time password entry, then block the sensitive screen with a clear message while leaving the rest of the app usable. Pair it with overlay and screen capture detection, and log every instance, because a cluster across your install base shows a campaign has started.

Conclusion

Android 17 narrows a door that has been open too wide for too long, and the change is worth welcoming. It is not a reason to defer app-level detection, for the ordinary reason that platform improvements reach your customers on a schedule you do not control.

Until the installed base catches up, the app itself remains the only component positioned to notice that something else is reading the screen.

Ready to meet your banking standards?

Talk to us about what your app currently detects when an accessibility service is reading a payment screen, and what it does about it.

Contact us