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

> Source: <https://dev.to/romka2x/building-a-no-root-android-automation-app-taught-me-that-trust-is-harder-than-features-2acn>
> Published: 2026-06-21 00:20:13+00:00

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:

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?
