{"type":"session_started","session_id":"...","started_at":"..."}
{"type":"screen_snapshot","session_id":"...","state":{"captured_at":"...","element_count":18,"elements":[...]}}
{"type":"command_result","id":"2","command":"tap_text","ok":true} Android automation that leaves evidence.
Luotsi keeps the control loop on your machine: inspect real Android devices, run governed scenarios, and replay failures from durable artifacts after the session ends.
$ luotsi inspect --device pixel-lab-3
session: real-device JSONL
actions: tap_text, wait_visible, screenshot
$ luotsi replay packet --artifacts ./artifacts/smoke-run
packet: run-summary.json, run-summary.md
next: focused triage command
artifact_root: ./artifacts/smoke-run
guide: replay packet writes run-summary.json and run-summary.md
next: luotsi replay packet --artifacts ./artifacts/smoke-run Three questions the tool has to answer.
Luotsi is useful when the answer needs to be a machine-readable device session and a durable artifact trail, not just a live screen or a pass/fail bit.
Can my agent inspect and act on a real Android device?
Yes. Start an inspect session, read JSONL screen snapshots and deltas, then send JSON commands such as wait_visible, tap_text, type_text, screenshot, and exit over stdin.
luotsi inspect --device <serial> Open the agent loop example -> Can CI run this and leave useful evidence?
Yes. Run scenario playbooks from the host, claim lab devices when needed, and keep JSON reports, JUnit, screenshots, hierarchy captures, logcat, telemetry, and governance signals under one artifact root.
luotsi run --path scenarios --device <serial> --report-junit junit.xml Open CI device lab workflows -> Can I debug the failure after the device is gone?
Yes. Replay commands read saved artifacts, summarize the run, build capsules, scrub timelines, query semantic graphs, cluster repeated failures, and draft follow-up scenarios.
luotsi replay packet --artifacts ./artifacts/<run-id> Open replay and artifacts -> Get to a real device workflow in five minutes.
Install from releases, run doctor once, then jump into the workflow that matches the job.
Run the release installer, then let doctor verify the device path before you burn time on setup drift.
iex (irm https://github.com/digablesolutions/luotsi/releases/latest/download/luotsi-install.ps1)
luotsi doctor --device <serial> --fix Use the shell installer, then validate the same first-run path against the attached device.
curl -fsSL https://github.com/digablesolutions/luotsi/releases/latest/download/luotsi-install.sh | sh
luotsi doctor --device <serial> --fix Run the environment check before you spend time on adb, helper, or decoder edge cases.
luotsi doctor --device <serial> --fix - Verifies adb visibility and device readiness.
- Checks live-view prerequisites.
- Stages helper and decoder assets Luotsi owns when possible.
Pick the route that matches the job.
Once a device is attached, most work falls into one of these three paths.
luotsi inspect --device <serial> luotsi run --path scenarios --device <serial> luotsi replay packet --artifacts ./artifacts/<run-id> Docs organized by intent, not by dump.
Start from the bucket that matches the moment: setup, run, or debug.
Get from install to a stable device session before you debug the app.
Choose the surface that matches the job: operator control, structured exploration, or repeatable runs.
Start from the page that matches the evaluation question or workflow you are trying to standardize.
Use the artifact layer and command surface when the question is no longer just how to start.