Android debug Bridge

This article attempts to list all requests that the client can send to the ADB server. About the ADB client, ADB server, adbd daemon, ADB service concepts, and how these components work together to complete ADB, refer to the previous article Android debug bridge technology implementation.

====================================
Host Service
====================================

HOST: Version
Request the internal version number of the ADB server. As a special exception, the server will respond with a 4-byte hexadecimal string and return the internal server version number. The response does not contain "okay" or "fail ".

HOST: Kill
Request the ADB server to exit immediately. The ADB client detects that the discarded ADB server is still running after the upgrade.

HOST: Devices
Request to return a list of available Android devices and their statuses. After "okay", it is a four-byte length definition, followed by a specified length string indicating the current device status, and the connection is closed after the result is returned.

HOST: Track-Devices
A variant of "Host: devices", which does not close the connection. On the contrary, each time a device is added or removed, or the status of the specified device changes, a new device list description is sent. This allows tools such as ddms to track the status of connected devices in real time without repeated training servers.

HOST: emulator: <port>
This is a special request. When a new simulator is started, the request is sent to the ADB server. <Port> is a decimal number that represents the ADB protocol port number of the simulator. For example, the simulator automatically forwards the port number to the TCP port number of the adbd daemon. This mechanism allows the ADB server to know that the new simulator instance is started.

HOST: Transport: <serial-number>
Request to switch to the device or simulator indicated by <serial-number>. After receiving the "okay" response, all client requests will be sent directly to the adbd daemon running on the specified device. (Used to implement-S)

HOST: Transport-USB
Request to switch to the device that is connected to the host through USB. If there are multiple such devices, the request will fail. (Used to implement-d)

HOST: Transport-Local
Request to switch to the simulator connected over TCP. If multiple of these simulator instances are running, the request will fail. (Used to implement-E)

HOST: Transport-any
Another "Host: Transport" variant. Request to switch to a connected device or a running simulator. If more than one device or simulator is available, the request will fail. (When-S,-D, and-E are not provided)

Host-serial: <serial-number >:< request>
This is a special form of request. The prefix "Host-serial: <serial-number>:" indicates that the client is requesting the ADB server to obtain the information of the specified device. <Request> it can be in the following format.

Host-USB: <request>
A variant of host-serial used to target a unique USB device connected to the host. If there are no such devices or multiple such devices, the request will fail.

Host-Local: <request>
A variant of host-serial used to target a unique simulator instance running on the host. If there are no such simulators or multiple such simulators, the request will fail.

HOST: <request>
When requesting device-related information, "Host:" can also be interpreted as "any unique device connected to the host or a unique simulator running on the host ".

<Host-Prefix>: Get-Product
No explanation.

<Host-Prefix>: Get-serialno
Returns the serial number of the corresponding device or simulator. Note that the simulator serial number is in the form of "emulator-5544.

<Host-Prefix>: Get-state
Returns the status string of the specified device.

<Host-Prefix >:forward: <local >;< remote>
Requests the ADB server to transfer the local connection from <local> to the <remote> address on the specified device.
Here, The <local> format is as follows:
TCP: <port>-> TCP connection on localhost: <port>
Local: <path>-> UNIX local region socket (UNIX domain socket) on <path>)
The <remote> format is as follows:
TCP: <port>-> TCP connection of localhost: <port> on the device
Local: <path>-> UNIX local region socket on the device
Jdwp: <pid>-> jdwp thread in the Virtual Machine Process <pid>
Or any of the local services described below.


====================================
Local Service
====================================

All the following requests assume that you have switched to the actual device, or you use the request prefix described above.

Shell: Command arg1 arg2...
Run "command arg1 arg2..." in the shell of the device to return the output stream and error stream. Note that the command parameters must be separated by spaces. If a parameter contains spaces, use double quotation marks. Parameters cannot contain double quotation marks and other symbols that may cause errors.
This is a non-interactive version of "ADB shell.

Shell:
Start an interactive shell Session on the device. Properly redirect standard input, standard output, and standard error output. The ADB server uses this service to implement "ADB shell". However, before the input is sent to the device, the ADB server also processes the input. (Refer to the interactive_shell () function in CommandLine. c)

Remount:
Request the adbd daemon to re-mount the file system of the device to read/write mode, instead of read-only mode. This service is usually required before "ADB sync" or "ADB push" is executed.
In a specific system that does not allow this operation, this request may fail.

Dev: <path>
Open a device file and directly connect the client to the file for read/write. This service is useful for debugging and debugging, but requires special permissions and cannot run on all devices. <Path> indicates the full path starting from the root directory of the file system.

TCP: <port>
Try to connect to the TCP port <port> of loclhost.

TCP: <port >:< server-Name>
Try to connect to the TCP port of the <server-Name> specified Machine <port> from the device. This service is useful for debugging network or proxy problems that can only be displayed on devices.

Local: <path>
Try to connect to the Unix domain socket on the device <path>.

Localreserved: <path>
Localabstract: <path>
Localfilesystem: <path>
Several local: <path> variants used to access other android socket namespaces.

Log: <Name>
Open a system log (/dev/log/<Name>) and allow the client to directly read it. Used to implement "ADB logcat ". The data stream is read-only to the client.

Framebuffer:
This service is used to send a framebuffer snapshot to the client. It requires sufficient permissions and works as follows:
After "okay", the Service sends a 16-byte binary structure containing the following fields (low-priority format ):
Depth: uint32_t: framebuffer depth
Size: uint32_t: framebuffer size (unit: bytes)
Width: uint32_t: framebuffer width (unit: pixel)
Height: uint32_t: framebuffer height (unit: pixels)
In the current implementation, the framebuffer depth is always 16, and the size is always: width * height * 2.
Whenever the client wants a snapshot, it should send a byte through the channel, trigger the service to send the framebuffer data to it according to the number of bytes specified by the framebuffer size.
If the adbd daemon does not have sufficient permissions to open the framebuffer device, the connection is immediately closed.

DNS: <server-Name>
This service is an exception because it only runs on the ADB server. It is used to achieve USB network, for example, providing a network connection for the device through the host.
It is used to execute gethostbyname (<address>) on the host, and the IP address is returned with a 4-byte string.

Recover: <size>
This service uploads a recovery image to the device. <Size> the size of the image file must be the same as that of the recovery image file. The working principle is as follows:
-Create a file named/tmp/update;
-Read the number of <size> bytes from the client and write them to/tmp/update;
-After the image file is successfully read, create a file named/tmp/update. Start.
This service can only work when the device is in the recovery mode. In addition, if the/tmp directory does not exist, the connection will be closed immediately.

Jdwp: <pid>
Connect to the jdwp thread running in the VM Process <pid>.

Track-jdwp
Sends the jdwp PIDs list to the client periodically. The returned data format is as follows:
<Hex4>: A 4-character hexadecimal string that specifies the length of all content
<Content>: A series of ASCII lines in the format of <pid> "/N"
Ddms uses this service to know which processes can be debugged are running on the device or simulator.
Note that there is no one-step service that obtains the list only once.

Sync:
This request starts the file system synchronization service to implement "ADB push" and "ADB pull ". This service is very complicated and requires special articles to explain it. If you are interested, we will discuss it later.