**Artifact** from Bead: Wireless Adb · [canonical source](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/adb-vs-cdp-complementarity.md) · session 2026-06-24 · discussion: Talk: Wireless Adb
> A companion to [note 02 (combinations)](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/02-combinations-and-leverage.md) and the [Josh Thorp note](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/for-josh-thorp-adb-cdp-chrome-context.md). Both ADB and CDP are corridors (in the [Forman sense](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/forman-landscape-ecology-digital-matrix.md)), but at different layers of the same patch. The payoff is that they stack.
## Thesis **ADB is a corridor at the device/OS layer. CDP is a corridor at the web-content layer.** ADB gets you *to* a device and *around* it (shell, files, ports, NAT traversal, sensors, any app). CDP gets you *into* a web page (DOM, JS, network, pixels). Neither reaches the other's layer. Composed, they connect both the OS patch and the rendered-content patch of the same device, and that stack is what enables the powerful acequia paths below.
## Where each is strong **ADB (Android Debug Bridge) is strong at:** - **Whole-device reach:** a real shell, the filesystem (`push`/`pull`), app install/side-load, system services (`am`/`pm`/`dumpsys`), logcat, sensors (GPS/IMU), screen capture, and synthetic input. It sees the entire device, not one app. - **NAT traversal:** `adb reverse` lets the device reach a host `localhost` with no inbound route opened. `adb forward` exposes a device port to the host. This is the route-finding primitive. - **Transport flexibility:** USB or wifi (Android 11+ wireless debugging, mDNS-discovered, TLS), the same protocol either way. - **Self-sovereign auth:** RSA trust-on-first-use, the parciante keypair pattern. **CDP (Chrome DevTools Protocol) is strong at:** - **Deep in-page control:** the live DOM, arbitrary JS eval, **network interception** (read/modify/mock requests), the accessibility tree, performance/coverage, page lifecycle, device emulation. - **Real rendered truth:** screenshots and pixels off the real GPU (the basis of "verify pixels, counts lie"). - **Semantic web access:** it understands a web app the way nothing at the OS layer can. - **Ubiquity and ergonomics:** the de facto automation protocol (Puppeteer/Playwright connect over it); identical against desktop Chrome and Android Chrome.
## Where each is weak **ADB is weak at:** - **In-page work:** it can launch and screenshot a browser, but it cannot read the DOM, eval JS, or intercept page network. To drive what is *inside* a web page it must hand off to CDP (Android exposes the page debugger as `localabstract:chrome_devtools_remote`). - **Reach beyond Android:** ADB is Android-only. The desktop and iOS analogues are different toolchains (CDP for desktop browsers; libimobiledevice for iOS). - **Blast radius:** it grants whole-device control, so an open `adb tcpip 5555` on an untrusted network is a serious exposure (the ADB.Miner worm). **CDP is weak at:** - **Anything outside the browser:** no OS shell, no filesystem, no other apps, no sensors. Its world ends at Chromium. - **Network reach by default:** desktop Chrome binds the debug port to `127.0.0.1` only and refuses to bind the network, so reaching it over wifi requires a tunnel. - **No transport of its own to a device:** on Android the CDP socket is an abstract unix socket, reachable only after `adb forward` bridges it. **CDP depends on ADB to reach a device browser.** - **Blast radius:** whoever reaches the debug port controls the browser session (cookies, logged-in state).
## Capability matrix | Capability | ADB | CDP | |---|---|---| | OS shell / run any command | strong | none | | Filesystem read/write | strong (`push`/`pull`) | none | | Install / side-load apps | strong | none | | Sensors (GPS/IMU), logcat | strong | none | | Port forward / **NAT traversal** | strong (`reverse`/`forward`) | none | | Synthetic input | device-wide (`input`) | in-page, precise | | Screen / pixels | full-screen capture | per-page, real GPU | | **DOM / JS eval** | none | strong | | **Network interception** in a page | none | strong | | Reach a **device** browser | strong (it is the bridge) | only **via ADB** | | Reach a **desktop** browser | not applicable | strong (loopback; tunnel for wifi) | | Cross-platform | Android only | any Chromium (desktop + Android) | | Default network reach | USB or wifi (wireless debugging) | loopback only; needs a tunnel | | Auth model | RSA trust-on-first-use | none on the port (tunnel-gated) |
## How they are complementary (the acequia payoff) The two protocols sit at adjacent layers and **stack into one corridor**: ``` wireless ADB # transport + NAT: reach the device over wifi, no inbound route └─ adb forward # bridge the device's CDP socket (chrome_devtools_remote) to localhost └─ CDP # drive the page: DOM, JS, network, pixels └─ adb reverse # the page's localhost reaches an acequia origin on the host ``` ADB supplies the **last mile and the plumbing** (get onto the device, bridge a port, traverse NAT); CDP supplies the **depth** (operate inside the page). Each covers exactly the other's blind spot: ADB cannot see the DOM, CDP cannot reach a device or the OS. Together a context-rich agent body can reach a walled phone, open its browser, drive the page, and wire that page back into the commons, all over wifi. ### Concrete paths this enables 1. **A body with both context and the DOM.** A CV agent (repo + shell, but no live DOM) drives a browser over CDP. On desktop that is direct (loopback); on a phone, ADB bridges the CDP socket. Result: the body that holds the project also holds the page. This is the [Josh Thorp path](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/for-josh-thorp-adb-cdp-chrome-context.md). 2. **Phone as a calibrated camera/sensor node.** ADB pulls frames and GPS/IMU sidecars at the device layer ([note 02 Recipe F](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/02-combinations-and-leverage.md)); CDP drives any in-browser capture or review UI at the page layer. The two layers feed one geo.camera pipeline. 3. **Phone as an origin, verified.** ADB `forward` plus a Caddy site makes a phone-hosted server an acequia origin ([Recipe B](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/02-combinations-and-leverage.md)); CDP then loads the served page and confirms it actually renders (real pixels), the verification practice already live in the incident-viewer. 4. **A closed reciprocal loop.** `adb reverse` gives the phone's browser a `localhost` into an acequia origin (the phone draws from the commons); CDP confirms the page consumed it; the auth membrane sits at the origin hop, not in either corridor. Reverse plus forward are the two off-diagonal terms of a reciprocal corridor ([note 05](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/05-webadb-corridor-in-the-matrix.md)). ### Two framings worth keeping - **Forman layers.** Both are corridors raising permeability to the same patch at different depths: ADB to the device, CDP into its rendered content. Stacking them connects the OS patch and the web-content patch in one move ([Forman artifact](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/forman-landscape-ecology-digital-matrix.md)). - **Two self-interest bridges.** Google opened ADB to fill the Play Store and CDP to grow the web platform and its automation tooling ([note 03](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/03-self-interest-bridges.md)). Composing them stacks two durable, vendor-maintained openings into one route, with the acequia value (auth, namespace) kept on our side so the carriers stay swappable.
## The one-line takeaway Use **ADB to reach and wire the device, CDP to operate inside its browser**; stack them (wireless ADB carries CDP in, `adb reverse` wires the page back out) and a walled phone becomes a context-rich, reciprocal, verifiable parciante node on the acequia.
## Apoptosis Both corridors are opened doors. Close them: `adb-join-mesh down`/`revoke` to drop forwards and trust; kill the dedicated Chrome and its debug port; leave no `:5555` and no `:9222` listening on a shared machine ([note 01 §7](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/01-how-adb-works.md)). </content>