I. General overview

Android Debug Bridge (ADB) is used for:

  • Tracks all Android devices and emulator instances that are connected or running on a given developer host.
  • Implement various control commands (for example, “ADB shell”, “ADB pull”, and so on) for clients (command line users, or helper programs like DDMS). These commands are called ‘services’ in ADB. In general, everything is done through the following components:
  1. ADB server

This is a daemon running on a host. Its purpose is to be aware of USB ports to know when to connect/remove devices and when to start/stop emulator instances.

It must maintain a list of “connected devices” and assign each of them a “state” : OFFLINE, BOOTLOADER, RECOVERY, or ONLINE (more below).

ADB Server is really a giant multiplexing loop whose purpose is to orchestrate the exchange of data (packets, really) between clients, services, and devices.

  1. ADB daemon (ADBD)

‘ADBD’ runs as a background process within the Android device or emulator system. Its purpose is to connect to ADB Server (via USB for devices and TCP for emulators) and provide some services to clients running on the host.

ADB Server considers the device ONLINE only when it has successfully connected to the ADBD inside the device. Otherwise, the device is OFFLINE, which means that ADB Server has detected a new device/emulator but cannot connect to the ADBD daemon.

The BOOTLOADER and RECOVERY status corresponds to the status of the device in BOOTLOADER or RECOVERY mode.

  1. ADB command line client

The ‘ADB’ command line program is used to run ADB commands in a shell or script. It first tries to locate the ADB Server on the host, and will automatically start one if it does not exist.

The client then sends its service request to ADB Server. It doesn’t need to know.

Currently, a single ‘ADB’ binary is used as both the server and client. This makes it easier to distribute and start the server.

  1. service

There are basically two types of services that clients can interact with.

The Host service:

  • These services run inside ADB Server and do not need to communicate with devices at all. A typical example is “ADB Devices,” which is used to return a list of currently known devices and their status. Still, they are some other services.

Local services: These services either run within the ADBD daemon or are started by it on the device. ADB Server is used to multiplex streams between clients and services running within the ADBD. In this case, its role is to initiate the connection and then act as a data channel.

II. Agreement details

1. Client <-> server protocol

The protocol used between the ADB client and the ADB Server itself is detailed here. ADB Server listens on TCP:localhost:5037.

The client sends a request using the following format:

  1. The payload length is given as a 4-byte hexadecimal string
  2. And then the payload itself.

For example, to query ADB Server for its internal version number, the client will do the following:

  1. Connect the TCP: localhost: 5037
  2. Send the string 000Chost: Version to the corresponding socket.

The ‘host:’ prefix is used to indicate that the request is sent to the server itself (we’ll discuss other kinds of requests later). Content length is encoded in ASCII for easy debugging.

The server should respond to a request in one of the following ways:

  1. Request successful: a 4-byte “OKAY” string
  2. The request fails, a 4-byte “FAIL” string, followed by a 4-byte hexadecimal length, followed by a string giving the reason for the failure.
  3. As a special extension, ‘host:version’, a 4-byte hexadecimal string corresponding to the internal version number of the server

Note that after OKAY, the connection is still alive, allowing the client to make additional requests. But in some cases, OKAY will even change the state of the connection.

For example, in the case of the ‘host:transport:’ request, where ‘ ‘is used to identify a given device/simulator; After “OKAY” replies, all further requests made by the client go directly to the corresponding ADBD daemon.

The services.txt file lists all SERVICES currently implemented by ADB.

2. The transmission

ADB transport models the connection between ADB Server and a device or emulator. There are currently two types of transport:

  • USB transfer, for physical devices connected via USB
  • Local transport, used for emulators running on the host, connected to the server via TCP

Theoretically, it should be possible to write a local transport, proxy ADB Server and a connection between a device/emulator connected to/running on another machine. Although it’s not done yet.

Each transport can carry one or more multiplexing streams between clients and the device/emulator to which they point. ADB Server must properly handle unexpected transport interrupts (for example, when the device is physically unplugged).

The original translation

exceptional