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

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?