Building a no-root Android automation app taught me that trust is harder than features

Roman Rashkovskiy — Sun, 21 Jun 2026 00:20:13 +0000

I’m building ScriptTap, a no-root Android automation app for user-controlled phone workflows.

The app lets people create scripts with taps, swipes, routines, screen-aware checks, OCR/text detection, image/pixel checks, variables, logic, and AI-assisted script creation.

The technical side is hard, but the trust side may be harder.

ScriptTap needs Android Accessibility permission because user-authored input automation requires it. That is a powerful permission. I do not want to minimize it, hide it behind vague onboarding copy, or expect people to click through without understanding what they are enabling.

That creates a product-design problem.

If the copy is too soft, it feels dishonest.

If the copy is too warning-heavy, a legitimate automation tool can feel suspicious before the user even understands what it does.

The explanation I am trying to make clear is:

ScriptTap is no-root.
Scripts are created and controlled by the user.
Screen capture is user-controlled.
It does not bypass Android permissions, lock screens, app security, or consent flows.
Accessibility is required for overlay/input automation, so users should understand why it is being requested.

The short version I keep coming back to is:

ScriptTap uses Accessibility so your scripts can interact with the screen the way you tell them to. This is a powerful permission. You should only enable it if you understand and trust what the app is doing.

For developers who have built apps with sensitive permissions:

How did you explain the permission without either hiding the risk or scaring users away from a legitimate feature?

DEV Community: Roman Rashkovskiy

Building a no-root Android automation app taught me that trust is harder than features