Android 17's accessibility lock works only if the user turns Advanced Protection on; no uptake figure found

Three conditions, and only one has a number

Three things must be true on a phone before Google's new accessibility restriction does anything. The phone must run Android 17. Its owner must have switched Advanced Protection on. And the app asking for accessibility access must not be a verified accessibility tool. As of 5 October 2026, only the first has a published figure. StatCounter, a web-analytics firm, puts Android 17 at 5.51% of UK Android mobile and tablet page views for September, up from 0.13% in June (its data, read on 5 October; it measures web traffic, not installed phones). Google's own distribution dashboard carries data only to 24 November 2025 and has no Android version table. For the second condition, Google's developer documentation calls Advanced Protection "Designed as an opt-in feature", and no figure for how many people have turned it on was found from Google or anyone else.

That does not establish that the control is weak where it applies. For a phone inside all three conditions, Google's announcement describes the removal of a route that banking trojans and spyware use. What the conditions fix is who is inside. It also does not establish that Android malware will stop using the AccessibilityService API, that fraud losses will fall, or that 1 October brought a new decision. Google described the same restriction on 12 May, 142 days earlier (derived), and Android Authority reported it running in an Android 17 beta on 13 March.

This briefing sets out what Google stated, what "verified" rests on in Google's own documents, what UK fraud data can and cannot say about the risk, and what a bank, fintech or security lead can do now. It does not describe how to abuse the API. Anything marked "read" or "not found" was checked on the afternoon of 5 October 2026 and can change.

What Google announced, and what is older than the announcement

The post of 1 October 2026 is titled "6 ways Advanced Protection on Android keeps you safe". Its third item, "Accessibility Protection", says that enabling Advanced Protection in Android 17 "automatically restricts AccessibilityService access exclusively to verified applications categorized as Accessibility Tools" (Google Security Blog). It adds that apps abusing the API "remain a primary vector for attackers executing fraud and scams". Google gives no share for "primary vector" and no measured effect for the restriction. The post is Google describing its own product, an announcement and not an evaluation. The Hacker News and Help Net Security covered it on 2 October and follow Google's post; they are used here as pointers only (The Hacker News, Help Net Security).

The post also says every feature in it is available on Android 17 devices, with two exceptions (USB Protection and Failed Authentication Lock) that reach only select Android 17 devices. Then it says: "If you already use Advanced Protection, you will see a notification once these new capabilities arrive on your device." So availability is staged, and no date is given.

How the restriction reached the 1 October post. Dates are from the sources shown; day counts are derived by this briefing.

1. Date

   26 Feb 2026

   What the source says

   Android 17 Beta 2 released. The Beta 2 post read for this briefing does not mention the accessibility change.

   Source

   Android Developers Blog

2. Date

   13 Mar 2026

   What the source says

   Android Authority reports the restriction working in Beta 2 on a Pixel 9a, and not on a Pixel 10 Pro running stable Android 16 with Advanced Protection on. One test.

   Source

   Android Authority (secondary)

3. Date

   12 May 2026

   What the source says

   Google: with Android 17 it is "removing access to the accessibility service from all apps that are not labeled as accessibility tools".

   Source

   Google Security Blog

4. Date

   16 Jun 2026

   What the source says

   Android 17 released to "most supported Pixel devices", with new devices "in the coming months". The release post does not mention this restriction.

   Source

   Android Developers Blog

5. Date

   1 Oct 2026

   What the source says

   "Accessibility Protection" item in the Advanced Protection post. Existing users to be notified when it arrives.

   Source

   Google Security Blog

Date	What the source says	Source
26 Feb 2026	Android 17 Beta 2 released. The Beta 2 post read for this briefing does not mention the accessibility change.	Android Developers Blog
13 Mar 2026	Android Authority reports the restriction working in Beta 2 on a Pixel 9a, and not on a Pixel 10 Pro running stable Android 16 with Advanced Protection on. One test.	Android Authority (secondary)
12 May 2026	Google: with Android 17 it is "removing access to the accessibility service from all apps that are not labeled as accessibility tools".	Google Security Blog
16 Jun 2026	Android 17 released to "most supported Pixel devices", with new devices "in the coming months". The release post does not mention this restriction.	Android Developers Blog
1 Oct 2026	"Accessibility Protection" item in the Advanced Protection post. Existing users to be notified when it arrives.	Google Security Blog

