Accessibility services are not the threat. Android lets an app with the accessibility service permission read what is on screen and act on the user’s behalf, so that people with visual, motor or cognitive impairments can use their phones. Malware abuses the same permission after tricking a user into enabling it: it reads one-time codes and balances, types into fields and taps confirm buttons. The defence is to judge behaviour on sensitive screens, not to ban the API. This article covers Android only; iOS offers third-party apps no equivalent service.
The legitimate purpose
Screen readers speak the content of each view. Switch access lets a person drive the phone with one or two physical switches. Voice control turns spoken commands into taps and scrolls. All of these need two powers that sound alarming out of context: reading the content of other apps’ windows and performing input in them.
Android grants those powers only after the user turns the service on in the accessibility settings and accepts a warning that the service can see and control the screen. Services declare their configuration, including whether they present themselves as accessibility tools, and Google Play asks developers to justify their use of the API.
- 2009
Android 1.6
The accessibility service API arrives, letting assistive apps receive events about what is on screen.
- 2016
Android 7.0
Services can dispatch gestures, so switch and voice tools can swipe and tap for the user.
- 2022
Android 13
Restricted settings make it harder to enable accessibility for some apps installed outside an app store.
- 2023
Android 14
Apps can mark views as accessibility-sensitive, so only services declared as accessibility tools read them.
For an app owner, the consequence is plain. A sizeable group of your customers relies on these services every day, and any control that treats accessibility as suspicious by default will lock them out and fill your support queue. The platform itself has moved in the same direction: each change narrows what an undeclared service can do without taking anything away from genuine assistive tools.
Assistive tool behaviour
- Declares itself as an accessibility tool
- Reads content to speak or describe it
- Acts only when the user issues a command
- Follows the user's pace through the screen
Abusive behaviour
- Presents itself as something else entirely
- Reads codes, balances and credentials silently
- Types into fields and taps approve on its own
- Acts in bursts, often behind an overlay
How the abuse chain works
Accessibility malware follows a recognisable pattern. Understanding it at this level is enough to design defences, and each step is also a point where the chain can be broken.
Lure
A disguised app keeps prompting the user until the service is enabled.
Read
The service walks the view tree and reads codes, balances and account numbers.
Act
It sets text, presses buttons and dispatches gestures to complete a transfer.
Detect in the app
Sensitive views are withheld; injected text and dispatched taps raise signals.
Decide on the backend
The signal travels with the request and your rules step up or refuse it.
Getting the permission
The malicious app arrives disguised as something harmless: a delivery tracker, a document viewer or a fake update. Once installed, it keeps prompting the user with a plausible story until they open the settings and enable its service. From that moment it holds the same view of the screen as a screen reader.
Reading what the user sees
The service receives events whenever windows change and can walk the tree of views. Text in labels and fields becomes readable, including account numbers, balances and codes shown in banking or authenticator apps. Blocking screenshots does not help here, because the service reads the view content rather than capturing pixels.
Acting on the user’s behalf
The service can set text in fields, press buttons and dispatch gestures. That lets it approve its own permission prompts, fill in a transfer, confirm it and dismiss the resulting notification, sometimes behind an overlay so the user sees nothing unusual. This is the step that turns information theft into fraud carried out on a genuine device, from a genuine session, which is why device checks and passwords alone do not catch it.
Designing proportionate protection
Good protection keeps assistive users working and makes abuse visible where it costs you money. The table compares the main options.
| Control | What it addresses | Effect on assistive users | Where it fits |
|---|---|---|---|
| Server-side step-up for risky actions | Fraud completed through a hijacked session | None if the step-up itself is accessible | Every app with payments or account changes |
| Marking sensitive views where Android supports it | Non-assistive services reading protected values | Declared accessibility tools keep access | Screens that show codes, balances or credentials |
| Detecting injected text in protected fields | Services typing on the user’s behalf | Low when voice and switch input are tested | Payee, amount and credential fields |
| Detecting dispatched gestures on approve controls | Automated confirmation of transfers | Low when the policy starts in observe mode | Confirm, approve and consent buttons |
| Signals sent to your backend with the request | Decisions made where the attacker has no reach | None | Fraud rules and case handling |
| Blocking every enabled service | Broad, but blunt | High: excludes users who need assistance | Rarely justified |
Testing without excluding people
Test each protected screen with a screen reader, switch access and voice control before you enforce anything. Run the policy in observe mode, check the signals against real support cases, then move specific screens to warn or restrict. Keep the remediation message short and readable by assistive tools, so a legitimate user knows what to do.
- List the screens that show codes, balances, credentials or payee details.
- Mark each of them for protection and confirm a screen reader still reads them.
- Complete a transfer with switch access and with voice control on a protected build.
- Run the policy in observe mode and compare signals with support tickets.
- Move one screen at a time to warn or restrict, with an accessible message.
How Otukan approaches it
Otukan watches what accessibility services do inside your Android app rather than whether they exist. It separates services that declare themselves as assistive tools from others, withholds sensitive views from non-assistive services where Android allows, and detects text injected into protected fields and gestures dispatched on approve controls. Each signal reaches your backend with the related request, including the service class and the screen, and you set the response per screen and per flow, from observe to terminate. Before any screen moves to enforcement, Otukan tests it with screen readers, switch access and voice control. Protection is added within your existing build and release pipeline, and your signing keys never leave your team.
The control itself is covered on Android accessibility abuse detection, part of mobile fraud prevention. The wider Android picture is on Android app security.