ADB实施笔记
I. 总体概览：
安卓调试桥(ADB)被用来：
- 保持一条指向于所有安卓设备以及连接向或者运行于所给的开发主机的仿真机。
- 实现多个适用于客户端(命令行用户或者像DDMS那样的帮助程序)的控制命令(比如说"adb shell"、"adb pull"等等)。这些命令在ADB当中被称作"服务"。
总的来说，所有的东西都运行在下面的组件当中：
1、ADB服务端
这是一个运行在主机上的后台进程。它的目的是通过USB端口感知设备连接和移除的时间，同样也包括仿真机的开始与关闭。
因此它保持了一个"已连接设备"的列表并为它们分别分配了一个"状态"：离线(OFFLINE)、开机加载状态(BOOTLOADER)、恢复状态(RECOVERY)或者在线(ONLINE)。（更多的在下面）。
ADB服务端是一个很巨大的循环系统，目的在于处理客户端、服务端以及设备之间的数据(包)交换。
2、ADB守护进程(adbd)
"adbd"程序作为一个后台进程运行在一个安卓设备或者模拟器上。它的作用是连接上ADB服务器(真机通过USB连接，仿真机通过TCP连接)并且为运行在主机上的客户端提供一些服务。
ADB服务端在一台设备成功地连接上它的adbd程序的时候认为它是在线(ONLINE)状态。否则，设备为离线(OFFLINE)，这意味着ADB服务端检测到了一个新的设备或仿真机，但是不能连接到adbd守护进程。
开机加载状态(BOOTLOADER)和恢复状态(RECOVERY)对应着系统的bootloader模式和recovery模式。---刷机时候的一些模式，通常长按音量下+关机键可以跳转。
3、ADB命令行客户端
"adb"命令行程序被用来在壳程序(控制台、shell)或者脚本上运行adb命令。它最开始会尝试定位主机上的ADB服务端，如果没有找到则会自动开启一个。
然后，客户端发送它的服务请求到ADB服务端。它不需要知道。
现在，一个简单的"adb"二进制程序被同时用于服务端和客户端。这使得分配和打开服务更加的简单。
4、服务
一个客户端可以和两种必要的服务进行交流：
主机服务：
这些服务运行在ADB服务端，因此它们完全不需要和一台设备交流。一个典型的例子就是"adb devices"命令，这个命令的作用是返回当前已知设备以及它们的状态的列表。它们是一些其他的服务。
本地服务：
这些服务运行在adbd守护进程上或者在设备上被它打开。ADB服务端被用来梳理客户端和运行在adbd的服务。此时它的作用是初始化连接，然后作为数据传输的通道。
II.协议细节：
1、客户端<->服务端协议：
此处描述了ADB客户端以及ADB服务端进行通讯的协议细节。ADB服务端接收端口为TCP:localhost:5037。
客户端通过如下的格式发送请求：
1、一个四字节的十六位字符串描述内容长度
2、接下来是内容
比如说，想要查询ADB服务端的内部版本号，客户端会像下面这么做：
1、连接到tcp:localhost:5037
2、发送字符串"000Chost:version"到适合的接口
主机端：前缀被用来确认这个请求已经被指向了服务端本身（我们会在接下来讨论其他种类的请求）。为了调试方便，内容的长度通过ACSLL编码。
服务端应该通过以下的其中一种回应请求：
1、成功，返回四字节的字符串"OKAY"
2、失败，首先是一个四字节的字符串"FAIL"，然后是一个四字节的十六位数字(描述长度)，然后是失败的原因
3、作为一个特殊的异常，对于"host:version"，一个四字节的十六位字符串，对应着服务端的内部版本号
记住在"OKAY"回复之后连接依然是活动的，这允许客户端发送其他请求。但是在明确的条件下，一个"OKAY"回复甚至会改变连接的状态。
比如说，"host:transport:<serialnumber>"请求，"<serialnumber>"被用来指明一个给定的设备或仿真机；在"OKAY"返回之后，之后所有的由客户端产生的请求都回直接发送到对应的adbd守护进程。
文件SERVICES.TXT列举了所有当前被ADB实现的服务。
2、传输：
一个ADB传输构成了一个ADB服务端到一个设备或者仿真机的连接。现在有两种类型的传输：
- USB传输，通过USB连接物理设备
- 本地传输，为了主机上运行的仿真机，通过TCP连接到服务端
理论上，应该可以写一个本地的传输来同时代理从ADB服务端或仿真机到另一台机器上的连接。不过现在这个还没有做。
每一个传输都可以携带一个或者更多的介于客户端和设备或者仿真机的流。ADB服务端必须正确地处理未预期的传输断线（比如说，当一个设备被物理性的拔出的时候）。
原文：
Implementation notes regarding ADB.
I. General Overview:
The Android Debug Bridge (ADB) is used to:
- keep track of all Android devices and emulators instances
connected to or running on a given host developer machine
- 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.
As a whole, everything works through the following components:
1. The ADB server
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.
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).
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.
2. The ADB daemon (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.
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.
the BOOTLOADER and RECOVERY states correspond to alternate states of
devices when they are in the bootloader or recovery mode.
3. The ADB command-line 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.
then, the client sends its service requests to the ADB server. It doesn't
need to know..
Currently, a single 'adb' binary is used for both the server and client.
this makes distribution and starting the server easier.
4. Services
There are essentially two kinds of services that a client can talk to.
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.
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.
II. Protocol details:
1. Client <-> Server protocol:
This details the protocol used between ADB clients and the ADB
server itself. The ADB server listens on TCP:localhost:5037.
A client sends a request using the following format:
1. A 4-byte hexadecimal string giving the length of the payload
2. Followed by the payload itself.
For example, to query the ADB server for its internal version number,
the client will do the following:
1. Connect to tcp:localhost:5037
2. Send the string "000Chost:version" to the corresponding socket
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.
The server should answer a request with one of the following:
1. For success, the 4-byte "OKAY" string
2. For failure, the 4-byte "FAIL" string, followed by a
4-byte hex length, followed by a string giving the reason
for failure.
3. As a special exception, for 'host:version', a 4-byte
hex string corresponding to the server's internal version number
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.
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.
The file SERVICES.TXT lists all services currently implemented by ADB.
2. Transports:
An ADB transport models a connection between the ADB server and one device
or emulator. There are currently two kinds of transports:
- USB transports, for physical devices through USB
- Local transports, for emulators running on the host, connected to
the server through TCP
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.
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.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
