diff options
-rw-r--r-- | adb/OVERVIEW.TXT | 19 | ||||
-rw-r--r-- | adb/SYNC.TXT | 25 |
2 files changed, 21 insertions, 23 deletions
diff --git a/adb/OVERVIEW.TXT b/adb/OVERVIEW.TXT index c40695af6..29a699254 100644 --- a/adb/OVERVIEW.TXT +++ b/adb/OVERVIEW.TXT | |||
@@ -7,16 +7,16 @@ The Android Debug Bridge (ADB) is used to: | |||
7 | - keep track of all Android devices and emulators instances | 7 | - keep track of all Android devices and emulators instances |
8 | connected to or running on a given host developer machine | 8 | connected to or running on a given host developer machine |
9 | 9 | ||
10 | - implement various control commands (e.g. "adb shell", "adb pull", etc..) | 10 | - implement various control commands (e.g. "adb shell", "adb pull", etc.) |
11 | for the benefit of clients (command-line users, or helper programs like | 11 | for the benefit of clients (command-line users, or helper programs like |
12 | DDMS). These commands are what is called a 'service' in ADB. | 12 | DDMS). These commands are called 'services' in ADB. |
13 | 13 | ||
14 | As a whole, everything works through the following components: | 14 | As a whole, everything works through the following components: |
15 | 15 | ||
16 | 1. The ADB server | 16 | 1. The ADB server |
17 | 17 | ||
18 | This is a background process that runs on the host machine. Its purpose | 18 | This is a background process that runs on the host machine. Its purpose |
19 | if to sense the USB ports to know when devices are attached/removed, | 19 | is to sense the USB ports to know when devices are attached/removed, |
20 | as well as when emulator instances start/stop. | 20 | as well as when emulator instances start/stop. |
21 | 21 | ||
22 | It thus maintains a list of "connected devices" and assigns a 'state' | 22 | It thus maintains a list of "connected devices" and assigns a 'state' |
@@ -40,7 +40,7 @@ As a whole, everything works through the following components: | |||
40 | meaning that the ADB server detected a new device/emulator, but could not | 40 | meaning that the ADB server detected a new device/emulator, but could not |
41 | connect to the adbd daemon. | 41 | connect to the adbd daemon. |
42 | 42 | ||
43 | the BOOTLOADER and RECOVERY states correspond to alternate states of | 43 | The BOOTLOADER and RECOVERY states correspond to alternate states of |
44 | devices when they are in the bootloader or recovery mode. | 44 | devices when they are in the bootloader or recovery mode. |
45 | 45 | ||
46 | 3. The ADB command-line client | 46 | 3. The ADB command-line client |
@@ -49,8 +49,7 @@ As a whole, everything works through the following components: | |||
49 | or a script. It first tries to locate the ADB server on the host machine, | 49 | or a script. It first tries to locate the ADB server on the host machine, |
50 | and will start one automatically if none is found. | 50 | and will start one automatically if none is found. |
51 | 51 | ||
52 | then, the client sends its service requests to the ADB server. It doesn't | 52 | Then, the client sends its service requests to the ADB server. |
53 | need to know. | ||
54 | 53 | ||
55 | Currently, a single 'adb' binary is used for both the server and client. | 54 | Currently, a single 'adb' binary is used for both the server and client. |
56 | this makes distribution and starting the server easier. | 55 | this makes distribution and starting the server easier. |
@@ -61,13 +60,13 @@ As a whole, everything works through the following components: | |||
61 | There are essentially two kinds of services that a client can talk to. | 60 | There are essentially two kinds of services that a client can talk to. |
62 | 61 | ||
63 | Host Services: | 62 | Host Services: |
64 | these services run within the ADB Server and thus do not need to | 63 | These services run within the ADB Server and thus do not need to |
65 | communicate with a device at all. A typical example is "adb devices" | 64 | communicate with a device at all. A typical example is "adb devices" |
66 | which is used to return the list of currently known devices and their | 65 | which is used to return the list of currently known devices and their |
67 | state. They are a few couple other services though. | 66 | states. They are a few other services though. |
68 | 67 | ||
69 | Local Services: | 68 | Local Services: |
70 | these services either run within the adbd daemon, or are started by | 69 | These services either run within the adbd daemon, or are started by |
71 | it on the device. The ADB server is used to multiplex streams | 70 | it on the device. The ADB server is used to multiplex streams |
72 | between the client and the service running in adbd. In this case | 71 | between the client and the service running in adbd. In this case |
73 | its role is to initiate the connection, then of being a pass-through | 72 | its role is to initiate the connection, then of being a pass-through |
@@ -109,7 +108,7 @@ II. Protocol details: | |||
109 | 108 | ||
110 | Note that the connection is still alive after an OKAY, which allows the | 109 | Note that the connection is still alive after an OKAY, which allows the |
111 | client to make other requests. But in certain cases, an OKAY will even | 110 | client to make other requests. But in certain cases, an OKAY will even |
112 | change the state of the connection. | 111 | change the state of the connection. |
113 | 112 | ||
114 | For example, the case of the 'host:transport:<serialnumber>' request, | 113 | For example, the case of the 'host:transport:<serialnumber>' request, |
115 | where '<serialnumber>' is used to identify a given device/emulator; after | 114 | where '<serialnumber>' is used to identify a given device/emulator; after |
diff --git a/adb/SYNC.TXT b/adb/SYNC.TXT index 06d7804f4..4445a7617 100644 --- a/adb/SYNC.TXT +++ b/adb/SYNC.TXT | |||
@@ -1,4 +1,4 @@ | |||
1 | This file tries to document file related requests a client can make | 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 | 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 | 3 | to understand what's going on here. See the SERVICES.TXT to learn more |
4 | about the other requests that are possible. | 4 | about the other requests that are possible. |
@@ -8,16 +8,16 @@ SYNC SERVICES: | |||
8 | 8 | ||
9 | Requesting the sync service ("sync:") using the protocol as described in | 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 | 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 | 11 | differs from the regular adb protocol. The connection stays in sync mode until |
12 | explicitly terminated (see below). | 12 | explicitly terminated (see below). |
13 | 13 | ||
14 | After the initial "sync:" command is sent the server must respond with either | 14 | After the initial "sync:" command is sent the server must respond with either |
15 | "OKAY" or "FAIL" as per usual. | 15 | "OKAY" or "FAIL" as per usual. |
16 | 16 | ||
17 | In sync mode both the server and the client will frequently use eight-byte | 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 | 18 | packets to communicate. In this document these are called sync requests and sync |
19 | responses. The first four bytes is an id and specifies sync request is | 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 is a Little-Endian | 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 | 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 | 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 | 23 | implicitly exited after each sync request, and normal adb communication |
@@ -29,8 +29,8 @@ RECV - Retrieve a file from device | |||
29 | SEND - Send a file to device | 29 | SEND - Send a file to device |
30 | STAT - Stat a file | 30 | STAT - Stat a file |
31 | 31 | ||
32 | For all of the sync request above the must be followed by length number of | 32 | All of the sync requests above must be followed by "length": the number of |
33 | bytes containing an utf-8 string with a remote filename. | 33 | bytes containing a utf-8 string with a remote filename. |
34 | 34 | ||
35 | LIST: | 35 | LIST: |
36 | Lists files in the directory specified by the remote filename. The server will | 36 | Lists files in the directory specified by the remote filename. The server will |
@@ -45,7 +45,7 @@ The directory entries will be returned in the following form | |||
45 | 6. length number of bytes containing an utf-8 string representing the file | 45 | 6. length number of bytes containing an utf-8 string representing the file |
46 | name. | 46 | name. |
47 | 47 | ||
48 | When an sync response "DONE" is received the listing is done. | 48 | When a sync response "DONE" is received the listing is done. |
49 | 49 | ||
50 | SEND: | 50 | SEND: |
51 | The remote file name is split into two parts separated by the last | 51 | The remote file name is split into two parts separated by the last |
@@ -65,7 +65,7 @@ transferred. Each chunk must not be larger than 64k. | |||
65 | 65 | ||
66 | When the file is transferred a sync request "DONE" is sent, where length is set | 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 | 67 | to the last modified time for the file. The server responds to this last |
68 | request (but not to chuck requests) with an "OKAY" sync response (length can | 68 | request (but not to chunk requests) with an "OKAY" sync response (length can |
69 | be ignored). | 69 | be ignored). |
70 | 70 | ||
71 | 71 | ||
@@ -73,9 +73,8 @@ RECV: | |||
73 | Retrieves a file from device to a local file. The remote path is the path to | 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 | 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 | 75 | received is split up into chunks. The sync response id is "DATA" and length is |
76 | the chuck size. After follows chunk size number of bytes. This is repeated | 76 | the chunk size. After follows chunk size number of bytes. This is repeated |
77 | until the file is transferred. Each chuck will not be larger than 64k. | 77 | until the file is transferred. Each chunk will not be larger than 64k. |
78 | 78 | ||
79 | When the file is transferred a sync response "DONE" is retrieved where the | 79 | When the file is transferred a sync response "DONE" is retrieved where the |
80 | length can be ignored. | 80 | length can be ignored. |
81 | |||