原文：https://github.com/android/platform_system_core/blob/master/adb/OVERVIEW.TXT）

Implementation notes regarding ADB.

ADB实现注解

1. General Overview:

1概要

The Android Debug Bridge (ADB) is used to:

ADB在下面情况下使用：

• keep track of all Android devices and emulators instances connected to or running on a given host developer machine
• 对全部连接到开发机器上的android真机和模拟器进行跟踪管理
• implement various control commands (e.g. "adb shell", "adb pull", etc..) for the benefit of clients (command-line users, or helper programs like DDMS). These commands are what is called a ‘service‘ in ADB.
• 实现了大量的控制命令（比方: "adb shell", "adb pull",等等）来方便用户使用（包含命令行用户和助手类程序如ddms),这些命令往往被我们叫做adb中的一个‘服务’。

As a whole, everything works through the following components:

总而言之。全部的事情都是环绕着下面这几个模块进行的：

1.1 The ADB server

1.1 ADBserver

This is a background process that runs on the host machine. Its purpose if to sense the USB ports to know when devices are attached/removed,as well as when emulator instances start/stop.

这是在主机设备(PC/开发机器)上执行的一个后台进程。它的目的是嗅探何时有设备在主机的usb口上挂载/移除，以及模拟器何时开启/关闭。

It thus maintains a list of "connected devices" and assigns a ‘state‘ to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE (more on this below).

因此它会维护着一个"已连接设备"列表，而且为每一个设备指定一个‘状态’：OFFLINE, BOOTLOADER, RECOVERY 或 ONLINE (下文会详述）。

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

ADBserver确实能够称为是一个强大的多路路由。它的目的就是去协调组织client，各种服务和设备之间的数据交换(数据包，真实数据)。

1.2 The ADB daemon (adbd)

1.2 ADB守护进程(adbd)

The ‘adbd‘ program runs as a background process within an Android device or emulated system. Its purpose is to connect to the ADB server (through USB for devices, through TCP for emulators) and provide a few services for clients that run on the host.

adbd是一个在android真实机器或者模拟器上执行的后台伺服程序。

它的目的是为了连接pc端的adbserver（真实机器用usb，模拟器用tcp协议（译者注：事实上真实机器也能够用tcp来连接。这篇文章没有及时更新过来））而且为在主机pc上执行的adbclient应用提供一些服务。

The ADB server considers that a device is ONLINE when it has successfully connected to the adbd program within it. Otherwise, the device is OFFLINE, meaning that the ADB server detected a new device/emulator, but could not connect to the adbd daemon.

当adbserver成功连接上android机器上的adbd伺服程序的时候就会觉得该设备已经online，否者就会觉得该设备是offline，指的是adbserver有检測到一个新的设备连接上来，可是却没有成功连接上该设备的的adbd。

the BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode.

BOOTLOADER和RECOVERY着两个状态分别代表android设备处于bootloader或者recovery模式下的相应的可选状态。

1.3. The ADB command-line client

1.3 ADB命令行client

The ‘adb‘ command-line program is used to run adb commands from a shell or a script. It first tries to locate the ADB server on the host machine, and will start one automatically if none is found.

adb命令行client是给shell或者脚本调用来跑各种adb命令的。它首先会尝试找到主机pc上执行的adbserver，假设没有找到的话就会自己主动启动一个adbserver。

then, the client sends its service requests to the ADB server. It doesn‘t need to know.

然后该adb命令行client会往adbserver发送服务请求。而这些对于adbserver来说是无需知道的。

Currently, a single ‘adb‘ binary is used for both the server and client. this makes distribution and starting the server easier.

就当前来说，adbserver和adbclient使用的事实上是同一个二进制文件。这样使得公布和启动server会更方便。

1.4. Services

1.4. 服务

There are essentially two kinds of services that a client can talk to.

本质上一个adb命令行client会和两类服务进行通信。

Host Services: these services run within the ADB Server and thus do not need to communicate with a device at all. A typical example is "adb devices" which is used to return the list of currently known devices and their state. They are a few couple other
services though.

主机服务：这些服务是在adbserver自身内部执行的所以根本不须要和不论什么的android设备进行交互。一个典型的命令就是列出当前连接的全部android设备和状态的命令“adb devices”。

当然另一些其它的服务了。

Local Services: these services either run within the adbd daemon, or are started by it on the device. The ADB server is used to multiplex streams between the client and the service running in adbd. In this case its role is to initiate the connection,
then of being a pass-through for the data.

本地服务：这类服务是在adbd这个守护进程自身内部执行的。或者是由它启动执行的。

adbserver会在client和这些adbd中执行的服务之间进行数据路由。在这样的情况下adbserver扮演着初始化各种连接以及数据路信使的角色。

（注：以上两表整理来自网友 arm-linux：http://www.cnblogs.com/armlinux/archive/2011/02/16/2396845.html）

2 Protocol details:

2 协议细节

2.1 Client <-> Server protocol:

2.1 client<--->server端

This details the protocol used between ADB clients and the ADB server itself. The ADB server listens on TCP:localhost:5037.

下面细节描写叙述的是主机pc中adbclient和adbserver端通信用到的协议。adbserver端会监听TCP:localhost:5037

A client sends a request using the following format:

client使用下面的协议格式发送请求:

• 1. A 4-byte hexadecimal string giving the length of the payload
• 1. 前面是一个4字节的十六进制用来指定请求命令的长度
• 2. Followed by the payload itself.
• 2. 紧跟着请求命令自身的内容

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

比方，为了得到adbserver的内部版本，client会做下面动作：

• 1. Connect to tcp:localhost:5037
• 1. 连接到 tcp:localhost:5037
• 2. Send the string "000Chost:version" to the corresponding socket
• 2. 发送字串"000Chost:version"到相应套接字（译者注：十六进制000C就是十进制12，"host:version"刚好12个字节)

