Loading adb/OVERVIEW.TXT +9 −10 Original line number Original line Diff line number Diff line Loading @@ -7,16 +7,16 @@ The Android Debug Bridge (ADB) is used to: - keep track of all Android devices and emulators instances - keep track of all Android devices and emulators instances connected to or running on a given host developer machine connected to or running on a given host developer machine - implement various control commands (e.g. "adb shell", "adb pull", etc..) - implement various control commands (e.g. "adb shell", "adb pull", etc.) for the benefit of clients (command-line users, or helper programs like for the benefit of clients (command-line users, or helper programs like DDMS). These commands are what is called a 'service' in ADB. DDMS). These commands are called 'services' in ADB. As a whole, everything works through the following components: As a whole, everything works through the following components: 1. The ADB server 1. The ADB server This is a background process that runs on the host machine. Its purpose This is a background process that runs on the host machine. Its purpose if to sense the USB ports to know when devices are attached/removed, is to sense the USB ports to know when devices are attached/removed, as well as when emulator instances start/stop. as well as when emulator instances start/stop. It thus maintains a list of "connected devices" and assigns a 'state' It thus maintains a list of "connected devices" and assigns a 'state' Loading @@ -40,7 +40,7 @@ As a whole, everything works through the following components: meaning that the ADB server detected a new device/emulator, but could not meaning that the ADB server detected a new device/emulator, but could not connect to the adbd daemon. connect to the adbd daemon. the BOOTLOADER and RECOVERY states correspond to alternate states of The BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode. devices when they are in the bootloader or recovery mode. 3. The ADB command-line client 3. The ADB command-line client Loading @@ -49,8 +49,7 @@ As a whole, everything works through the following components: or a script. It first tries to locate the ADB server on the host machine, or a script. It first tries to locate the ADB server on the host machine, and will start one automatically if none is found. and will start one automatically if none is found. then, the client sends its service requests to the ADB server. It doesn't Then, the client sends its service requests to the ADB server. need to know. Currently, a single 'adb' binary is used for both the server and client. Currently, a single 'adb' binary is used for both the server and client. this makes distribution and starting the server easier. this makes distribution and starting the server easier. Loading @@ -61,13 +60,13 @@ As a whole, everything works through the following components: There are essentially two kinds of services that a client can talk to. There are essentially two kinds of services that a client can talk to. Host Services: Host Services: these services run within the ADB Server and thus do not need to These services run within the ADB Server and thus do not need to communicate with a device at all. A typical example is "adb devices" communicate with a device at all. A typical example is "adb devices" which is used to return the list of currently known devices and their which is used to return the list of currently known devices and their state. They are a few couple other services though. states. They are a few other services though. Local Services: Local Services: these services either run within the adbd daemon, or are started by These services either run within the adbd daemon, or are started by it on the device. The ADB server is used to multiplex streams it on the device. The ADB server is used to multiplex streams between the client and the service running in adbd. In this case between the client and the service running in adbd. In this case its role is to initiate the connection, then of being a pass-through its role is to initiate the connection, then of being a pass-through Loading adb/SYNC.TXT +12 −13 Original line number Original line Diff line number Diff line This file tries to document file related requests a client can make This file tries to document file-related requests a client can make to the ADB server of an adbd daemon. See the OVERVIEW.TXT document to the ADB server of an adbd daemon. See the OVERVIEW.TXT document to understand what's going on here. See the SERVICES.TXT to learn more to understand what's going on here. See the SERVICES.TXT to learn more about the other requests that are possible. about the other requests that are possible. Loading @@ -8,16 +8,16 @@ SYNC SERVICES: Requesting the sync service ("sync:") using the protocol as described in Requesting the sync service ("sync:") using the protocol as described in SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that differ from the regular adb protocol. The connection stays in sync mode until differs from the regular adb protocol. The connection stays in sync mode until explicitly terminated (see below). explicitly terminated (see below). After the initial "sync:" command is sent the server must respond with either After the initial "sync:" command is sent the server must respond with either "OKAY" or "FAIL" as per usual. "OKAY" or "FAIL" as per usual. In sync mode both the server and the client will frequently use eight-byte In sync mode both the server and the client will frequently use eight-byte packets to communicate in this document called sync request and sync packets to communicate. In this document these are called sync requests and sync responses. The first four bytes is an id and specifies sync request is responses. The first four bytes are an id that specifies the sync request. It is represented by four utf-8 characters. The last four bytes is a Little-Endian represented by four utf-8 characters. The last four bytes are a Little-Endian integer, with various uses. This number will be called "length" below. In fact integer, with various uses. This number will be called "length" below. In fact all binary integers are Little-Endian in the sync mode. Sync mode is all binary integers are Little-Endian in the sync mode. Sync mode is implicitly exited after each sync request, and normal adb communication implicitly exited after each sync request, and normal adb communication Loading @@ -29,8 +29,8 @@ RECV - Retrieve a file from device SEND - Send a file to device SEND - Send a file to device STAT - Stat a file STAT - Stat a file For all of the sync request above the must be followed by length number of All of the sync requests above must be followed by "length": the number of bytes containing an utf-8 string with a remote filename. bytes containing a utf-8 string with a remote filename. LIST: LIST: Lists files in the directory specified by the remote filename. The server will Lists files in the directory specified by the remote filename. The server will Loading @@ -45,7 +45,7 @@ The directory entries will be returned in the following form 6. length number of bytes containing an utf-8 string representing the file 6. length number of bytes containing an utf-8 string representing the file name. name. When an sync response "DONE" is received the listing is done. When a sync response "DONE" is received the listing is done. SEND: SEND: The remote file name is split into two parts separated by the last The remote file name is split into two parts separated by the last Loading @@ -65,7 +65,7 @@ transferred. Each chunk must not be larger than 64k. When the file is transferred a sync request "DONE" is sent, where length is set When the file is transferred a sync request "DONE" is sent, where length is set to the last modified time for the file. The server responds to this last to the last modified time for the file. The server responds to this last request (but not to chuck requests) with an "OKAY" sync response (length can request (but not to chunk requests) with an "OKAY" sync response (length can be ignored). be ignored). Loading @@ -73,9 +73,8 @@ RECV: Retrieves a file from device to a local file. The remote path is the path to Retrieves a file from device to a local file. The remote path is the path to the file that will be returned. Just as for the SEND sync request the file the file that will be returned. Just as for the SEND sync request the file received is split up into chunks. The sync response id is "DATA" and length is received is split up into chunks. The sync response id is "DATA" and length is the chuck size. After follows chunk size number of bytes. This is repeated the chunk size. After follows chunk size number of bytes. This is repeated until the file is transferred. Each chuck will not be larger than 64k. until the file is transferred. Each chunk will not be larger than 64k. When the file is transferred a sync response "DONE" is retrieved where the When the file is transferred a sync response "DONE" is retrieved where the length can be ignored. length can be ignored. Loading
adb/OVERVIEW.TXT +9 −10 Original line number Original line Diff line number Diff line Loading @@ -7,16 +7,16 @@ The Android Debug Bridge (ADB) is used to: - keep track of all Android devices and emulators instances - keep track of all Android devices and emulators instances connected to or running on a given host developer machine connected to or running on a given host developer machine - implement various control commands (e.g. "adb shell", "adb pull", etc..) - implement various control commands (e.g. "adb shell", "adb pull", etc.) for the benefit of clients (command-line users, or helper programs like for the benefit of clients (command-line users, or helper programs like DDMS). These commands are what is called a 'service' in ADB. DDMS). These commands are called 'services' in ADB. As a whole, everything works through the following components: As a whole, everything works through the following components: 1. The ADB server 1. The ADB server This is a background process that runs on the host machine. Its purpose This is a background process that runs on the host machine. Its purpose if to sense the USB ports to know when devices are attached/removed, is to sense the USB ports to know when devices are attached/removed, as well as when emulator instances start/stop. as well as when emulator instances start/stop. It thus maintains a list of "connected devices" and assigns a 'state' It thus maintains a list of "connected devices" and assigns a 'state' Loading @@ -40,7 +40,7 @@ As a whole, everything works through the following components: meaning that the ADB server detected a new device/emulator, but could not meaning that the ADB server detected a new device/emulator, but could not connect to the adbd daemon. connect to the adbd daemon. the BOOTLOADER and RECOVERY states correspond to alternate states of The BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode. devices when they are in the bootloader or recovery mode. 3. The ADB command-line client 3. The ADB command-line client Loading @@ -49,8 +49,7 @@ As a whole, everything works through the following components: or a script. It first tries to locate the ADB server on the host machine, or a script. It first tries to locate the ADB server on the host machine, and will start one automatically if none is found. and will start one automatically if none is found. then, the client sends its service requests to the ADB server. It doesn't Then, the client sends its service requests to the ADB server. need to know. Currently, a single 'adb' binary is used for both the server and client. Currently, a single 'adb' binary is used for both the server and client. this makes distribution and starting the server easier. this makes distribution and starting the server easier. Loading @@ -61,13 +60,13 @@ As a whole, everything works through the following components: There are essentially two kinds of services that a client can talk to. There are essentially two kinds of services that a client can talk to. Host Services: Host Services: these services run within the ADB Server and thus do not need to These services run within the ADB Server and thus do not need to communicate with a device at all. A typical example is "adb devices" communicate with a device at all. A typical example is "adb devices" which is used to return the list of currently known devices and their which is used to return the list of currently known devices and their state. They are a few couple other services though. states. They are a few other services though. Local Services: Local Services: these services either run within the adbd daemon, or are started by These services either run within the adbd daemon, or are started by it on the device. The ADB server is used to multiplex streams it on the device. The ADB server is used to multiplex streams between the client and the service running in adbd. In this case between the client and the service running in adbd. In this case its role is to initiate the connection, then of being a pass-through its role is to initiate the connection, then of being a pass-through Loading
adb/SYNC.TXT +12 −13 Original line number Original line Diff line number Diff line This file tries to document file related requests a client can make This file tries to document file-related requests a client can make to the ADB server of an adbd daemon. See the OVERVIEW.TXT document to the ADB server of an adbd daemon. See the OVERVIEW.TXT document to understand what's going on here. See the SERVICES.TXT to learn more to understand what's going on here. See the SERVICES.TXT to learn more about the other requests that are possible. about the other requests that are possible. Loading @@ -8,16 +8,16 @@ SYNC SERVICES: Requesting the sync service ("sync:") using the protocol as described in Requesting the sync service ("sync:") using the protocol as described in SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that differ from the regular adb protocol. The connection stays in sync mode until differs from the regular adb protocol. The connection stays in sync mode until explicitly terminated (see below). explicitly terminated (see below). After the initial "sync:" command is sent the server must respond with either After the initial "sync:" command is sent the server must respond with either "OKAY" or "FAIL" as per usual. "OKAY" or "FAIL" as per usual. In sync mode both the server and the client will frequently use eight-byte In sync mode both the server and the client will frequently use eight-byte packets to communicate in this document called sync request and sync packets to communicate. In this document these are called sync requests and sync responses. The first four bytes is an id and specifies sync request is responses. The first four bytes are an id that specifies the sync request. It is represented by four utf-8 characters. The last four bytes is a Little-Endian represented by four utf-8 characters. The last four bytes are a Little-Endian integer, with various uses. This number will be called "length" below. In fact integer, with various uses. This number will be called "length" below. In fact all binary integers are Little-Endian in the sync mode. Sync mode is all binary integers are Little-Endian in the sync mode. Sync mode is implicitly exited after each sync request, and normal adb communication implicitly exited after each sync request, and normal adb communication Loading @@ -29,8 +29,8 @@ RECV - Retrieve a file from device SEND - Send a file to device SEND - Send a file to device STAT - Stat a file STAT - Stat a file For all of the sync request above the must be followed by length number of All of the sync requests above must be followed by "length": the number of bytes containing an utf-8 string with a remote filename. bytes containing a utf-8 string with a remote filename. LIST: LIST: Lists files in the directory specified by the remote filename. The server will Lists files in the directory specified by the remote filename. The server will Loading @@ -45,7 +45,7 @@ The directory entries will be returned in the following form 6. length number of bytes containing an utf-8 string representing the file 6. length number of bytes containing an utf-8 string representing the file name. name. When an sync response "DONE" is received the listing is done. When a sync response "DONE" is received the listing is done. SEND: SEND: The remote file name is split into two parts separated by the last The remote file name is split into two parts separated by the last Loading @@ -65,7 +65,7 @@ transferred. Each chunk must not be larger than 64k. When the file is transferred a sync request "DONE" is sent, where length is set When the file is transferred a sync request "DONE" is sent, where length is set to the last modified time for the file. The server responds to this last to the last modified time for the file. The server responds to this last request (but not to chuck requests) with an "OKAY" sync response (length can request (but not to chunk requests) with an "OKAY" sync response (length can be ignored). be ignored). Loading @@ -73,9 +73,8 @@ RECV: Retrieves a file from device to a local file. The remote path is the path to Retrieves a file from device to a local file. The remote path is the path to the file that will be returned. Just as for the SEND sync request the file the file that will be returned. Just as for the SEND sync request the file received is split up into chunks. The sync response id is "DATA" and length is received is split up into chunks. The sync response id is "DATA" and length is the chuck size. After follows chunk size number of bytes. This is repeated the chunk size. After follows chunk size number of bytes. This is repeated until the file is transferred. Each chuck will not be larger than 64k. until the file is transferred. Each chunk will not be larger than 64k. When the file is transferred a sync response "DONE" is retrieved where the When the file is transferred a sync response "DONE" is retrieved where the length can be ignored. length can be ignored.
