ScriptTap has moved from Google Play closed testing to a public open beta. The current public build is Code 20.
That milestone did not come from adding one final headline feature. It came from rebuilding the parts users normally notice only when they fail: state ownership, persistence, lifecycle closure, rotation, imports, and permission handling.
ScriptTap is a no-root Android automation app. Users create scripts that can perform taps and gestures, inspect visible UI states, use OCR and image or pixel checks, work with variables and conditions, and run through overlays, routines, and shortcuts.
That combination makes ordinary Android lifecycle and state-management mistakes visible very quickly.
One authority is better than synchronized copies
One of the largest changes was moving the Script Library, active Editor, and running script state around one canonical authority.
Other screens now work from stable IDs and retained projections instead of maintaining competing copies of the same script data.
The practical lesson was simple: synchronization code is often evidence that ownership is unclear. Removing extra owners eliminated entire categories of refresh, selection, and stale-state problems.
RAM first, persistence second
Normal user actions now update resident state immediately.
Persistence receives immutable work through one background writer queue. The UI does not wait for storage, and the writer does not call back into UI state.
This separation made the app feel more responsive, but the larger benefit was predictability. A user action has one immediate RAM result and one ordered persistence path.
Closing has to be real lifecycle behavior
Floating Android applications make “close” more complicated than hiding a window.
ScriptTap’s close path now stops ordinary activity immediately, gives the writer one bounded drain, removes active overlays, and leaves only the idle permission holder running.
This became an important rule during testing: if a user closes the active application surface, no visible or mutating work should continue afterward.
Rotation can become a data-correctness problem
For screen-aware automation, rotation is not merely a layout event.
Screen-capture sessions need to survive valid configuration changes, while scripts containing literal coordinates must not run against the wrong orientation.
Recent builds added orientation protection for existing scripts and coordinate transposition during supported imports. This keeps a portrait-authored workflow from silently becoming incorrect when imported or opened under a different orientation.
Import compatibility should fail selectively
Script packages may come from older builds, newer builds, cloud storage, or another device.
Rejecting an entire package because one newer command is unsupported is unnecessarily destructive. The importer can now preserve compatible content while allowing unsupported newer commands to be skipped deliberately.
Compatibility is more useful when the boundary is explicit and narrow.
Powerful permissions need concrete explanations
No-root input automation depends on Android Accessibility. Screen-aware commands may separately request Android screen capture.
Those permissions should not be described as harmless, but vague warnings are not useful either. The explanation needs to state:
- why the permission is needed
- what user-created scripts can do with it
- which capabilities are separate
- what ScriptTap does not bypass
- when the user should decline
Closed testing reinforced that trust is not produced by softer wording. It comes from specific behavior and specific boundaries.
What public beta means
Open beta does not mean the application is finished or proven stable across every Android device.
It means anyone can now install it without joining a tester group, and the next phase can focus on broader device behavior, onboarding clarity, real automation workflows, and the failures that only appear outside a controlled tester pool.
For developers working on stateful Android apps: which caused more trouble in practice—state ownership, persistence ordering, configuration changes, or lifecycle shutdown?
Disclosure: I used an AI assistant to help organize and edit this article. I reviewed the technical claims and stand behind them.
Top comments (0)