4th Chapter 2 "Monkeyrunner Source Analysis" ADB protocol and Services: ADB services SERVICES.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.

The ADB server is processed after receiving the command sent by the ADB client, and if the host service is processed inside the ADB server, the local service will be sent to the ADBD daemon on the Android target machine side for processing.

Because the ADB-related source code is not within the scope of our source analysis, it is necessary to describe all the services supported by the official ADB server. Although I have confidence in my English level, but always worried about lied, so the process of translation to the English also retained for your reference.

Host Services: Host:version

Request its build number to the ADB server. As an exception in an agreement (see OVERVIEW.txt to view ADB-specific protocol rules), the server returns a 4-byte hexadecimal string representing its build number, rather than returning okay or fail as in the standard protocol

Host:kill

Request the ADB server to exit immediately. When the ADB upgrade is complete, the ADB client will send this request if it detects that the previously obsolete ADB server is still running.

Host:devices host:devices-l

Both service requests are similar, requesting that the ADB server return a list of valid Android devices and the corresponding status information, except that DEVICES-L will include more information about the device in the status information, such as the product model. After a normal return of okay, a 4-byte hexadecimal number representing the length of the data is followed, and the corresponding output is shown as we can see through the command adb devices-l command, and the connection request is closed.

Host:track-devices

This service is a variant of the above host:devices, the client and ADB server connection will remain, when there is an increase/removal device or device status changes will be active to the connection to the client to send a new device list information (4 bytes 16 binary length + content). Doing so allows DDMS these tools to track the status of all connected devices in real time, without requiring the client to connect to the ADB server each time to obtain the corresponding information.

Host:emulator:

This is a special request that will be sent to the ADB server when a new emulator is started. Corresponds to a decimal number for the control port of the simulator, such as the corresponding TCP forwarding port that the native forwards to the adbd of the running emulator. This mechanism allows the ADB server to know exactly which emulator is being launched.

Host:transport:

Requests that the ADB server switch is currently connected to the specified device/emulator. After the okay is answered, all requests from the client are redirected to the daemon of the device's adbd. (-s option for ADB command line client)

Host:transport-usb

Requests the ADB server to switch between devices that are currently connected to the host via USB. If more than one device is connected to the host via USB, the call will fail. (-D, the easy-to-use option to implement the ADB command-line client)

Host:transport-local

Requests that the ADB server switch is currently connected to an emulator that is connected over the TCP protocol. If more than one emulator is running, the call will fail. (For the easy-to-use option of-e)

Host:transport-any

Another variant of the Host:transport. Requests that the ADB server switch the device that is currently connected to the host that is already connected or that is running in the host computer. If more than one such device exists, the call will fail. (used when none of the-s,-d or-e options are available)

Host-serial:serial-number:request

This is a special request, the prefix "HOST-SERIAL:SERIAL-NUMBER>:" is used to specify the client request information when the target ADB server is located on a specific device. The request can be any of the methods described below.

Host-usb:request

A variant of the host-serial that specifies a USB device connected to the host. If there are no or more than one such device, the call will fail.

Host-local:request

Another variant of the host-serial, this time specifying a simulator that runs on the host. If there are no or more than one such device, the call will fail. Equivalent to direct execution of "adb get-product" or "adb Get-serilano", etc.

Host:request

When requesting information through the ADB server to a related device, ' host: ' In this case it can also refer to ' any device connected to the host or emulator running on the host '.
(The following "Host-prefix:" begins with the description of the above 4 special Service request parameters)

Host-prefix:get-productxxx

The official provided the above xxx, no more information. I found no support when I tried "adb get-product".

Host-prefix:get-serialno

Returns the serial number of the corresponding device/emulator. "Host-prefix:" refers to the above 4 kinds of special Information request command. Note that the simulator's serial number is formatted as "emulator-5554". Similar to command line execution "adb Get-serialno"

Host-prefix:get-devpath

Returns the device path for the corresponding device/emulator, where the device path refers to the last part of the "ADB device-l" list, such as "Device product:oppo_12025 model:x909 device:x909". "Host-prefix:" refers to the above three kinds of special Information request command. Similar to command line execution "adb get-devpath".

Host-prefix:get-state

Returns a string representing the state of the specified device, "Host-prefix:" refers to the above three special information request commands. Similar to command line execution "adb get-stat".

Host-prefix:forward:local;remote

Requests the ADB server to redirect the connection specified locally to the remote address of the specified device. Here, "Host-prefix" can be described above to specify the target device/emulator

Where the local format can be one of the following:

• TCP connections for port ports of the local host, Tcp:port

