Android ADB engine
Owns the ADB transport: the server, the devices it talks to, and the pair/connect state between them. Everything else in the Android Control system rides on top of this layer, so establish a verified connection before driving any device.
When to use
- Device not appearing, ADB server stale, or authorisation prompt handling.
- Pairing a new device or re-establishing a dropped transport.
- Starting any Android automation flow (entry point for transport readiness).
- Verifying that a connection is real before UI / input / file work.
Tools used (name matched to the Android Control MCP server)
list_devices— current ADB device list with serial and state.discover— scan for connectable devices (USB / Wi-Fi / emulator).connect— open a transport to a discovered device (pair when required).disconnect— close the transport to a device.reconnect— tear down and re-establish a transport (first recovery step).status— live state of the transport and the device.verify— end-to-end probe that the transport is usable (not just present).shell— read-only diagnostic commands when the transport misbehaves.
Procedure
list_devicesto see what the ADB server already knows.- If expected device is missing →
discover(USB / Wi-Fi / emulator). connectto the target; follow the pairing prompt on the device when asked.status→ confirm state isdevice(notoffline/unauthorized).verifywith a harmless probe before relying on the transport.- If authorisation or offline state appears, run
disconnect+reconnect. - Record serial + state as evidence for the session.
Security
- Connecting/pairing a device is a mutative transport action: requires
confirm=trueand explicit human approval. - Never bypass the authorisation prompt; wait for the human to accept it on the device.
- Keep shell use read-only here — mutating host or device state belongs to
dedicated skills (
android-shell,android-files,android-apps).
Related skills
android-control (orchestrator) · android-discovery · android-recovery ·
android-device-info · android-shell