Before submitting
Area
apps/desktop
Problem or use case
When developing an Android, IOs or React Native application, I cannot view or interact with the running app inside T3 Code.
The browser preview supports web applications, but mobile development requires switching between T3 Code, Android Studio, and a separate emulator window. The coding agent also cannot inspect the current Android screen or perform basic interactions to verify its changes.
I want to launch or attach to an Android emulator as well ios emulator if possible and see its screen inside T3 Code, and allow the agent to perform controlled interactions such as taking screenshots, tapping, swiping, typing, and pressing Android navigation buttons, for automated testing
Proposed solution
Add an Android device preview surface alongside the existing browser preview.
The desktop application would:
- Discover connected Android emulators and devices through ADB.
- Allow selecting or starting an Android Virtual Device.
- Display the device screen inside the preview panel using a low-latency stream, potentially through scrcpy.
- Forward mouse and keyboard input as taps, swipes, text input, and Android key events.
- Support common actions such as Back, Home, rotate, reload/relaunch app, screenshot, and opening Logcat.
- Preserve the selected device and preview state across client reconnects where possible.
Expose a small set of agent-facing operations, either through the existing preview automation infrastructure or an internal mobile automation service:
- List and select devices.
- Capture a screenshot and structured UI hierarchy.
- Tap or long-press coordinates or UI elements.
- Swipe and scroll.
- Type text.
- Press Back, Home, Enter, and other supported keys.
- Launch or stop an application by package name.
- Wait for a UI element or text to appear.
Existing projects such as Mobile MCP or Appium MCP could be evaluated for automation behavior, but the human-facing preview and emulator lifecycle should remain owned by T3 Code rather than requiring an external MCP server.
Why this matters
This would make T3 Code useful for end-to-end Android and React Native development instead of limiting integrated verification to browser applications.
Developers could remain in one workspace while building, viewing, and testing mobile changes. Agents could also verify UI changes directly rather than relying on the developer to manually describe the emulator state or provide screenshots.
The same internal abstraction could later support physical Android devices and a separate macOS-only iOS Simulator implementation.
Smallest useful scope
An Android-only first version that supports one already-running local emulator.
The minimum useful version would:
- Detect an emulator through ADB.
- Show its screen in a T3 Code desktop preview panel.
- Forward taps, swipes, typing, Back, and Home.
- Capture screenshots for agent inspection.
- Launch an application by package name.
Starting and creating AVDs, physical-device support, Logcat integration, structured UI inspection, recording, multiple devices, and iOS support can follow later.
Alternatives considered
The agent can currently use ADB commands to interact with an Android device. However, this is slow because each interaction requires separate commands for inspecting the screen and performing an action. On real devices, these commands also frequently fail or do not produce the expected result, making the workflow unreliable.
Using Android Studio with a separate emulator window works for manual development, but the agent cannot directly inspect or reliably interact with it.
An external MCP server such as Mobile MCP or Appium MCP could provide more reliable mobile automation, but T3 Code would still need an integrated preview and lifecycle management.
Risks or tradeoffs
- Android emulators consume significant CPU, memory, and disk space, so concurrent emulator instances should be limited.
- T3 Code must supervise emulator, ADB, and streaming processes and clean them up after crashes or shutdowns.
- Video decoding and input forwarding need to remain responsive without affecting conversation rendering.
- Input coordinates must account for scaling, orientation changes, system bars, and device resolution.
- Arbitrary ADB shell access should not be exposed directly to the renderer or agent without validation.
- Physical devices require explicit authorization and should not be controlled accidentally.
- Windows, macOS, and Linux have different Android SDK discovery and virtualization requirements.
- External projects may be useful references, but depending on them directly introduces versioning, security, and lifecycle risks.
Examples or references
Contribution
Before submitting
Area
apps/desktop
Problem or use case
When developing an Android, IOs or React Native application, I cannot view or interact with the running app inside T3 Code.
The browser preview supports web applications, but mobile development requires switching between T3 Code, Android Studio, and a separate emulator window. The coding agent also cannot inspect the current Android screen or perform basic interactions to verify its changes.
I want to launch or attach to an Android emulator as well ios emulator if possible and see its screen inside T3 Code, and allow the agent to perform controlled interactions such as taking screenshots, tapping, swiping, typing, and pressing Android navigation buttons, for automated testing
Proposed solution
Add an Android device preview surface alongside the existing browser preview.
The desktop application would:
Expose a small set of agent-facing operations, either through the existing preview automation infrastructure or an internal mobile automation service:
Existing projects such as Mobile MCP or Appium MCP could be evaluated for automation behavior, but the human-facing preview and emulator lifecycle should remain owned by T3 Code rather than requiring an external MCP server.
Why this matters
This would make T3 Code useful for end-to-end Android and React Native development instead of limiting integrated verification to browser applications.
Developers could remain in one workspace while building, viewing, and testing mobile changes. Agents could also verify UI changes directly rather than relying on the developer to manually describe the emulator state or provide screenshots.
The same internal abstraction could later support physical Android devices and a separate macOS-only iOS Simulator implementation.
Smallest useful scope
An Android-only first version that supports one already-running local emulator.
The minimum useful version would:
Starting and creating AVDs, physical-device support, Logcat integration, structured UI inspection, recording, multiple devices, and iOS support can follow later.
Alternatives considered
The agent can currently use ADB commands to interact with an Android device. However, this is slow because each interaction requires separate commands for inspecting the screen and performing an action. On real devices, these commands also frequently fail or do not produce the expected result, making the workflow unreliable.
Using Android Studio with a separate emulator window works for manual development, but the agent cannot directly inspect or reliably interact with it.
An external MCP server such as Mobile MCP or Appium MCP could provide more reliable mobile automation, but T3 Code would still need an integrated preview and lifecycle management.
Risks or tradeoffs
Examples or references
https://developer.android.com/studio/run/emulator-commandline
https://github.com/Genymobile/scrcpy
https://github.com/mobile-next/mobile-mcp
https://github.com/appium/appium-mcp
https://github.com/jduartedj/android-mcp-server
Contribution