# Android Adb

> Android Debug Bridge engine — server, device discovery, connect/pair, and transport-level diagnostics. Use for any ADB server lifecycle work, device pairing, connectivity checks, or transport troubleshooting.

- Skill: `samraddhashrivastavatech/android-adb` (Agent Skill)
- Install (CLI): `npx skillmds@latest add samraddhashrivastavatech/android-adb`
- Raw SKILL.md: https://api.skillmd.com/api/skills/samraddhashrivastavatech/android-adb/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: SAMRADDHASHRIVASTAVATECH (https://skillmd.com/u/samraddhashrivastavatech)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/samraddhashrivastavatech/android-adb

---


# 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

1. `list_devices` to see what the ADB server already knows.
2. If expected device is missing → `discover` (USB / Wi-Fi / emulator).
3. `connect` to the target; follow the pairing prompt on the device when asked.
4. `status` → confirm state is `device` (not `offline` / `unauthorized`).
5. `verify` with a harmless probe before relying on the transport.
6. If authorisation or offline state appears, run `disconnect` + `reconnect`.
7. Record serial + state as evidence for the session.

## Security

- Connecting/pairing a device is a mutative transport action: requires
  `confirm=true` and 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`