Android CI Device Lab Workflows

If you are looking for Android CI device lab workflows, Luotsi fits when the same CLI needs to work on an engineer laptop, a shared lab host, and CI, with explicit device readiness, scenario execution, and replay artifacts instead of one-off scripts.

What changes in CI and labs

Device readiness is explicit rather than implied.
Scenario validation and execution use the same JSON playbook format as local runs.
Reports, JUnit output, screenshots, and replay artifacts survive the pipeline run.
Lab allocation and shared operations can stay in the same public model as the rest of the tool.

Recommended workflow

luotsi doctor --device <serial>
luotsi scenario-validate --path scenarios
luotsi run --path scenarios --device <serial> --report-junit junit.xml
luotsi replay packet --artifacts ./artifacts/<run>
luotsi replay packet --artifacts ./artifacts/<run> --check

Use replay packet as the CI handoff preview: it writes the At a Glance summary, failure snapshot, packet gate, primary failure, recommended next action, and first-minute commands without trying to launch a browser on the runner. Use replay open --dry-run when a human also needs the replay front door response. When the workflow depends on a shared device pool, pair this with Lab And Device Claims and Shared Lab Operations.

Portable CI workflow pack

For CI/CD, start from the Portable Physical Lab CI workflow pack. It keeps the device-lab contract in reusable Bash and PowerShell scripts, then layers a GitHub Actions workflow over those scripts.

That means the same run path can work in:

GitHub Actions self-hosted runners
GitHub Actions-compatible CI systems
generic CI jobs that can run shell or PowerShell
Docker jobs that connect to host adb or adb-over-TCP devices

The default Docker model is host ADB rather than privileged USB passthrough. The CI job owns the process, Luotsi owns the device claim, and replay artifacts remain the handoff point for humans and agents.

Strong fit when

Your CI pipeline already has adb access to physical devices.
You want the same artifact model locally and in automation.
You need shared-lab semantics instead of each job inventing its own device locking scheme.
You want failures to leave a triage trail instead of only console output.

Weaker fit when

Your main need is emulator-only smoke testing with no artifact or replay expectations.
A hosted device farm already dictates the automation contract and orchestration model.
You do not need shared-lab coordination, replay, or structured output contracts.