From the Android Authority report to Google's post is 202 days, from Google's first statement 142 days, and from the public release 107 days (all derived). Reading these together, 1 October looks like a rollout notice, not a policy decision. That is inference: Google does not say whether the restriction was already in the 16 June build or arrives with a later update. Android Authority's single test also suggests that the first cohort of Advanced Protection users, those on Android 16, do not get it. Google's own page for app developers on Advanced Protection, last updated 29 July 2026, lists the changes apps must account for (disabled 2G, blocked sideloading, forensic logging, blocked calls from unknown numbers, link spam protection) and does not name this one (Android Developers).

What "verified" means in Google's own pages

The 1 October post does not define "verified". Two other Google pages come closest. Google Play's policy says only services designed to help people with disabilities are eligible to declare themselves accessibility tools, and that the declaration is the isAccessibilityTool attribute in the service's metadata file. It then uses the word "verified" for the flagged apps: "Verified accessibility tools, identified by the isAccessibilityTool="true" flag" (Play Console Help). Since 3 November 2021, an app that targets Android 12 (API level 31) and includes an accessibility service completes a declaration in Play Console: the core feature, the disabilities served, the target users, and a link to a short video. Screen readers, switch-based input, voice-based input and braille-based access are given as examples. Antivirus software, automation tools, assistants, monitoring apps, cleaners, password managers and launchers are named as not eligible. A general voice assistant that happens to help some users with motor impairments would not qualify.

The weak joint is in the Android API reference. It describes the attribute as indicating whether the service assists users with disabilities, and says: "This criteria might be defined by the installer. The default is false." (AccessibilityServiceInfo). So the flag is something an app declares, and Google's reference leaves the criteria to the installer. None of the pages read says whether the Android 17 restriction checks the declared flag alone or also whether the installer vetted it. Inference: on an Advanced Protection phone the same help page says the mode will "block the installation of apps from unknown sources", which narrows how an app that merely declares the flag could arrive. Google does not say the two controls were designed to work together.

Stated and not stated, from Google pages read on 5 October 2026.

1. Question

   Who is covered

   Stated

   Users who turn Advanced Protection on. Google: "Designed as an opt-in feature".

   Not stated

   How many users have. No figure found from Google or any other source.

2. Question

   What "verified" is

   Stated

   Play ties it to the isAccessibilityTool flag plus a Play Console declaration with a video.

   Not stated

   Review time, rejection rate, appeals, or how many apps are verified.

3. Question

   Who is excluded

   Stated

   Antivirus, automation, assistants, monitoring, cleaners, password managers and launchers are named as not eligible.

   Not stated

   How assistive tools distributed outside Google Play are treated.

4. Question

   What happens to apps that already have access

   Stated

   Google, 12 May: "removing access" from apps not labelled as tools.

   Not stated

   The user-facing behaviour. Android Authority saw revocation and blocked new grants in one beta test.

5. Question

   When

   Stated

   "Available on Android 17 devices"; users notified "once these new capabilities arrive".

   Not stated

   A date, or whether it shipped in the 16 June build.

6. Question

   Effect on fraud

   Stated

   API abuse is "a primary vector".

   Not stated

   Any share of fraud or malware that uses the API, or any measured effect.

7. Question

   Managed devices

   Stated

   12 May: Android Enterprise support for Advanced Protection "later in the year".

   Not stated

   A date or a policy name. Not found in the Android Management API reference on 5 October.

