4th Chapter 3 "Monkeyrunner Source Analysis" ADB protocol and Services: ADB Agreement overview SYNC.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 purpose of this documentation is to document a client requesting the ADB server to send a file-related request to the ADBD daemon. Check the OVERVIEW.TXT documentation to see information about (ADB server and ADBD daemon), and see SERVICES.TXT to learn more about other available requests.

Synchronization Service:

Use the relevant protocol described by SERVICES.TXT to request the Synchronization service ("Sync:") to set the connection to synchronous mode. This mode is also called binary mode, which differs from the normal ADB protocol. When set, the connection remains in this mode until it is explicitly terminated (see description below)

After initiating the "Sync:" command to start the sync mode, the server side must return "OKAY" or "FAIL" reply as normal mode (see OVERVIEW.TXT).

In synchronous mode, the server and client frequently use 8-byte packets for interactive communication, which is referred to in this document as "synchronous request" and "synchronous answer". The first 4 bytes are the ID of a specified synchronization request, and the 4 bytes are rendered with 4 utf-8 characters. The next 4 bytes is a small-endian integer, which is widely used (various) and is referred to as the "length" below. In fact, all binary integers in synchronous mode are small endian. Synchronous mode automatically exits and enters normal adb communication mode after each synchronization request is completed, please check the SERVICES.TXT for normal mode details.

All synchronization requests within the acceptable range are listed as follows:

• List-Lists all the files under a folder

• Send-a file is sent to the target device

• RECV-Get a file from the target device

The following list does not have a truly documented synchronization request :

• STAT-Gets the various state properties of a file

• Ulink-Cancels (deletes) a connection to a file. (Not supported yet)

All of the synchronization requests mentioned above must be followed by a byte of the size specified by "Length" to store the remote file name of the Utf-8 string type.

LIST:

This synchronization request lists all files in the directory specified by remote file name. The server will return more than 0 directory entries or it may also be called "dents".

Catalog entries will be returned in the following form

• A 4-byte synchronous return with ID "DENT"

• A 4-byte integer representing the file (permission) mode

• A 4-byte integer representing the size of the file

• A 4-byte integer representing the last modified event

• A 4-byte integer representing the length of the file name

• The "Length" size of the byte code containing a file name encoded in the UTF-8 string format

When the client receives a "done" synchronization return, the request to list all the files in the specified directory is completed.

SEND:

The remote file name in this case will be divided into 2 parts by the last comma (","), the previous part represents the real path, and the second part is a decimal form of the file mode attribute that represents the access rights of the file on the target device.

Note that some file types are deleted before (ADBD) the file is actually copied to the target directory or after the delivery fails. But there are also some file types that are not deleted, which allows

  adb push disk_image /some_block_device

can work properly (Heaven Zhuhai Branch rudder Note: Otherwise, if the adbd received files are deleted after processing, you can no longer copy this file to the target block device "Some_block_device" go).

The actual contents of the file can be transferred by block after sending the transfer command. Each file block will have the following format.

A synchronous request command with ID "DATA" followed by the length of the block size, followed by a block-sized byte content. The contents of the file are transferred in this format repeatedly until the entire file transfer is complete. The size of each block cannot be greater than 64k.

A "Done" synchronization request is sent to the target machine (ADBD) when the file transfer is complete, in which case the requested "length" is set to the last modified time of the file. The server finally returns a "OKAY" synchronous reply after receiving this request (note that not every data block is sent) (The requested "length" can be ignored regardless of the request)

RECV:

The purpose of this request is to retrieve a file from the target machine and save it locally. The remote file name of the request is set to the path of the remote file name to get back. As with the "SEND" synchronization request above, the file is routed as a file block. The ID in the synchronous return format is "DATA", "Length" is the block size, followed by the number of bytes (file content) that is the specified block size. The same size cannot exceed 64k per block.

When the file transfer is complete, the client obtains a "done" synchronization request, which can be ignored regardless of the "length" of the request.

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

——— to Be Continued ———

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

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