[Roadmap] Android Studio plugin: in-IDE task dispatch, device debugging, and test recording

[RanjithRagavan]

Summary

Feature request tracking the roadmap item Android Studio Integration (README §Roadmap): a native IDE plugin that brings ARTEMIS's on-device automation into Android Studio — in-editor test dispatch, live device perception, debugging, test recording, and replay — so developers can drive and inspect real devices without leaving the IDE.

Motivation

Today ARTEMIS is reachable through four surfaces: the Web Console (artemis ui), the CLI (artemis run), the MCP server (for AI coding assistants), and the Python SDK (artemis-client). Android app developers, however, spend their day in Android Studio, which already owns the device lifecycle (AVD Manager, device dropdown, Logcat, layout inspector). An IDE-native integration would:

• Remove context switching: write a natural-language test next to the code it tests, run it against the same device Android Studio already manages.
• Reuse the IDE's device/AVD plumbing instead of requiring a separately attached ADB session.
• Make agent runs debuggable: correlate agent steps (screenshots, hierarchy, taps) with app logs and breakpoints in one window.
• Lower the barrier for QA engineers who are not CLI-first users, broadening adoption of the project.

Proposed scope (phased)

Phase 1 — Companion tool window (MVP)

• IntelliJ-platform plugin (works in Android Studio Hedgehog+; Kotlin, Gradle IntelliJ Plugin).
• Tool window embedding a task dispatch panel that talks to a running ARTEMIS server via the existing artemis-client HTTP API (task submit, status polling, trace view) — no agent logic reimplemented in the plugin.
• Device picker synchronized with Android Studio's selected device/AVD (pass the serial through, like ArtemisClient(device_serial=...)).
• Run results rendered in the IDE: step timeline, screenshots, final structured report; failures deep-link to Logcat.

Phase 2 — Editor & debugging integration

• Run configurations: "ARTEMIS Task" run type with before-run "build & install APK" steps, so a task can target the just-built variant.
• Line-marker / gutter action to generate or run a UI test prompt for the current screen/Activity.
• Breakpoint-aware runs: pause agent execution when the app hits a selected breakpoint, resume after inspection.

Phase 3 — Recording & authoring

• Record mode: capture manual interactions (taps/types on the mirrored device) and emit a natural-language or structured ARTEMIS task draft.
• Replay comparison: side-by-side diff of two execution replays (already produced by the Web Console) inside the IDE.

Architecture notes

• The plugin should be a thin client: all perception, planning, and device control stay in the ARTEMIS server; the plugin consumes the same API as packages/artemis-client and the MCP server (mcp_server/), keeping the agent surface single-sourced.
• Distribution via JetBrains Marketplace; source could live under apps/ (alongside the existing console app) or a sibling android-studio-plugin/ directory.
• No new credentials surface: reuse the server's existing config; the plugin only needs the server base URL and optional device serial.

Acceptance criteria (Phase 1)

• Installable plugin (Marketplace or .zip) targeting recent Android Studio versions
• Tool window: dispatch a natural-language task to a user-configured ARTEMIS server and show live status
• Device selection follows the IDE's active device; serial is passed to the server
• Completed runs display step timeline + screenshots + final report inside the IDE
• Docs: setup page covering server startup (artemis ui / headless), plugin install, and a first-task walkthrough

Happy to help spec the plugin API surface against artemis-client if maintainers want a design doc first.

[RanjithRagavan]

Phase 1 MVP implemented in #153 — thin-client tool window (device picker, task dispatch via POST /api/run, live polling, stop), settings page, 25 tests, compatible with Android Studio Hedgehog+ (since-build 231, no until-build cap). Phases 2–3 (run configurations, breakpoint-aware runs, record mode) left as follow-ups per the scope above.