adb概覽及協議參考，adb概覽協議參考

adb概覽及協議參考，adb概覽協議參考

原文：https://github.com/android/platform_system_core/blob/master/adb/OVERVIEW.TXT）

Implementation notes regarding ADB.

ADB實現註解

1. General Overview:

1概要

The Android Debug Bridge (ADB) is used to:

ADB在以下情況下使用：

• keep track of all Android devices and emulators instances connected to or running on a given host developer machine
• 對所有串連到開發機器上的android真機和模擬器進行跟蹤管理
• 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.
• 實現了大量的控制命令（比如: "adb shell", "adb pull",等等）來方便使用者使用（包括命令列使用者和助手類程式如ddms),這些命令往往被我們叫做adb中的一個‘服務’。

As a whole, everything works through the following components:

總而言之，所有的事情都是圍繞著以下這幾個模組進行的：

1.1 The ADB server

1.1 ADB伺服器

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.

這是在主機裝置(PC/開發機器)上啟動並執行一個後台進程。它的目的是嗅探何時有裝置在主機的usb口上掛載/移除，以及模擬器何時開啟/關閉。

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).

因此它會維護著一個"已串連裝置"列表，並且為每個裝置指定一個‘狀態’：OFFLINE, BOOTLOADER, RECOVERY 或 ONLINE (下文會詳述）。

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.

ADB伺服器確實可以稱為是一個強大的多路路由，它的目的就是去協調組織用戶端，各種服務和裝置之間的資料交換(資料包，真實資料)。

1.2 The ADB daemon (adbd)1.2 ADB守護進程(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.

adbd是一個在android真實機器或者模擬器上啟動並執行後台伺服程式。它的目的是為了串連pc端的adb伺服器（真實機器用usb，模擬器用tcp協議（譯者註：其實真實機器也可以用tcp來串連，這篇文章沒有及時更新過來））並且為在主機pc上啟動並執行adb用戶端應用提供一些服務。

The ADB server considers that a device is ONLINE when it has successfully 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.

當adb伺服器成功串連上android機器上的adbd伺服程式的時候就會認為該裝置已經online，否者就會認為該裝置是offline，指的是adb伺服器有檢測到一個新的裝置串連上來，但是卻沒有成功串連上該裝置的的adbd。

the BOOTLOADER and RECOVERY states correspond to alternate states of devices when they are in the bootloader or recovery mode.

BOOTLOADER和RECOVERY著兩個狀態分別代表android裝置處於bootloader或者recovery模式下的對應的可選狀態。

1.3. The ADB command-line client1.3 ADB命令列用戶端

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.

adb命令列用戶端是給shell或者指令碼調用來跑各種adb命令的。它首先會嘗試找到主機pc上啟動並執行adb伺服器，如果沒有找到的話就會自動啟動一個adb伺服器。

then, the client sends its service requests to the ADB server. It doesn't need to know.

然後該adb命令列用戶端會往adb伺服器發送服務要求，而這些對於adb伺服器來說是無需知道的。

Currently, a single 'adb' binary is used for both the server and client. this makes distribution and starting the server easier.
就當前來說，adb伺服器和adb用戶端使用的其實是同一個二進位檔案，這樣使得發布和啟動伺服器會更方便。

1.4. Services1.4. 服務

There are essentially two kinds of services that a client can talk to.

本質上一個adb命令列用戶端會和兩類服務進行通訊。

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.

主機服務：這些服務是在adb伺服器自身內部啟動並執行所以根本不需要和任何的android裝置進行互動。一個典型的命令就是列出當前串連的所有android裝置和狀態的命令“adb devices”。 當然還有一些其他的服務了。

命令	解釋
host:version
host:kill	停止server
host:devices
host:track-devies
host:emulator:<port>
host:transport:<serial-number>	串連指定serial-number的裝置或者模擬器
host:transport-usb	串連usb上的裝置，如果usb上有不止一個裝置，會失敗。
host:transport-local	通過tcp方式串連模擬器，如果有多個模擬器在運行，會失敗。
host:transport-any	串連usb裝置或者模擬器都可以，但是如果有超過一個裝置或模擬器，會失敗。
host-serial:<serial-number>:<request> host-usb:<request> host-local:<request>	向指定的裝置發送特定的請求。同樣如果存在多個裝置的衝突，會失敗。
host:<request>	向當前串連的裝置發送請求
<host-prefix>:get-serialno	擷取裝置的serial-number
<host-prefix>:get-state	擷取裝置狀態
<host-prefix>:forward:<local>;<remote>

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.

本地服務：這類服務是在adbd這個守護進程自身內部啟動並執行，或者是由它啟動啟動並執行。adb伺服器會在用戶端和這些adbd中啟動並執行服務之間進行資料路由。在這種情況下adb伺服器扮演著初始化各種串連以及資料路信使的角色。

命令	解釋
shell:command arg1 arg2 ...	在裝置上執行命令列操作
shell:	參見commandline.c中的interactive_shell()
remount:	以讀/寫入模式載入裝置的檔案系統
dev:<path>	為client開啟裝置上的特定路徑，用於讀寫問題。有可能由於許可權問題而失敗。
tcp:<port>	嘗試從裝置串連本主機的某個tcp連接埠
tcp:<port>:<server-name>	嘗試從裝置串連特定主機名稱的某個tcp連接埠
local:<path>	嘗試串連裝置上的特定路徑，路徑是UNIX網域名稱形式
localreserved:<path> localabstract:<path> localfilesystem:<path>	嘗試串連裝置上的特定路徑。
log:<name>	開啟裝置上的特定記錄檔，以便讀取日誌
framebuffer:	嘗試擷取framebuffer的快照。即涉筆的螢幕快照
dns:<server-name>	由serer執行來解析特定裝置名稱
recover:<size>	更新裝置的恢複鏡像
jdwp:<pid>	串連特定VM進程上面的JDWP線程
track-jdwp
sync:	同步裝置和主機上的檔案

（註：以上兩表整理來自網友 arm-linux：http://www.cnblogs.com/armlinux/archive/2011/02/16/2396845.html）

2 Protocol details:

2 協議細節

2.1 Client <-> Server protocol:

2.1 用戶端<--->伺服器端

This details the protocol used between ADB clients and the ADB server itself. The ADB server listens on TCP:localhost:5037.

以下細節描述的是主機pc中adb用戶端和adb伺服器端通訊用到的協議。adb伺服器端會監聽TCP:localhost:5037

A client sends a request using the following format:
用戶端使用以下的協議格式發送請求:

• 1. A 4-byte hexadecimal string giving the length of the payload
• 1. 前面是一個4位元組的十六進位用來指定請求命令的長度
• 2. Followed by the payload itself.
• 2. 緊跟著請求命令自身的內容

For example, to query the ADB server for its internal version number, the client will do the following:

比如，為了得到adb伺服器的組建號，用戶端會做以下動作：

• 1. Connect to tcp:localhost:5037
• 1. 串連到 tcp:localhost:5037
• 2. Send the string "000Chost:version" to the corresponding socket
• 2. 發送字串"000Chost:version"到對應通訊端（譯者註：十六進位000C就是十進位12，"host:version"剛好12個位元組)

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.

'host'這個首碼是用來指定這個請求是發送給伺服器自身的（我們晚點會談下其他的請求類型），為了方便調試，請求內容長度是用ASCII編碼的。

The server should answer a request with one of the following:

伺服器端將會用以下的一種方式進行應答：

• 1. For success, the 4-byte "OKAY" string
• 1. 成功：應答一個4位元組的"OKAY"字串
• 2. For failure, the 4-byte "FAIL" string, followed by a 4-byte hex length, followed by a string giving the reason for failure.
• 2.失敗：應答一個4位元組的"FAIL"字串，緊跟著一個4位元組十六進位描述錯誤描述內容長度，然後是描述錯誤的內容字串。
• 3. As a special exception, for 'host:version', a 4-byte hex string corresponding to the server's internal version number
• 3. 例外:'host:version'的返回將會是一個4位元組字串代表著伺服器的組建號。

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.

注意用戶端和伺服器端的串連在接收到OKAY的應答後將會繼續保持，以便用戶端繼續其他請求。但在一些特定的情況下，OKAY應答會改變串連的狀態。

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.

比如，以命令'host:transport:<serialnumber>‘請求為例（其中　'<serialnumber>'用來指定一個指定的裝置/模擬器），收到'OKAY'應答後，用戶端往後的所有請求都將會直接發送到對應的裝置/模擬器的adbd守護進程。

The file SERVICES.TXT lists all services currently implemented by ADB.

檔案SERVICES.TXT列出了adb當前已經實現的所有服務（譯者註：大家請自行google）。

2.2. Transports:

An ADB transport models a connection between the ADB server and one device or emulator. There are currently two kinds of transports:

adb傳輸指的是adb伺服器和一個裝置/模擬器之間的串連模型。當前有以下兩種傳輸模型：

• USB transports, for physical devices through USB
• USB傳輸：真實機器通過usb串連的情況下
• Local transports, for emulators running on the host, connected to the server through TCP
• 本地傳輸：本機上的模擬器通過tcp串連到adb伺服器的情況下

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.

理論上說，我們可以編寫一個本地啟動並執行傳輸代理來處理adb伺服器和串連/運行在其他主機pc上的裝置/模擬器的串連，但這個還沒有實現。

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.

每一種傳輸方式都可以承載多路用戶端和其指定的裝置/模擬器之間的資料流傳輸。adb伺服器必須合理的處理傳輸斷開等異常（比如：當一個裝置從pc主機上拔掉的情況）

怎在android應用裡執行adb 命令

ADB介面的作用主要是讓電腦等其它裝置控制安卓系統的，所以，稱為“中間橋”；
不是為安卓自已用的，自已可直接執行稱為SHELL，這與ADB無關。
所以安卓JAVA不一定有封裝的ADB類。電腦上有ADB服務程式，連接埠5037，
它是中間程式，與安卓系統上守護進程（Daemon）通訊。
如果要在自已的手機上應該也能執行adb命令，應該直接跟守護進程
（Daemon）通訊了。百度上可以搜到的方法並不滿意。

樓主用exec執行CMD命令，這已不是ADB介面了，這是系統的SHELL了！！！

自已用socket/tcp直接發命令效果不知怎樣，地址用127.0.0.1, 安卓daemon進程的連接埠
5555 是奇數開始。
。。。 。至於ADB對話協議百度可以搜到，建議試一試。

樓上其實要的是SHELL，並不是ADB，我搜到一篇文章，但我並沒有試過，
是否需要ROOT，不得而知，附上，你試一試 ，回個話。
滿意就採納！


 
adblog是什檔案

adb的log檔案，系統產生的，供開發人員調試參考用。
如果不是開發人員，這個檔案可以刪除。