| name | iterating-on-voltius-android-emulator |
| description | Use when building, deploying, running, screenshotting, clicking through, or debugging the Voltius Tauri app on a headless Android emulator running in Docker (no physical phone) — drives the in-container x86_64 emulator through the tauri-android MCP (adb + Chrome DevTools Protocol) so changes are seen and interacted with, not just compiled. |
Iterating on Voltius Android (Docker emulator)
Overview
No phone, no cable. A headless x86_64 Android emulator runs in Docker (Dockerfile.android-emulator),
and the tauri-android MCP runs inside the same container via docker exec, so adb is local —
none of the real-phone Windows-firewall / ADB_SERVER_SOCKET pain applies. Same MCP, same tool names,
same selector rules as the on-device flow (iterating-on-voltius-android); only the transport differs.
Use this for fast no-device iteration / CI. Use the real-phone skill when a feature depends on actual
hardware (real keychain, USB serial, camera) — the emulator's sandbox still differs from a real device,
so a cross-compile or an emulator pass is not proof a feature works on real hardware. The proof is
still: drive it, read the screenshot, check logcat.
Requires /dev/kvm (KVM accel — verified on x86_64 WSL2). The MCP itself needs no changes: it is
device-agnostic (ANDROID_SERIAL selects the target, adb is local, CDP host defaults to 127.0.0.1).
Arch: the Dockerfile and the orchestrator both pick the ABI from the build host's uname -m —
x86_64 host → x86_64 image + x86_64 APK; ARM host → arm64-v8a image + aarch64 APK. KVM only
accelerates a same-arch guest, so the ABI must match the host. On ARM-WSL2 two things are unverified
(check on that box): ls /dev/kvm must exist (Windows-on-ARM nested-virt exposure is less mature), and
must pull a working linux-aarch64 emulator host binary.
