auto import from //depot/cupcake/@135843

1 files changed, 0 insertions, 139 deletions

diff --git a/OVERVIEW.TXT b/OVERVIEW.TXT
deleted file mode 100644
index 6a5191a..0000000
--- a/OVERVIEW.TXT
+++ /dev/null
@@ -1,139 +0,0 @@
-Implementation notes regarding ADB.
-
-I. General Overview:
-
-The Android Debug Bridge (ADB) is used to:
-
-- keep track of all Android devices and emulators instances
-  connected to or running on a given host developer machine
-
-- implement various control commands (e.g. "adb shell", "adb pull", etc..)
-  for the benefit of clients (command-line users, or helper programs like
-  DDMS). These commands are what is called a 'service' in ADB.
-
-As a whole, everything works through the following components:
-
-  1. The ADB server
-
-    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,
-    as well as when emulator instances start/stop.
-
-    It thus maintains a list of "connected devices" and assigns a 'state'
-    to each one of them: OFFLINE, BOOTLOADER, RECOVERY or ONLINE (more on
-    this below).
-
-    The ADB server is really one giant multiplexing loop whose purpose is
-    to orchestrate the exchange of data (packets, really) between clients,
-    services and devices.
-
-
-  2. The ADB daemon (adbd)
-
-    The 'adbd' program runs as a background process within an Android device
-    or emulated system. Its purpose is to connect to the ADB server
-    (through USB for devices, through TCP for emulators) and provide a
-    few services for clients that run on the host.
-
-    The ADB server considers that a device is ONLINE when it has succesfully
-    connected to the adbd program within it. Otherwise, the device is OFFLINE,
-    meaning that the ADB server detected a new device/emulator, but could not
-    connect to the adbd daemon.
-
-    the BOOTLOADER and RECOVERY states correspond to alternate states of
-    devices when they are in the bootloader or recovery mode.
-
-  3. The ADB command-line client
-
-    The 'adb' command-line program is used to run adb commands from a shell
-    or a script. It first tries to locate the ADB server on the host machine,
-    and will start one automatically if none is found.
-
-    then, the client sends its service requests to the ADB server. It doesn't
-    need to know.
-
-    Currently, a single 'adb' binary is used for both the server and client.
-    this makes distribution and starting the server easier.
-
-
-  4. Services
-
-    There are essentially two kinds of services that a client can talk to.
-
-    Host Services:
-      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"
-      which is used to return the list of currently known devices and their
-      state. They are a few couple other services though.
-
-    Local Services:
-      these services either run within the adbd daemon, or are started by
-      it on the device. The ADB server is used to multiplex streams
-      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
-      for the data.
-
-
-II. Protocol details:
-
-  1. Client <-> Server protocol:
-
-    This details the protocol used between ADB clients and the ADB
-    server itself. The ADB server listens on TCP:localhost:5037.
-
-    A client sends a request using the following format:
-
-        1. A 4-byte hexadecimal string giving the length of the payload
-        2. Followed by the payload itself.
-
-    For example, to query the ADB server for its internal version number,
-    the client will do the following:
-
-        1. Connect to tcp:localhost:5037
-        2. Send the string "000Chost:version" to the corresponding socket
-
-    The 'host:' prefix is used to indicate that the request is addressed
-    to the server itself (we will talk about other kinds of requests later).
-    The content length is encoded in ASCII for easier debugging.
-
-    The server should answer a request with one of the following:
-
-        1. For success, the 4-byte "OKAY" string
-
-        2. For failure, the 4-byte "FAIL" string, followed by a
-           4-byte hex length, followed by a string giving the reason
-           for failure.
-
-        3. As a special exception, for 'host:version', a 4-byte
-           hex string corresponding to the server's internal version number
-
-    Note that the connection is still alive after an OKAY, which allows the
-    client to make other requests. But in certain cases, an OKAY will even
-    change the state of the connection. 
-
-    For example, the case of the 'host:transport:<serialnumber>' request,
-    where '<serialnumber>' is used to identify a given device/emulator; after
-    the "OKAY" answer, all further requests made by the client will go
-    directly to the corresponding adbd daemon.
-
-    The file SERVICES.TXT lists all services currently implemented by ADB.
-
-
-  2. Transports:
-
-    An ADB transport models a connection between the ADB server and one device
-    or emulator. There are currently two kinds of transports:
-
-       - USB transports, for physical devices through USB
-
-       - Local transports, for emulators running on the host, connected to
-         the server through TCP
-
-    In theory, it should be possible to write a local transport that proxies
-    a connection between an ADB server and a device/emulator connected to/
-    running on another machine. This hasn't been done yet though.
-
-    Each transport can carry one or more multiplexed streams between clients
-    and the device/emulator they point to. The ADB server must handle
-    unexpected transport disconnections (e.g. when a device is physically
-    unplugged) properly.