How to Fix Google Play AccessibilityService API Rejection
Verify whether the service is a genuine accessibility tool, repair the disclosure and declaration flow, remove prohibited automation, and submit evidence from the exact release.
Direct answer
Start with the exact signed AAB and determine why every AccessibilityService exists. Set isAccessibilityTool=true only when the app's primary purpose is directly helping people with disabilities; do not use the flag for a launcher, automation tool, assistant, monitor, cleaner, password manager, or antivirus merely because some users with disabilities benefit. Other policy-compliant uses need an accurate Play Console declaration plus a separate in-app disclosure and affirmative consent before the user is sent to Accessibility settings. Remove the service when a narrower API can perform the feature, and remove any prohibited behavior that changes settings without permission, bypasses platform controls, deceives users, records remote-call audio, or autonomously initiates, plans, and executes actions or decisions. Submit a new build after code, manifest, disclosure, or behavior changes; appeal only when the exact reviewed release already complies and the enforcement rests on a specific factual error.
Match the wording in your rejection
“Your app is not an accessibility tool”
The isAccessibilityTool flag is reserved for services whose primary purpose is helping people with disabilities overcome disability-related challenges. Incidental accessibility benefit does not qualify.
“Prominent disclosure and consent requirement”
A non-accessibility-tool app must show a separate in-app disclosure in the normal feature flow, explain the data accessed and its use or sharing, and obtain affirmative consent before enabling the service.
“Accessibility API declaration is invalid or incomplete”
The Play Console answers, data types, store listing, release behavior, and demonstration video must all describe the same service and exact version under review.
“Autonomous actions or decisions”
Google prohibits non-accessibility tools from using the API to autonomously initiate, plan, and execute actions or decisions. Deterministic, rule-based automation can be allowed only when it has a narrow, clearly understood purpose and complies with the rest of the policy.
Google detects AccessibilityService after you removed the feature
Inspect the merged manifest and service metadata inside the signed AAB. A library, product flavor, dynamic feature, or active older artifact can still contribute the service.
What this rejection usually means
An AccessibilityService rejection is usually one of four different problems: the app inaccurately claims to be an accessibility tool, a non-tool use lacks compliant disclosure or consent, the service performs prohibited behavior, or the reviewed artifact and declaration do not match. These routes are not interchangeable. A polished disclosure cannot cure prohibited behavior, and isAccessibilityTool=true cannot be used as a shortcut around disclosure. Recovery depends on proving what the exact release service observes, acts on, stores, transmits, and why a narrower API cannot provide the user-facing core feature.
Likely rejection signals
- An AccessibilityService declaration or BIND_ACCESSIBILITY_SERVICE entry appears in the merged manifest of the signed AAB
- isAccessibilityTool=true is set even though disability support is not the app's primary purpose
- The disclosure is only in the store listing, privacy policy, terms, Android service description, or a settings page
- The disclosure omits the screen content, app activity, browsing, messages, identifiers, or other data the service can access
- The app opens Accessibility settings before showing a separate disclosure and receiving affirmative in-app consent
- Consent is bundled with unrelated terms, has no decline path, or uses ambiguous language such as “Got it”
- The service changes device settings, blocks uninstall or disable controls, bypasses privacy or security controls, or manipulates another app's UI deceptively
- Automation goes beyond a narrow user-defined rule and autonomously chooses, sequences, or executes actions
- The Play Console declaration, Data safety answers, privacy policy, store listing, video, and runtime behavior describe different uses
- A library, flavor, dynamic feature, internal track, or older active APK still contains the service after the feature was removed
Recovery plan
- Preserve the full enforcement notice and record the package name, version code, track, review date, cited policy text, declaration answers, video URL, and any reviewer attachment.
- Inspect the merged manifest and accessibility-service metadata from the exact signed AAB. Inventory every service, contributing module or SDK, isAccessibilityTool value, event type, package-name filter, capability, flag, feedback type, and configuration resource.
- Trace the actual data and action path. For every event or node your service can observe, document what is read, whether it leaves the device, who receives it, retention, and every action the service can perform in another app or in system UI.
- Choose the correct eligibility route. Claim accessibility-tool status only when direct disability support is the app's primary purpose and is obvious in the product and listing. Otherwise remove the flag and evaluate the feature as a non-tool use.
- Apply the minimum-scope test. Replace AccessibilityService when a narrower API or user-driven system surface can deliver the feature. Restrict event types, package names, view retrieval, actions, and data collection to what the remaining core function demonstrably requires.
- Remove prohibited behavior before polishing the declaration. Do not change settings without permission, obstruct uninstall or service disablement, bypass platform privacy or security controls, deceive users through UI manipulation, record remote-call audio, or autonomously initiate, plan, and execute actions or decisions.
- For deterministic automation, make the rule static, human-defined, narrow, and understandable. Require the user to configure or trigger the purpose, constrain what can happen, expose a stop or disable path, and show that the service is not making open-ended decisions.
- If the app is not an accessibility tool, show a standalone disclosure in the normal feature flow immediately before the user is sent to grant accessibility access. Name the feature, the data accessed or collected, how it is used or shared, and provide clear accept and decline actions.
- Make refusal safe. A user who declines must not be trapped in the permission flow; keep the rest of the app usable where possible and let the user intentionally restart the feature setup later.
- Reconcile the Play Console declaration, isAccessibilityTool flag, store listing, privacy policy, Data safety answers, in-app disclosure, SDK data flow, and reviewer instructions with the exact new release. Resubmit the declaration whenever API use changes.
- Record the required evidence video from a clean install of the release build. Show app launch, navigation to the full disclosure, accept and decline paths, the Android accessibility grant, and the core feature using the service; add captions or narration when the use is not visually obvious.
- Choose the recovery route. Upload a new AAB after any manifest, service, scope, disclosure, consent, data-flow, or behavior change. Clarify or appeal only when the reviewed artifact already complies and you can identify the factual mismatch precisely.
Evidence to prepare
- Full rejection notice with package, version code, track, date, and exact policy wording
- Merged manifest and accessibility-service XML from the exact signed AAB
- Service inventory covering event types, capabilities, package filters, flags, actions, and isAccessibilityTool
- Data-flow map for all screen, app-activity, browsing, message, identifier, or other data accessible through the service
- Minimum-scope analysis showing why a narrower API works or why it cannot support the core feature
- Screenshots and copy for the standalone disclosure, affirmative consent, decline path, and re-entry path
- Current Play Console declaration, Data safety answers, store listing, privacy policy, and reviewer instructions
- Clean-install video showing launch, full disclosure, consent and refusal, Android Settings grant, and the core use
- Before-and-after artifact diff for any removed service, capability, dependency, or prohibited action
Appeal or fix first?
Appeal or request clarification when Google identified the wrong version or track, the signed artifact does not contain the cited service or flag, or the exact reviewed release already uses the correct eligibility route with compliant behavior, declaration, disclosure, consent, and evidence. Anchor the appeal to the specific incorrect fact rather than asserting that the API is generally allowed.
Fix and submit a new build when the app misuses isAccessibilityTool, a narrower API is sufficient, the disclosure or consent flow is incomplete, the declaration does not match runtime data access, the video omits a required path, the service is broader than necessary, or any prohibited behavior remains. Policy wording alone cannot repair the shipped artifact.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the package, version code, track, service class, isAccessibilityTool value, and cited policy finding.
- State whether the release is a genuine accessibility tool, a permitted non-tool use, or has removed the service entirely.
- For retained use, describe the narrow core feature, exact data and actions, minimum-scope rationale, disclosure and consent sequence, and declaration video timestamps.
- For removed or reduced use, attach the merged-manifest and service-configuration diff from the signed AAB.
- Ask for review of the corrected release or reconsideration of one documented factual error without promising approval or concealing other uses.
Frequently asked questions
Can I set isAccessibilityTool=true to avoid the disclosure requirement?
Only when the app's primary purpose is helping people with disabilities access their device or overcome disability-related challenges. Google specifically says that general assistants, automation tools, monitoring apps, cleaners, password managers, antivirus apps, and launchers do not qualify merely because some users with disabilities benefit.
Is AccessibilityService allowed for automation apps?
Google permits deterministic, rule-based automation for a narrow and clearly understood purpose, subject to the rest of the policy. A non-accessibility-tool app may not use the API to autonomously initiate, plan, and execute actions or decisions.
Is the Android accessibility service description enough disclosure?
No. Google says AccessibilityService_description or htmlDescription cannot replace the separate in-app prominent disclosure. The video must show the full disclosure, affirmative consent, refusal path, system grant, and core use.
What must the prominent disclosure say?
It should explain why the feature needs AccessibilityService, what data the API accesses or collects, and how that data is used or shared. It must appear inside the normal app flow, be separate from other disclosures, and require affirmative action before the accessibility grant flow.
Why is Google still detecting AccessibilityService after I removed it?
A dependency, product flavor, feature module, or older active artifact may still contribute the service. Inspect the merged manifest and service metadata inside the exact signed AAB and reconcile every relevant release track.
Should I appeal or upload a corrected build?
Upload a new build whenever you changed the manifest, service scope, behavior, disclosure, consent flow, SDKs, or declaration-relevant behavior. Appeal only when the exact reviewed release already complied or Google relied on a specific wrong version, flag, or factual finding.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Google Play — Use of the AccessibilityService API. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.