The ‘host:‘ prefix is used to indicate that the request is addressed to the server itself (we will talk about other kinds of requests later). The content length is encoded in ASCII for easier debugging.

‘host‘这个前缀是用来指定这个请求是发送给server自身的（我们晚点会谈下其它的请求类型），为了方便调试，请求内容长度是用ASCII编码的。

The server should answer a request with one of the following:

server端将会用下面的一种方式进行应答：

• 1. For success, the 4-byte "OKAY" string
• 1. 成功：应答一个4字节的"OKAY"字串
• 2. For failure, the 4-byte "FAIL" string, followed by a 4-byte hex length, followed by a string giving the reason for failure.
• 2.失败：应答一个4字节的"FAIL"字串，紧跟着一个4字节十六进制描写叙述错误描写叙述内容长度，然后是描写叙述错误的内容字串。
• 3. As a special exception, for ‘host:version‘, a 4-byte hex string corresponding to the server‘s internal version number
• 3. 例外:‘host:version‘的返回将会是一个4字节字串代表着服务器的内部版本。

Note that the connection is still alive after an OKAY, which allows the client to make other requests. But in certain cases, an OKAY will even change the state of the connection.

注意client和server端的连接在接收到OKAY的应答后将会继续保持。以便client继续其它请求。

但在一些特定的情况下，OKAY应答会改变连接的状态。

For example, the case of the ‘host:transport:<serialnumber>‘ request, where ‘<serialnumber>‘ is used to identify a given device/emulator; after the "OKAY" answer, all further requests made by the client will go directly to the corresponding adbd daemon.

比方。以命令‘host:transport:<serialnumber>‘请求为例（当中　‘<serialnumber>‘用来指定一个指定的设备/模拟器），收到‘OKAY‘应答后，client往后的全部请求都将会直接发送到相应的设备/模拟器的adbd守护进程。

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

文件SERVICES.TXT列出了adb当前已经实现的全部服务（译者注：大家请自行google）。

2.2. Transports:

An ADB transport models a connection between the ADB server and one device or emulator. There are currently two kinds of transports:

adb传输指的是adbserver和一个设备/模拟器之间的连接模型。当前有下面两种传输模型：

• USB transports, for physical devices through USB
• USB传输：真实机器通过usb连接的情况下
• Local transports, for emulators running on the host, connected to the server through TCP
• 本地传输：本机上的模拟器通过tcp连接到adb服务器的情况下

In theory, it should be possible to write a local transport that proxies a connection between an ADB server and a device/emulator connected to/ running on another machine. This hasn‘t been done yet though.

理论上说。我们能够编写一个本地执行的传输代理来处理adbserver和连接/执行在其它主机pc上的设备/模拟器的连接，但这个还没有实现。

Each transport can carry one or more multiplexed streams between clients and the device/emulator they point to. The ADB server must handle unexpected transport disconnections (e.g. when a device is physically unplugged) properly.

每一种传输方式都能够承载多路client和其指定的设备/模拟器之间的数据流传输。adbserver必须合理的处理传输断开等异常（比方：当一个设备从pc主机上拔掉的情况）