Samuel Carlsson | 912d5dd | 2014-03-20 11:44:09 +0100 | [diff] [blame^] | 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 | differ 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 called sync request and sync |
| 19 | responses. The first four bytes is an id and specifies sync request is |
| 20 | represented by four utf-8 characters. The last four bytes is 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 | SEND - Send a file to device |
| 29 | RECV - Retreive a file from device |
| 30 | |
| 31 | Not yet documented: |
| 32 | STAT - Stat a file |
| 33 | ULNK - Unlink (remove) a file. (Not currently supported) |
| 34 | |
| 35 | For all of the sync request above the must be followed by length number of |
| 36 | bytes containing an utf-8 string with a remote filename. |
| 37 | |
| 38 | LIST: |
| 39 | Lists files in the directory specified by the remote filename. The server will |
| 40 | respond with zero or more directory entries or "dents". |
| 41 | |
| 42 | The directory entries will be returned in the following form |
| 43 | 1. A four-byte sync response id beeing "DENT" |
| 44 | 2. A four-byte integer representing file mode. |
| 45 | 3. A four-byte integer representing file size. |
| 46 | 4. A four-byte integer representing last modified time. |
| 47 | 5. A four-byte integer representing file name length. |
| 48 | 6. length number of bytes containing an utf-8 string representing the file |
| 49 | name. |
| 50 | |
| 51 | When an sync response "DONE" is received the listing is done. |
| 52 | |
| 53 | SEND: |
| 54 | The remote file name is split into two parts separated by the last |
| 55 | comma (","). The first part is the actual path, while the second is a decimal |
| 56 | encoded file mode containing the permissions of the file on device. |
| 57 | |
| 58 | Note that some file types will be deleted before the copying starts, and if |
| 59 | the transfer fails. Some file types will not be deleted, which allows |
| 60 | adb push disk_image /some_block_device |
| 61 | to work. |
| 62 | |
| 63 | After this the actual file is sent in chunks. Each chucks has the following |
| 64 | format. |
| 65 | A sync request with id "DATA" and length equal to the chunk size. After |
| 66 | follows chunk size number of bytes. This is repeated until the file is |
| 67 | transfered. Each chunk must not be larger than 64k. |
| 68 | |
| 69 | When the file is tranfered a sync request "DONE" is sent, where length is set |
| 70 | to the last modified time for the file. The server responds to this last |
| 71 | request (but not to chuck requests) with an "OKAY" sync response (length can |
| 72 | be ignored). |
| 73 | |
| 74 | |
| 75 | RECV: |
| 76 | Retrieves a file from device to a local file. The remote path is the path to |
| 77 | the file that will be returned. Just as for the SEND sync request the file |
| 78 | received is split up into chunks. The sync response id is "DATA" and length is |
| 79 | the chuck size. After follows chunk size number of bytes. This is repeated |
| 80 | until the file is transfered. Each chuck will not be larger than 64k. |
| 81 | |
| 82 | When the file is transfered a sync resopnse "DONE" is retrieved where the |
| 83 | length can be ignored. |
| 84 | |