Android 17 Just Locked Down the Permission That 90% of Android Malware Exploits

The Permission Malware Loves Most

If you had to pick a single Android feature that malware authors prize above all others, it would be the Accessibility Services API. Designed to help users with disabilities interact with their phones through screen readers, switch controls, and voice input, the API grants an app extraordinary visibility into what is happening on the device. It can observe every screen that opens, read the text displayed in any app, simulate taps and swipes on behalf of the user, and intercept input before it reaches its destination. For a legitimate screen reader, those capabilities are essential. For a banking trojan, they are a complete toolkit for theft.

Researchers have documented at least six distinct Android malware families that rely on the Accessibility Services API as a core part of their attack chain. The list includes overlay trojans that draw fake login screens on top of real banking apps, infostealers that silently read one time passwords as they arrive in SMS apps, and spyware that logs every message typed across all installed applications. Because the permission is granted by the user through a single toggle in settings, and because many legitimate apps have historically requested it, victims often enable it without fully understanding what they are agreeing to. Android 17 changes that calculus entirely.

What Android 17 Actually Changes

Android 17 Beta 2 introduces a significant new restriction inside Android Advanced Protection Mode, which Google refers to as AAPM. When AAPM is active, any app that does not explicitly identify itself as an accessibility tool is barred from using the Accessibility Services API. Apps that already hold the permission when AAPM is enabled will have it automatically revoked. Users cannot manually re-grant the permission to excluded apps without first disabling Advanced Protection Mode entirely.

The mechanism is technically precise. An app qualifies as an accessibility tool only if its manifest sets the isAccessibilityTool="true" flag and its declared purpose falls within Google's narrow definition of what counts as assistive technology. According to Google, the only qualifying categories are screen readers, switch based input systems, voice based input tools, and Braille based access programs. Everything else—including software that has used the API for years—is excluded.

This is not a soft nudge or a warning dialog. It is a hard block enforced at the OS level when the user has opted into the highest security tier Android offers.

How the Accessibility API Became a Malware Superhighway

The abuse pattern is not new. Security researchers began raising alarms about accessibility based attacks in the early 2010s, but the problem accelerated sharply as mobile banking adoption grew. The appeal is straightforward: the API provides a single, user approved pathway into nearly every other app on the device. Once a malicious app obtains accessibility access, it does not need to exploit a vulnerability in the operating system or in a target application. The legitimate API does the work.

Banking trojans use it to perform overlay attacks, rendering a convincing fake interface on top of a real banking app at the exact moment a user opens it. The victim types their credentials into what appears to be their bank's login screen, while the malware captures every keystroke and forwards them to a remote server. The real banking app never receives the input. The user sees a brief error message and assumes the app is slow.

Infostealers take a different approach. Rather than intercepting a specific login, they use accessibility events to monitor every screen transition across all installed apps, logging displayed content continuously. Two factor authentication codes that appear in notification banners, password manager autofill suggestions, email subject lines, chat messages—all of it passes through accessibility events and can be captured without any additional permission beyond the one the user already granted.

The scale of the problem is reflected in Google's own language when announcing the Android 17 restriction. The company described the Accessibility Services API as having been "extensively abused by bad actors in recent years to steal sensitive data from compromised Android devices." That characterization from the platform owner, rather than a third party researcher, signals how seriously Google now treats this attack surface.

Which Apps Are Blocked—and Why That List Surprises People

The decision to explicitly exclude password managers, antivirus software, automation tools, and custom launchers from the accessibility whitelist is likely to generate debate among security professionals and power users. Each of those categories has historically relied on accessibility APIs for core functionality, and in many cases for genuinely protective purposes.

Password managers use accessibility events to detect when a login form is visible and to fill credentials into the correct fields. Antivirus products use them to observe app behavior in near real time and flag suspicious activity. Automation platforms such as scripting tools use them to drive the UI for legitimate workflow tasks. Launchers use them to improve gesture handling and app switching.

Google's rationale appears to be that the attack surface these legitimate use cases create outweighs the benefit within the Advanced Protection Mode context. Users who enable AAPM are explicitly choosing a higher security posture, and Google has made the judgment that no app outside true assistive technology can be trusted with this level of access in that context. The exclusion also removes the social engineering angle: malware frequently disguises itself as a security tool or password manager specifically to justify requesting accessibility access. Closing that loophole means the disguise no longer works.

• Screen readers — permitted
• Switch based input systems — permitted
• Voice based input tools — permitted
• Braille based access programs — permitted
• Password managers — blocked under AAPM
• Antivirus and security apps — blocked under AAPM
• Automation and scripting tools — blocked under AAPM
• Custom launchers — blocked under AAPM

What Developers Need to Know

For developers whose apps currently use the Accessibility Services API for non-assistive purposes, Android 17 introduces a clear migration decision. Apps that qualify as genuine accessibility tools should audit their manifests now and ensure they correctly declare isAccessibilityTool="true" with accurate service descriptions. Apps that do not qualify need to find alternative implementation paths before their users upgrade.

Google has provided the AdvancedProtectionManager API as the integration point for developers who want to detect when a device is running under AAPM. This allows apps to surface appropriate messaging to users—explaining why a particular feature is unavailable in the current security configuration—rather than failing silently or with a confusing error.

The broader implication for developers is that the era of using accessibility access as a convenient workaround for missing platform APIs is ending. Google has been progressively restricting what accessibility events can observe and what they can control. Android 17's AAPM restriction is the sharpest expression of that trend so far, but it follows a trajectory that has been visible for several releases.

What You Should Do Right Now

If you are running Android 16 or earlier and want to reduce your exposure to accessibility based attacks today, review which apps on your device currently hold accessibility access. Open Settings, navigate to Accessibility, and look for any service that is not a screen reader or similar assistive tool. Anything unexpected should be investigated and revoked unless you actively use it.

When Android 17 becomes generally available, consider enabling Advanced Protection Mode if your threat model warrants it. AAPM was introduced in Android 16 and carries additional restrictions beyond accessibility access—including tighter controls on sideloading and network connections. Google is also adding a mandatory 24 hour wait before users can sideload apps from unverified developers, a change that specifically targets the social engineering scams that trick users into disabling Play Protect. It is worth reading through the full scope of changes before enabling AAPM on a device where you rely on third party tools that may be affected.

For users who do not want to give up password manager autofill or other accessibility dependent features, the choice between convenience and the highest security tier will be a real one. Google is not forcing AAPM on anyone. But for users who travel to high risk environments, handle sensitive professional information, or have been targeted in the past, the tradeoff is likely worth it—and Android 17 makes that tradeoff more meaningful than any previous Android release.

The Accessibility API has been the most abused door into Android devices for over a decade. Android 17 is the first version to meaningfully close it for users who choose to let it.