The Evolution and Architecture of Remote Real‑Device Debugging

Origin

Remote debugging capabilities were introduced on cloud‑phone platforms to allow developers to test and debug applications on real devices without physical access.

Prototype

The initial prototype relied on ADB TCP connection mode, requiring the phone and development machine to share the same network.

Innovation

Subsequent innovation added an STF‑based adbkit proxy, simulated ADB server, and cross‑network support, enabling more flexible remote debugging.

Application

Various cloud‑phone services now provide remote debugging as a standard feature for developers.

Platform Requirements

Key requirements include separated deployment (different hardware and network constraints for phones and web servers), strict permission verification (unique per‑user remote‑debug keys), high performance for IDE interaction, and robust security monitoring to prevent malicious device manipulation.

Implementation Approach

Remote debugging services are split into two parts: a web‑server component handling user ADB connections and a phone‑server component executing ADB commands. A ZMQ proxy on the web server enables bidirectional data transfer. Permission verification uses temporary keys that become invalid when a user releases a device. High‑performance Go services manage ADB connections, command execution, and message routing via ZMQ. Security monitoring analyses interaction data for potential abuse.

Architecture Diagram

Technology Stack

Protocols

ADB protocol (protocol.txt) defines messages such as CNXN, AUTH, OPEN, WRTE, OKAY, CLSE, SYNC. Service definitions (services.txt) include OKAY, FAIL, etc. The open‑stf adbkit library (npm package "adbkit" ^2.7.1) provides a Node.js implementation.

ADB Protocol Explanation

Clients (C) and servers (S) communicate via the service.txt protocol, while servers (S) and devices (D) use the protocol.txt protocol, with the server acting as a proxy to forward data between client and device.

General Remote Debugging Solution

1. A proxy mediates data between client and server. 2. The proxy handles client connections and forwards commands. 3. The proxy connects to the local server, establishing a socket channel to forward client commands to the server.

Post‑Change Architecture Diagram

ZMQ Architecture Design

ZMQ Message Format

Golang Functions to Implement

Based on adbkit source and captured ADB traffic, implement a full ADB server in Go, using ZMQ for communication, leveraging Go’s concurrency (goroutine, channel) for real‑time performance, and expose the service as a microservice interacting with the web layer.

Golang TCP Server

Golang ZMQ Proxy

Golang ADB Service

Security Monitoring

Demo