What closed testing changed in my Android automation app

Roman Rashkovskiy — Thu, 20 Aug 2026 15:55:47 +0000

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.

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

Roman Rashkovskiy — Sun, 21 Jun 2026 00:20:13 +0000

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?

DEV Community: Roman Rashkovskiy