Question	Stated	Not stated
Who is covered	Users who turn Advanced Protection on. Google: "Designed as an opt-in feature".	How many users have. No figure found from Google or any other source.
What "verified" is	Play ties it to the isAccessibilityTool flag plus a Play Console declaration with a video.	Review time, rejection rate, appeals, or how many apps are verified.
Who is excluded	Antivirus, automation, assistants, monitoring, cleaners, password managers and launchers are named as not eligible.	How assistive tools distributed outside Google Play are treated.
What happens to apps that already have access	Google, 12 May: "removing access" from apps not labelled as tools.	The user-facing behaviour. Android Authority saw revocation and blocked new grants in one beta test.
When	"Available on Android 17 devices"; users notified "once these new capabilities arrive".	A date, or whether it shipped in the 16 June build.
Effect on fraud	API abuse is "a primary vector".	Any share of fraud or malware that uses the API, or any measured effect.
Managed devices	12 May: Android Enterprise support for Advanced Protection "later in the year".	A date or a policy name. Not found in the Android Management API reference on 5 October.

The cost of the exemption is real for the people it is meant to protect. If an assistive vendor's app is not flagged or not approved, an Advanced Protection user loses it. The pages read describe no appeal route. Whether an assistive tool distributed through an alternative store can even be installed on an Advanced Protection phone is also not stated, because the same help page says updates are blocked for apps originally installed from unknown sources.

A mode, not a default: the friendly name

"Advanced Protection" sounds like a baseline. It is a mode. Google's developer guide says it was launched in Android 16 and is "aimed at enhancing the security of Android devices for at-risk users, such as journalists and activists". Google's help page says it "gives you the option" to equip devices with Android's most effective security features, and that a screen lock is required first (Android Help). The page for developers is blunt about the price: the mode "prioritizes security over some potentially diminished functionality and usability". In Android Authority's test a third-party customisation app could no longer be granted accessibility with the mode on. That is a good trade for someone who chose it. It also means a control that applies to opted-in users is a control for users who already asked for protection.

The label hides a second collision. Google's help page separates "Device protection" from "Account protection", the enrolment of a Google Account in the Advanced Protection Program. A staff member who says they have Advanced Protection on may mean only the account. On the page's structure, the sideloading block and the accessibility line sit with device protection (inference).

There is also an overlap to weigh. Advanced Protection already blocks installs from unknown sources, and Google's review of 2025, published 19 February 2026, describes its Play Protect enhanced fraud protection as triggered when a user tries to install, from an "Internet-sideloading source" such as a web browser or messaging app, an app that requests a sensitive permission (Google). Inference: for opted-in users the accessibility restriction is an extra layer on a route that is already narrowed. Google publishes scale numbers when it has them: that review reports 266 million risky installation attempts blocked in 2025, across 185 markets and more than 2.8 billion devices. It has published no equivalent for Advanced Protection uptake.

What the UK numbers can and cannot say

UK Finance's Annual Fraud Report 2026, published 15 June, records £1,279.8m of losses in 2025: £703.4m unauthorised and £576.4m authorised push payment (APP) (UK Finance). One category is defined by the banking app: mobile banking fraud, where a criminal uses compromised account details to reach an account "through a banking app downloaded to a device only". It was £43.9m, down 10%, on a record 25,180 cases, up 21%. That is 3.4% of losses and 0.62% of cases (both derived). Browser banking on a phone is counted as internet banking.

That figure is a ceiling for one category, not an estimate of accessibility abuse. UK Finance's definition says compromised account details, not malware. It does not split by operating system or method, and its definition of APP fraud (the account holder is tricked into authorising the payment) leaves it unclear where a phone-takeover case is booked (inference). A reader cannot get from £43.9m to a figure for Android accessibility abuse, and no report read for this briefing does either.

What each UK source establishes and does not. Sources read on 5 October 2026.

1. Source and finding

   UK Finance 2025: mobile banking fraud £43.9m, 25,180 cases

   Establishes

   Size of the app-defined category and its direction.

   Does not establish

   How many cases were Android, malware or accessibility abuse.

2. Source and finding

   UK Finance 2025: APP £576.4m, 45.0% of losses (derived)

   Establishes

   The largest slice is payments customers authorise.

   Does not establish

   Any link to accessibility. A device restriction does not reach a payment authorised in a call or a chat.

3. Source and finding

   BioCatch and Nasdaq Verafin foreword: remote access and malware "have declined"

   Establishes

   A partner vendor reads these methods as falling.

   Does not establish

   A UK Finance finding. The partners supply fraud-detection technology.

