1 This file tries to document file-related requests a client can make 2 to the ADB server of an adbd daemon. See the OVERVIEW.TXT document 3 to understand what's going on here. See the SERVICES.TXT to learn more 4 about the other requests that are possible. 5 6 SYNC SERVICES: 7 8 9 Requesting the sync service ("sync:") using the protocol as described in 10 SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that 11 differs from the regular adb protocol. The connection stays in sync mode until 12 explicitly terminated (see below). 13 14 After the initial "sync:" command is sent the server must respond with either 15 "OKAY" or "FAIL" as per usual. 16 17 In sync mode both the server and the client will frequently use eight-byte 18 packets to communicate. In this document these are called sync requests and sync 19 responses. The first four bytes are an id that specifies the sync request. It is 20 represented by four utf-8 characters. The last four bytes are a Little-Endian 21 integer, with various uses. This number will be called "length" below. In fact 22 all binary integers are Little-Endian in the sync mode. Sync mode is 23 implicitly exited after each sync request, and normal adb communication 24 follows as described in SERVICES.TXT. 25 26 The following sync requests are accepted: 27 LIST - List the files in a folder 28 RECV - Retrieve a file from device 29 SEND - Send a file to device 30 STAT - Stat a file 31 32 All of the sync requests above must be followed by "length": the number of 33 bytes containing a utf-8 string with a remote filename. 34 35 LIST: 36 Lists files in the directory specified by the remote filename. The server will 37 respond with zero or more directory entries or "dents". 38 39 The directory entries will be returned in the following form 40 1. A four-byte sync response id "DENT" 41 2. A four-byte integer representing file mode. 42 3. A four-byte integer representing file size. 43 4. A four-byte integer representing last modified time. 44 5. A four-byte integer representing file name length. 45 6. length number of bytes containing an utf-8 string representing the file 46 name. 47 48 When a sync response "DONE" is received the listing is done. 49 50 SEND: 51 The remote file name is split into two parts separated by the last 52 comma (","). The first part is the actual path, while the second is a decimal 53 encoded file mode containing the permissions of the file on device. 54 55 Note that some file types will be deleted before the copying starts, and if 56 the transfer fails. Some file types will not be deleted, which allows 57 adb push disk_image /some_block_device 58 to work. 59 60 After this the actual file is sent in chunks. Each chunk has the following 61 format. 62 A sync request with id "DATA" and length equal to the chunk size. After 63 follows chunk size number of bytes. This is repeated until the file is 64 transferred. Each chunk must not be larger than 64k. 65 66 When the file is transferred a sync request "DONE" is sent, where length is set 67 to the last modified time for the file. The server responds to this last 68 request (but not to chunk requests) with an "OKAY" sync response (length can 69 be ignored). 70 71 72 RECV: 73 Retrieves a file from device to a local file. The remote path is the path to 74 the file that will be returned. Just as for the SEND sync request the file 75 received is split up into chunks. The sync response id is "DATA" and length is 76 the chunk size. After follows chunk size number of bytes. This is repeated 77 until the file is transferred. Each chunk will not be larger than 64k. 78 79 When the file is transferred a sync response "DONE" is retrieved where the 80 length can be ignored. 81
