Droidline: Two Commands, No USB or Root, to Drive Real Android Phones from Anywhere
Droidline removes the physical tether from mobile automation: no USB cables, no ADB configuration, and no root, which lowers the barrier for real-device regression testing. For teams already invested in Appium, the tool's real value is its architecture—single-source spec generation and a phone-outbound, encrypted connection model that are worth copying regardless of whether you adopt the tool.
Droidline, open-sourced on October 7, 2026, by Korean developer KnifeLemon, turns a real Android phone into a remotely drivable test device. The phone runs a normal app with an accessibility service and a custom keyboard; the PC runs a Go-based server. Pairing happens via a QR code or a 6-digit code, and the phone initiates the outbound connection, so the PC needs no open ports. Communication is end-to-end encrypted, and relay servers only see ciphertext.
The tool offers a spec-driven design: a single `commands.json` file generates the Python, Node.js, and .NET SDKs plus the MCP tool list, keeping interface names consistent. It supports element-based automation via `dump()` and commands like `touch` and `input`, with built-in waiting and page-level error messages. One PC can control many phones in parallel, each with its own proxy. MCP integration lets AI agents like Claude and Cursor interact with a real screen. The README also lists limitations: no PIN unlock, no force-stop or clear-data commands, and coordinate-only fallbacks for games and custom UIs.
The single-source spec generating five entry points is a practical answer to the common pain of keeping multi-language SDKs in sync; it makes the tool's interfaces consistent by construction and reduces documentation drift.
Reversing the connection direction (phone dials out) is a clean security model for a mobile tool; it means no port forwarding, NAT traversal, or firewall holes, and it makes end-to-end encryption meaningful even when a relay is involved.
The strict permission boundary—only accessibility service and a custom keyboard—is what keeps the tool usable on ordinary phones, but it also sets a hard ceiling: any UI that doesn't expose accessibility elements is only partially automatable.
The emphasis on documenting what the tool cannot do in the README is a good proxy for engineering maturity in an early-stage project; it helps set realistic expectations for testing teams that might otherwise assume a pure no-root solution is a full Appium replacement.
The element tree has a premise: the dump only gets anything when the app is willing to report its UI to the accessibility service. On the same screen I measured two extremes in practice: normally 200+ nodes, but after one tap it became 0. It wasn't that the permission was missing — that window had the anti-screenshot flag set, so the element tree and the screenshot went empty together, and force-stop didn't restore it; the only fix was clearing data and logging in again. So "locating by text/id instead of coordinates" is rock-solid in system settings and your own apps, but once you enter mini-programs, Flutter self-drawn UIs, or a locked window like the one above, you have to fall back to screenshot-plus-vision, and the screenshot is black in those windows. When both paths die at the same time, that page simply can't be tapped that day; all you can do is honestly report that the screen can't be obtained. The fakephone emulator won't give you the 0-node case, so adding this scenario on a real device is more valuable.