Android touch automation needs AccessibilityService to dispatch user-configured gestures, but the system warning is necessarily broad.

For Phone Operator, I currently show a disclosure before opening Android settings, explain what the service does and does not do, require the user to start every run, keep a visible stop controller and foreground notification, and provide a direct path to disable the service. Scripts stay on the device unless the user explicitly shares one.

I am trying to balance meaningful consent with an onboarding flow that does not overwhelm first-time users. For Android users and developers, which signals matter most before you would grant this access: no screen-content collection, local-only scripts, a visible stop control, a short test mode, or something else?

I will use the feedback to improve the permission guide and onboarding.

Building an Android auto-clicker taught me that dispatching a gesture is the easy part. The harder problem is making every action understandable and predictable for the user.

For Phone Operator, I have been using four design rules:

1. The marker must show the real action. A tap marker should display the configured random radius, while a swipe marker should show direction and distance without moving during execution.

2. Every step needs independent settings. Timing, delay, repeat count, random range, and swipe distance should belong to the individual action instead of a global template.