Android development tool-ADB (Android debug Bridge) Overview

Android debug bridge (ADB) is a versatile debugging tool for Android Developers. It is indeed named the same. It builds a bridge between the developer and the target machine.

ADB usage is very simple, as long as you read the SDK documentation about ADB, (android-sdk-linux_86/docs/GUIDE/developing/tools/adb.html), and then a little exercise, basically, you can use it easily. But if you are interested in its implementation, the best way is to read the source code. Its Android 2.2 Location is:

system/core/adb

ADB is based on the slient-server architecture and consists of three parts,

1. The client runs on the development machine. You can call the ADB command in the shell. Other Android tools, such as the ADT plug-in and ddms, also include the ADB client.

2. server, as a background process, also runs on the development machine. server is responsible for managing the client and communicating with the daemon of the target machine or emulator, just like a bridge.

3. daemon: daemon runs on the daemon of the target machine or emulator.

The above paragraph was translated from the SDK. I read the ADB code and found it a little confused. Then I went to see the SDK. I thought a lot clearer when I returned the code.

ADB has powerful functions and supports multiple platforms, but its code is very streamlined, with only about 15 thousand lines. The price is rather obscure (previously understood ), the various macros that can be seen everywhere in the Code are dazzling. An important macro, adb_host, is used to distinguish between the local host and the target machine.

The client and server call ADB.

LOCAL_CFLAGS += -O2 -g -DADB_HOST=1  -Wall -Wno-unused-parameterLOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE -DSH_HISTORYLOCAL_MODULE := adb

Emulator/device calls adbd.

LOCAL_CFLAGS := -O2 -g -DADB_HOST=0 -Wall -Wno-unused-parameterLOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCELOCAL_MODULE := adbd

1. on the host side, ADB will fork a daemon (not adbd), that is, server, while the parent process continues to process client requests, all clients communicate with the server through TCP port 5037, while the server creates a local socket and remote socket. The former is used to communicate with the client, the latter is used to communicate with the remote end, And the emulator uses TCP, real device uses USB.

2. On the emulator/device side, adbd also creates a local socket and remote socket. The former communicates with the Java Virtual Machine through jdwp and the latter communicates with the host through TCP/USB.

Therefore, the entire process should be like this,

1. The client calls an ADB command.

2. The ADB process fork generates a sub-process as the server

3. The server searches for the current connected emulator/device.

4. The server receives a request from the client.

5. The server processes the request and sends the requests that cannot be processed locally to the emulator/device.

6. adbd located in the emulator/device receives the request and submits it to the corresponding Java Virtual Machine Process.

7. adbd sends the result back to the server

8. The server sends the lecture result back to the client.

For example:

___________________________________
|
| ADB server (host) |
|
Debugger <---> localsocket <-------------> remotesocket |
| ^ |
| ___________________________ | _______ |
|
Transport |
(TCP for emulator-USB for device) |
|
___________________________ | _______
|
| Adbd (device) |
| Vv |
Jdwp <======> localsocket <------------> remotesocket |
|
| ___________________________________ |