The Evolution and Architecture of Remote Real‑Device Debugging

Origin : Early remote debugging on cloud‑phone platforms relied on simple ADB TCP connections where the phone and development machine shared the same network.

Prototype : Introduced TCP‑based ADB connections and unified network environments.

Innovation : Adopted STF adbkit proxy, simulated ADB server, and cross‑network communication to overcome network isolation.

Application : Modern cloud‑phone services now provide remote debugging capabilities to end users.

Platform Requirements

Separated deployment: phone and web server have different hardware and network constraints.

Permission verification: users obtain exclusive remote‑debug rights for rented devices; rights are revoked upon release.

High performance: IDE debugging demands low latency; separation adds complexity.

Security monitoring: elevated user privileges require safeguards against malicious actions.

Implementation Method

Separated deployment: two services – one on the web server handling user ADB connections, another on the phone server executing ADB commands; ZMQ proxy on the web side enables bidirectional data transfer.

Permission verification: temporary keys are issued per rental; ADB connect triggers an auth step; keys expire when the device is released.

High performance: Golang implements the ADB connection service and command execution; ZMQ handles message forwarding.

Security monitoring: interaction data is analyzed for safety.

Architecture Diagram : (image illustrating the overall system layout).

Technology Stack : (image showing components such as Golang, ZMQ, ADB, STF, etc.).

Protocols

ADB protocol definitions from protocol.txt (CNXN, AUTH, OPEN, WRTE, OKAY, CLSE, SYNC) and service definitions from services.txt (OKAY, FAIL, …). OpenSTF’s adbkit source (npm dependency ^2.7.1) is referenced.

ADB Protocol Explanation : Client and server communicate via service.txt ; device and daemon communicate via protocol.txt , with the server acting as a proxy.

General Remote Debugging Solution

Proxy mediates data between client and server.

Proxy handles client connections and command forwarding.

Proxy connects to the local server, establishing a socket channel to forward commands (OPEN, WRTE, OKAY, CLSE) to the device.

Updated Architecture After Changes

proxy_cnxn maintains ADB connection (CNXN, AUTH).

ZMQ routes connection and command data.

proxy_command forwards commands to the phone.

ZMQ Architecture Design : (image of ZMQ message flow).

ZMQ Message Format : (image showing the frame structure).

Golang Functions to Implement

TCP server replicating full ADB server logic based on adbkit source and packet captures.

ZMQ communication for separating connection and command services.

Leveraging Go’s concurrency (goroutine, channel) for real‑time debugging.

Integration as micro‑services communicating with the web layer.

Golang TCP Server : (diagram of server architecture).

Golang ZMQ Proxy : (diagram of proxy component).

Golang ADB Service : (diagram of service handling ADB commands).

Security Monitoring : (illustration of monitoring mechanisms for device interactions).

Demo : Animated GIF showing the remote debugging workflow, with a note that the GIF may need to be saved to a device for clearer viewing.