Android's Accessibility API is a powerful, dangerous, and frequently abused piece of platform infrastructure. It's powerful because it lets an app read on-screen content and dispatch synthetic gestures across other apps. It's dangerous because that's also exactly what malware wants to do. It's frequently abused because automation tools, password managers, and accessibility helpers all need it, and not all of them are honest about why.
Google's response, tightened in 2023 and revised again since, is that an app on the Play Store may only use the AccessibilityService if it's the only viable mechanism for an accessibility-relevant feature, and the framing of the app must make that clear in the listing and the in-app disclosure.
Our position
We use the Accessibility API the way it was meant to be used: to help users execute multi-tap sequences they explicitly authored. The disclosure flow that runs on first launch makes this explicit:
- We only act on workflows you author on smartordercapture.com.
- We never read screen content silently — only when an action you authored asks for it.
- Workflows targeting gig-delivery, ticket-scalping, or ad-network packages are blocked.
- You can revoke the permission in Android Settings at any time.
The third bullet is the unusual one. Most Accessibility-using apps will execute any workflow they can express. We refuse to.
The dual-channel strategy
Even with all of that, Play Store reviewers may eventually decide our category is too close to the abuse pattern they're trying to suppress. We don't blame them — they're triaging a flood of bad apps, and pattern matching is faster than case-by-case review.
That's why we ship a direct APK from smartordercapture.com in parallel with the Play Store build. Same engine, different applicationId, signed by us. If the Play listing ever comes down, the direct channel keeps every existing user installed and updating, and the install-from-our-site flow on the download page is a single click.
Concretely: never let your distribution depend on a single channel you don't control.
What we don't ship
No root, no shell, no Xposed. The temptation in this category is to use root for the things AccessibilityService can't do (programmatic Wi-Fi toggling, certain system-level taps). We've drawn the line at the public API. The product is what users can author against documented Android primitives, full stop.