4. Source and finding

   Cifas Fraudscape 2026: 444,000 cases; 78,000 account takeovers, 18%

   Establishes

   Account takeover is a large share of filings.

   Does not establish

   Anything about banking apps: the phone cases are telecom products.

5. Source and finding

   Cifas, CDA, UK Finance, 13 Nov 2025: remote access bank scam

   Establishes

   A live scam in which a fake bank page installs software on the victim's computer.

   Does not establish

   An Android accessibility case. It concerns a computer.

6. Source and finding

   Zimperium, 2026: 34 malware families, 25 with full device control; 69 UK banking apps targeted

   Establishes

   UK apps are on target lists, per a mobile security vendor.

   Does not establish

   How many families use the accessibility API, or any UK victim count.

Source and finding	Establishes	Does not establish
UK Finance 2025: mobile banking fraud £43.9m, 25,180 cases	Size of the app-defined category and its direction.	How many cases were Android, malware or accessibility abuse.
UK Finance 2025: APP £576.4m, 45.0% of losses (derived)	The largest slice is payments customers authorise.	Any link to accessibility. A device restriction does not reach a payment authorised in a call or a chat.
BioCatch and Nasdaq Verafin foreword: remote access and malware "have declined"	A partner vendor reads these methods as falling.	A UK Finance finding. The partners supply fraud-detection technology.
Cifas Fraudscape 2026: 444,000 cases; 78,000 account takeovers, 18%	Account takeover is a large share of filings.	Anything about banking apps: the phone cases are telecom products.
Cifas, CDA, UK Finance, 13 Nov 2025: remote access bank scam	A live scam in which a fake bank page installs software on the victim's computer.	An Android accessibility case. It concerns a computer.
Zimperium, 2026: 34 malware families, 25 with full device control; 69 UK banking apps targeted	UK apps are on target lists, per a mobile security vendor.	How many families use the accessibility API, or any UK victim count.

On the last row: Zimperium names accessibility abuse, with overlay attacks and command-and-control, among the techniques of the four families that dominate attack volume (TsarBot, Copybara, Hydra and Hook). It does not say how many of its 34 families rely on the API, and "full device control" is a capability, not a named mechanism. Zimperium sells mobile app protection and its report recommends it, so treat its forecasts as forecasts. Its 69 UK apps is the highest in its European table; the United States has 162 (Zimperium). For what happens after the API is abused, this site has already covered a Gemini-assisted Android trojan and a banking overlay kit with a remote-control module.

What the control does not touch

The restriction leaves the following outside it, on Google's own descriptions. Every Android phone without Advanced Protection. With no uptake figure the size of that group cannot be stated; for a mode Google aims at at-risk users it is likely to be large (inference). Phones on Android 16 and earlier, since Google calls this an Android 17 change and Android Authority's one test on Android 16 found it absent. Users without the mode who are talked into allowing restricted settings for a sideloaded app: Google's help page says such settings "can't be changed unless you allow restricted settings" and gives the steps (Android Help). Users who turn the mode off: Google's page describes that as a settings action authenticated by biometrics or PIN, and whether the in-call protections Google describes for Play Protect also cover Advanced Protection is not stated. And it does not touch the many ways a user is persuaded to authorise a payment themselves.

It is also an Android control. It changes nothing for customers on iPhones, and nothing for the 94.49% of UK Android page views that are not from Android 17 devices (derived from the StatCounter figure above, with the same caveat, read on 5 October). Google's May post also describes separate measures: Live Threat Detection warnings for accessibility overlay, and dynamic signal monitoring "enabled on Android 17 devices" with protections "rolling out in the second half of the year" (Google). They are not what the 1 October post announces.

For UK bank and fintech teams and for managed fleets

Three groups should read the announcement differently from a consumer. App teams at banks and fintechs, whose app a trojan wants to drive, get two documented hooks and one gap. The hooks: an app can read Advanced Protection state through the AdvancedProtectionManager API (API level 36, with the QUERY_ADVANCED_PROTECTION_MODE permission), and Google says developers "can be notified when Advanced Protection is enabled so that they can auto-enable any features they have for this user population" (Android Developers). A new "View Supporting Apps" page shows users which installed apps check that status. The gap: how "verified" is checked on the phone is not stated, as above. The same flag already gates a view-level control: since API level 34 an app can mark a view so that only services flagged as accessibility tools interact with it (View reference).