• Local:path. UNIX domain socket connection for local host based on address path (the address of the UNIX domains socket is the path of a socket-type file in the file system)

The remote format is as follows:

• Localhost:port for target devices, Tcp:port

• Local UNIX Domain Socket for target device, Local:path

• Jdwp:pid-a JDWP thread inside a Java virtual machine specified by the process number in the target device

It even supports any of the local services described below

Host-prefix:forward:norebind:local;remote

Like Host-prefix:forward:local;remote, the difference is that if there is already a forwarding in the local, the call will fail. Used to implement "ADB forward–no-rebind local Remote"

Host-prefix:killforward:local

Removes all the specified local redirect connections. Used to implement the "ADB forward–remove local" command

Host-prefix:killforward-all

Remove all redirected connections. Used to implement the "ADB forward–remove-all" command

Host-prefix:list-forward

Lists all existing forwarding connections for this machine. The return format is as follows:

• HEX4: Returns the length of the result, consisting of 4 bytes of 16 binary characters

• Payload: A series of lines in the following format:

  • Serial "Local" "Remote" \ n ": Serial represents the device serial number. Local represents the connection point on the host side (for example, tcp:90000). Remote represents the connection point on the device side.

This is used to implement the "ADB forward–list" command.

Local Service:

All of the following requests are based on a service request that you have switched the transfer to a real device, or that you have used one of the query prefixes described above.

Shell:command arg1 arg2 ...

Run ' command arg1 arg2 ... ' in the shell of the device and return the corresponding output and error stream.

Note that the parameters must be separated by spaces. If a parameter itself contains a space, it must be enclosed in double quotation marks. Parameters cannot contain double quotation marks, otherwise the command execution result will not be controlled.

Note that this is a non-interactive version of the "adb shell"

Shell

Turns on an interactive shell session for the device. Reasonable redirection of standard input/standard output/callout errors.

Note that the ADB server is using this protocol to implement the "ADB shell" request of the command line client, but of course it will wrap up the input information before sending it to the target device (see COMMANDLINE.C's Interactive_shell ())

Remount

Request ADBD to re-mount the device read-only file system to a read-write mode file system. This is usually necessary before performing an "adb sync" or "adb push" request. This request may fail in some versions because it is not supported

Dev:path

Opens a device file and reads and writes to the device through the client connection. This is typically used for debugging purposes, but may not be run on all devices because it requires special permissions to execute. Path refers to the full path starting at the root of the file system.

Tcp:port

Try to connect to the TCP port on this computer ports port

Tcp:port:server-name

Try to connect the TCP port on the specified device on Server-name. This is useful for debugging network/agent issues that can only be displayed on the device.

Local:path

Try to connect to the UNIX domain socket specified on the device's path address

Localreserved:path | Localabstract:path | Localfilesystem:path

Several variants of Local:path are used to access the sockets specified by other Android namespaces.

Log:name

Opens a system journal file specified by/dev/log/name and allows the client to read the journal information directly. Used to implement the "ADB logcat" command. The journal stream is read-only to the client.

Framebuffer

This service is used to send screenshots of framebuffer to the client. It requires sufficient permissions and works as follows: The service will continue to send the following contents of the 16-byte binary structure data to the client (small endian format) after returning okay

• Depth:uint32_t:framebuffer depth

• Size:uint32_t:framebuffer size (bytes)

• Width:uint32_t:framebuffer width (pixels)

• Height:uint32_t:framebuffer height (pixels)

In the current implementation, the width is always 16, and the size is always width * height

Each time a client wants a screenshot, it sends a byte through the socket channel, which triggers the service to send the framebuffer data to the client in the number of bytes specified by its size. If the ADBD daemon does not have sufficient privileges to open the framebuffer device, the connection is immediately closed.

Jdwp:pid

Connect the JDWP thread inside the Java virtual machine process specified by the process number in the target device

Track-jdwp

This service is used to periodically send a list of process numbers to the client that have the JDWP process enabled.
The format of the returned data is the following:
The return data format is as follows:

• HEX4: Represents a 4-byte 16 binary string that returns the length of the data

• Content: A series of ASCLL word serial, each line is formatted as follows: "\ n"

This service is used by DDMS to know which tunable processes are running on the real device/emulator.

Note that there is no other service to get this list only once.

Sync

The file synchronization service is turned on to implement both the "ADB push" and "adb pull" commands. Because this service is quite complex, please see the relevant SYNC.TXT documentation for more detailed information.

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

——— to Be Continued ———

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

4th Chapter 2 "Monkeyrunner Source Analysis" ADB protocol and Services: ADB services SERVICES.TXT translation Reference (original)