View on GitHub

scrcpy-gui

👻 A simple & beautiful GUI application for scrcpy.

Advanced automation proposal (#222)

This is the implementation plan for #222, not a list of shipped features. Keep the issue open until the phases below have separately passed their acceptance criteria.

Current behavior

The GUI launches scrcpy in a separate native window. Record actions records GUI control-panel actions, not native-window mouse or keyboard input. The workflow editor and runner already support manually authored normalized taps, swipes, non-sensitive text, app launch, screenshots, delays, controls, and device assertions. Batch file push exists separately from workflow steps. Workflow imports are untrusted previews; arbitrary shell execution is rejected.

1. Record screen interactions

First choose an explicit input-capture surface. The current separate scrcpy window provides no DOM pointer or keyboard events to the GUI; adding renderer event listeners cannot record its interactions. Investigate upstream integration or an opt-in GUI capture surface before promising native-window recording. Avoid global input hooks that also capture unrelated desktop applications.

Acceptance criteria:

2. Per-run string variables

Add bounded string assignment and substitution with explicit errors for missing names. Isolate values by run and device so concurrent batches cannot share data. Imported workflows must not inherit prior run values.

Clipboard capture needs a separate design decision: clipboard synchronization with scrcpy is not equivalent to reading selected Android text. Specify supported data sources and require explicit user action for host clipboard access. Do not imply that arbitrary Android app text is readable.

Acceptance criteria:

3. Workflow upload and download

Reuse the existing device/file validation and selected-file handling for upload. Add an explicit pull operation with a user-selected destination. Bind host paths locally rather than trusting paths from imported workflows, and define variable substitution before allowing it in transfer paths.

Acceptance criteria:

4. Local command execution

This introduces host execution into an engine that currently rejects shell commands. Keep it a separately reviewed capability with local executable selection and an argv array; never build a shell command from variable values. The renderer must continue to use guarded typed IPC.

Acceptance criteria:

Each phase should ship in a focused PR with schema/validation, runner, typed preload API, UI, documentation, and behavior tests as applicable. Native-window recording and Android clipboard capture still need feasibility evidence; neither is implied by the existing action recorder.