Customer fraud teams get no published baseline either, so the practical move is to measure: how many of your active app sessions come from Android 17 phones, how many of those report Advanced Protection if your app reads it, and what your case data show for each group. Organisations with BYOD or managed Android fleets get a mixed picture. The NCSC treats device management as the heart of BYOD ("it is really the concept of device management that is key", NCSC), and Advanced Protection is a switch on the phone that no document read says an organisation can enforce.

Controls an organisation can set today, and what is not found. Android Management API reference and release notes read on 5 October 2026.

1. Control

   permittedAccessibilityServices (Android Management API)

   What the documents say

   If not set, "any accessibility service can be used". If set, only listed services and the built-in one. On fully managed devices and work profiles.

   Gap

   A package allow-list, not tied to the tool flag. Applied to a work profile it "affects both the personal profile and the work profile".

2. Control

   Untrusted apps policy (advancedSecurityOverrides)

   What the documents say

   Default is to disallow untrusted app installs on the entire device.

   Gap

   An administrator can loosen it, including for the personal profile only.

3. Control

   Advanced Protection by policy

   What the documents say

   Google, 12 May: Android Enterprise support "later in the year".

   Gap

   No policy field in the reference; release notes end in July 2026; the 23 September Android Enterprise post does not mention it.

4. Control

   Developer verification (Google Play and sideloading)

   What the documents say

   Google: protections begin 30 September 2026 for installs from participating stores in Brazil, Indonesia, Singapore and Thailand; global in 2027.

   Gap

   The UK is not listed as read on 5 October, five days after the start.

Control	What the documents say	Gap
permittedAccessibilityServices (Android Management API)	If not set, "any accessibility service can be used". If set, only listed services and the built-in one. On fully managed devices and work profiles.	A package allow-list, not tied to the tool flag. Applied to a work profile it "affects both the personal profile and the work profile".
Untrusted apps policy (advancedSecurityOverrides)	Default is to disallow untrusted app installs on the entire device.	An administrator can loosen it, including for the personal profile only.
Advanced Protection by policy	Google, 12 May: Android Enterprise support "later in the year".	No policy field in the reference; release notes end in July 2026; the 23 September Android Enterprise post does not mention it.
Developer verification (Google Play and sideloading)	Google: protections begin 30 September 2026 for installs from participating stores in Brazil, Indonesia, Singapore and Thailand; global in 2027.	The UK is not listed as read on 5 October, five days after the start.

Neither UK baseline speaks to this. The NCSC's Android device guidance was last tested on Android 16 in work managed mode, shows a review date of 13 May 2025, does not mention accessibility services or Advanced Protection, and says the NCSC "will not necessarily have reviewed all these new features" (NCSC). Cyber Essentials requirements v3.3 of April 2026 put phones and BYOD devices that reach organisational data in scope. Its malware option for phones is application allow listing, where "users must not be able to install any application that is unsigned or has an invalid signature", and it does not mention accessibility services either (Cyber Essentials). So no baseline tells you to act on this announcement. It is your risk assessment.

The user guidance in item 6 is anchored in the sources. The CDA, Cifas and UK Finance warning of 13 November 2025 quotes Cifas's chief executive: "Banks will never ask you to download software or transfer funds to protect your account." It lists 159 as the way to reach a bank's fraud team (Cifas). That warning concerns a computer, not an Android phone, so use it as a style of message, not as evidence about this API.

The question that exposes the gap

Google cannot say, in the pages read, how many people have switched Advanced Protection on. UK Finance cannot say how much of £43.9m of app-defined fraud involved an accessibility service. Each missing number is reasonable on its own. Together they mean the announcement cannot yet be turned into a statement about risk in your estate.

How many of your own customers and staff are on an Android 17 phone with Advanced Protection switched on, and what protects the rest?

Key facts