4th Chapter 1 "Monkeyrunner Source Analysis" ADB protocol and Services: ADB Agreement overview OVERVIEW.TXT Translation Reference (original)

Heaven Zhuhai Branch Rudder note : Originally this series is to prepare a book, details please see the earlier blog "to seek partners to write the deep understanding of Monkeyrunner" books. But for many reasons, there is no wish. So the draft is shared here, so mistakes are unavoidable. If necessary, please refer to the following, the forwarding of the word also keep the end of each article source and other information.

About the ADB implementation record. I. Overview

The Android Debug Bridge (ADB) is used to track an Android device or emulator instance that manages all connections or runs on a development host.

It implements a variety of control commands (e.g. "adb shell", "adb pull", etc...) To facilitate a variety of clients (command-line users, or programs such as development assistants such as DDMS). These commands are actually the so-called "services" in the ADB.

Overall, all of the work is done in the following individual components:

1. ADB server

This is a daemon daemon running on the host side. The purpose of this process is to sense (monitor) whether the USB port has a device mounted or removed, and of course includes monitoring the startup and shutdown of the emulator instance.

So it maintains a series of "connected devices" information, and each connected device is given one of the following statuses: Offline,bootloader,recovery or online (there will be more support for other states later).

The ADB server can indeed be called a powerful multi-route, and its purpose is to coordinate the exchange of data (in fact, packets) between the ADB command line client, the service, and the device as if it were routed.

2. ADB Daemon (ADBD)

"ADBD" is run as a daemon in the target Android device or emulator system. His purpose is to connect to the host-side ADB server (the real device uses a USB connection, and the simulator connects via TCP) to provide some services to clients running on the host side. (Translator Note: Actually the real machine can also be connected via TCP)

When the ADB server connects to the ADBD daemon of a target device, the ADB server considers the device to be online. Conversely, the device is considered a offline state, which means that the ADB server can detect a device/emulator, but it cannot connect to its ADBD daemon.

The bootloader and recovery states are a counterpart of the two alternating states in which the device is in a boot state or a repair state.

3. ADB command-line client

The ' adb ' command-line client is a program used to run ADB commands in a shell or script. It first tries to locate the ADB server on the host, and if it finds out that the ADB server is not up, it tries to start it up.

When you locate the ADB server that is already started, the ADB command-line client sends its service request command to the ADB server. It does not need to know any details of the ADB server processing the service request.

To date, the same ' adb ' binaries are used both as ADB servers and clients. The advantage of this is that it makes it easier to publish and start the ADB server.

4. Service

Essentially, the client interacts with the two types of services here.

Host Services:

These services are run entirely inside the ADB server, so there is no need to communicate with any target Android devices at all. A typical example is the command "ADB devices", which is used to obtain a series of device information and status currently connected to the host. Of course, there are a lot of other services.

Local Service:

These services may be running inside the adbd daemon of the target device, perhaps by adbd boot. The role played by the ADB server here is to act as a route between the client and the service running by the ADBD daemon as a multi-channel traffic. In this case, the ADB server initializes the connection between the ADBD daemon and the ADB command-line client, and then relays the data between them.

Ii. details of the agreement 1. Client <-> server-side protocol

The following is a detailed description of the protocol used to communicate between ADB client and ADB server itself. The TCP port that the ADB server listens on is localhost:5037.

The client sends a service request to the ADB server using the following format:

1. A 4-byte 16 string containing the length of the specified service request data

2. The 4 bytes are followed by the service request data itself

For example, in order to query the build number of the ADB server, the client will do the following actions:

1. The local socket port that is connected to the ADB server for listening tcp:localhost:5037

2. Send a Service request string "000chost:version" to the corresponding socket above

' Host: ' This prefix is used to indicate that the service request is a host request and is a request to loosen up to the ADB server itself (we'll discuss some other types of requests down the hill). To facilitate debugging, the request content length is encoded in ASCII code.

The ADB server should answer a service request for the client in one of the following formats:

1. Returns a 4-byte "OKAY" string if the service request succeeds

2. If a service request fails, the result string is preceded by a 4-byte "FAIL" string, followed by a 4-byte hexadecimal number that represents the length of the subsequent data, followed by a string that describes the cause of the error.

3. As an exception, for the service request ' Host:version ', the returned result will be a 4-byte hexadecimal string corresponding to the internal version number of the ADB server.

It is important to note that the ADB server and the service request client remain in the connected state after the service request has been completed and the ADB server has responded to the successful response of okay on behalf of the service request, allowing the client to send additional service requests shortly thereafter. However, in some special cases, an okay response from the ADB server will change the status of the connection.

Let's say, for example, ' Host:transport: ' This service request is used to identify a fixed device/emulator, and the ADB server returns ' when the service request succeeds After OKAY ' replies to the client, all clients are sent directly to the ADBD daemon of the corresponding device (the device specified in the service request command above), immediately after the service request is sent.

File SERVICES.TXT lists all the services currently implemented by ADB.

2. Transfer Mode

The transmission mode of an ADB represents a connection model between an ADB server and a target device or simulator.

• USB transfer mode, applied in the case of physical devices connected to the host side of the ADB server by using the USB protocol

• Local transfer mode, where the emulator running on the host is connected through the TCP protocol and the ADB server

In theory, it is feasible to write a local transfer mode to implement the ADB server and the connection agent for the Android device/emulator that is connected to/running on another host. But that's not done yet. (Translator Note: This document should not be updated by Google developers because, for example, in the 4.4.2 version, we can connect to any device or simulator in the same LAN via the ' ADB Connect ' command)

Each transport mode can host one or more traffic to the target Android device/emulator that the client and client point to. The ADB server must reasonably handle the abnormal disconnection of the transmission mode (for example, when a device is unplugged from the host).

Official English version: Https://android.googlesource.com/platform/system/core/+/master/adb/OVERVIEW.TXT

——— to Be Continued ———

Heaven Zhuhai Branch Rudder
Public Number: Techgogogo
Weibo: Http://weibo.com/techgogogo
Csdn:http://blog.csdn.net/zhubaitian

4th Chapter 1 "Monkeyrunner Source Analysis" ADB protocol and Services: ADB Agreement overview OVERVIEW.TXT Translation Reference (original)