ScriptTap

Because account management system has been rebuilt, you will have to uninstall the app and install it from scratch in order to get your tester menu access back. Old account parameters are not compatible with current tester menu recognition.

Link is on ScriptTap.com

Code 16 is now published for beta testers.

This is not one big feature release. It is a foundational rebuild of how ScriptTap keeps scripts, validation, editing, playback, storage, and overlays synchronized.

Main changes since Code 15:

- ScriptTap now uses one canonical Script Library authority and one resident active tree shared by the Editor and Play.

- Normal actions are RAM-first. The UI updates immediately, then immutable work enters one background writer queue.

- Validation V2 provides precise one-line Editor validation while a separate rolling window fully validates three scripts at a time.

- Active-script assets are cached in RAM, and Undo is identity-bound without reloading the complete script.

- Script Library, Asset Library, and Recycle Bin now use retained keyed projections with hierarchical folders and one storage-write authority.

- Red-X shutdown was rebuilt. Normal activity stops immediately, accepted writes receive one bounded drain, and only the idle permission holder remains.

- Non-MainOverlay surfaces now open on demand as application overlays with pass-through touch, minimal focus capture, responsive sizing, and split-screen support.

- Editor Selector now has deterministic permission returns, mode-specific hosts, UI Element selection, two-second updates, and two-app split-screen lists.

- Major command paths were corrected, including ReTap, TouchDown/TouchMove, gestures, ImgFind, PixelFind, GetPixelColor, generated Result/Baby-IF blocks, duplication, moves, and Test returns.

- Bridge, Cloud, imports/exports, assets, Run Logs, shortcuts, AI contracts, and website documentation were expanded and tightened.

The public command catalog remains at 68 commands. Code 16 is mainly about making those commands and the systems around them behave consistently.

The practical goal is simple:

Editing should not require full reloads.

Play should consume the exact active script already in RAM.

Validation should update only what changed.

The Main Overlay should remain responsive.

Accepted work should become durable without blocking the UI.

Closing ScriptTap should stop normal activity cleanly.

ScriptTap remains in beta. The next priority is real-world stability testing before any production application.

If you test Code 16, the most useful areas to exercise are editing and reopening commands, Play/Stop cycles, split-screen selector workflows, Library folders, imports/exports, and Run Logs.

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

The app lets people build 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, and I do not want to minimize it or hide behind vague onboarding copy.

I’m trying to explain it clearly:

- 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 what they are enabling.

My question for other founders:

How would you explain a powerful permission honestly without scaring away every normal user?

I am not looking for fluffy marketing language. I am trying to find the clearest version of the truth that still helps people understand the product.