Android Accessibility Service, Explained for Gig Drivers

You can't run any gig driver auto-accept tool without granting it Android's Accessibility Service permission. The Settings page where you enable it shows a serious-sounding warning that scares off a lot of new bot users. This is the honest explanation of what the permission does, why your bot needs it, and how to grant it without giving up your phone's security.

TL;DR

• Accessibility Service is the Android API that lets one app see and tap inside other apps. It was built for screen readers; gig bots reuse it.
• The warning Android shows is real. An app with this permission has god-mode visibility into your phone. Grant it only to apps you trust.
• Properly-built tools use it efficiently — ~1% extra CPU, ~2-3% extra battery per hour.
• The permission keeps getting silently disabled because Android's battery optimizer kills the service. Disabling battery optimization for the bot is the fix.
• The major gig platforms can't directly detect what your Accessibility Service is doing, just that one is enabled.

What this permission actually is

Android has dozens of permissions a regular app can request: camera, microphone, location, contacts. Accessibility Service isn't on that list. It's a different category entirely — a system-level service permission that's only meant to be requested by a narrow class of apps (assistive technology for users with disabilities).

When you enable Accessibility Service for an app, the OS starts forwarding two streams of data to that app:

1. Accessibility events. Every time something changes on any screen on your phone — a button appears, text changes, a notification arrives, you scroll a list — the OS fires an event describing it. Your accessibility-enabled app receives every event.
2. Gesture dispatch capability. The app can synthesize taps, swipes, long-presses, and other gestures at any screen coordinate, inside any app.

That's an enormous amount of capability. For a screen reader serving a blind user, this is exactly what's needed: read aloud what's on screen, dispatch taps when the user issues a voice command. For a gig driver bot, the use case is narrower but uses the same mechanism: watch the delivery app for offers, tap accept when one matches your rules.

There is no other Android API that gives bots this capability. Apps cannot normally see or tap other apps' UIs. Accessibility Service is the one exception, deliberately designed for situations where one app legitimately needs to mediate another app's UI.

Why the warning Android shows is real

When you enable an Accessibility Service, Android shows this warning (paraphrased): "This app can observe your actions and retrieve content of windows you interact with. It can also perform actions on your behalf."

That's not boilerplate. The capability is exactly that broad. The app can:

• Read every word on every screen, including text in your banking app, password manager, SMS messages, photos, browser history, and emails
• Dispatch taps inside any app, including transferring money in your banking app or sending messages in any messenger
• Run continuously in the background as long as Accessibility Service is enabled, even after you've removed it from recent apps

Granted to a malicious app, this is a catastrophic-level breach of phone security. Granted to a legitimate app from a reputable developer, it's the mechanism that makes screen readers, password managers, accessibility wear devices, and yes, gig driver bots possible.

The choice you're making isn't "Accessibility Service good or bad." It's "do I trust the specific app I'm granting it to."

What separates a trustworthy bot from a dangerous one

Three signals matter when deciding whether to grant Accessibility Service to a specific app:

Distribution channel. Apps on Google Play go through Play Protect malware scanning, identity verification of the developer, and ongoing monitoring for behavior changes. Apps sideloaded from an APK file have none of these checks. The first rule of accessibility-enabled apps is install only from Google Play.

On-device vs cloud-based architecture. If a tool ships screen contents or any extracted data to a server, you've extended your trust to that server's operators too. An on-device tool that processes everything locally has a much smaller attack surface — if the developer turned malicious tomorrow, the worst they could do is push a poisoned app update, which Play Protect can detect.

Permission discipline. A well-built bot only watches the specific apps it needs to (the gig delivery apps). A poorly-built bot watches every screen on your phone all the time. Both technically have the same permission, but the latter is doing far more than its job requires. Look in the bot's settings — there should be a list of target apps it's actively watching, not "all apps."

Our companion piece on how Amazon Flex bots actually work goes into the architectural choices that distinguish well-built bots from sloppy ones.

The settings flow, step by step

When your gig driver bot prompts you to enable Accessibility Service:

1. Tap "Enable" in the bot's onboarding screen. Android opens Settings → Accessibility.
2. Scroll to the list of installed services. Find your bot's name.
3. Tap the bot's entry.
4. Toggle the switch on.
5. Read and confirm the warning Android shows.

You're now granting the permission. The bot starts receiving the event stream immediately.

A note on the warning text: the warning is the same regardless of whether the app is benign or malicious. Android can't tell which is which. It shows the warning generically because the capability is dangerous, not the specific app. The protection is your decision about trust, not the OS's vetting.

Why your bot keeps "forgetting" the permission

This is the most common support question for any Accessibility Service tool, including ours: "I enabled it, it worked, then a day later it stopped working and the permission was off again. What happened?"

Almost always, the answer is Android's battery optimizer killed the bot's foreground service, and on some OEM-customized Android builds, that triggers the OS to also disable the associated Accessibility Service.

The fix is two settings:

1. Disable battery optimization for the bot. Settings → Apps → [bot name] → Battery → "Unrestricted" or "Don't optimize."
2. On Xiaomi/Redmi/POCO phones: enable Autostart for the bot. Security app → Permissions → Autostart → toggle the bot on.
3. On OnePlus phones: add the bot to your "Battery optimization exempt" list AND enable "Allow auto-launch."
4. On Samsung phones: Settings → Apps → [bot name] → Battery → tap "Allow background activity" and "Unrestricted."

The order matters. Make these changes once and the bot stays running for the full shift.

What the gig platforms can and can't see

A common worry: "If I enable Accessibility Service, can DoorDash / Uber / Flex detect that I have a bot?"

The honest answer is nuanced:

• The platform can detect that you have some Accessibility Service enabled — there's a public Android API to check this, originally added so accessibility apps could detect each other and not conflict.
• The platform cannot detect which Accessibility Service is enabled or what it's doing. They see "user has at least one accessibility service enabled" — that's it. Other things that show up in this check: TalkBack (Android's official screen reader), every password manager, accessibility-enabled custom keyboards, etc.
• The platform cannot directly distinguish a synthetic tap from a real fingertip tap. Both produce the same MotionEvent data structure.

What the platforms can do is look for statistical patterns: superhuman reaction times, accept-rate jumps, identical timing fingerprints across drivers. Our deeper risk analysis in are Amazon Flex bots safe? walks through what's actually detectable and the mitigations that reduce signal.

Should you grant the permission?

If you've understood everything above and you want to run a gig driver bot, the practical answer is: yes, granted to a single reputable on-device tool installed from Google Play, the permission is generally safe. The bot can do exactly what it says — watch the gig delivery apps you've configured and dispatch accept taps you recorded yourself. It cannot read your banking app unless you grant it that specific authority (which you should not).

If you'd rather not grant the permission to anything at all, that's a defensible position too. The cost is doing all your accepting by hand, which means slower reactions and (per our Uber vs manual benchmarks) somewhat lower earnings. That's a fair trade if you value the smaller attack surface.

For the broader picture of how Route Grabber uses Accessibility Service specifically — what it watches, what it doesn't, and how to verify — see how Route Grabber uses Accessibility Service on the homepage. Or jump to our gig driver automation 2026 guide for the bigger-picture playbook.