Transferred from: http://my.oschina.net/xuwa/blog/1574
The Android Debug Bridge (ADB) is a versatile tool that can help you manage the state of your device or emulator.
You can join ADB in the following ways:
- Run the shell command on the device
- To manage the emulator or device via port forwarding
- Copy or copy files from a simulator or device
The following is an introduction to ADB and describes common uses.
Contents
-
Profile
-
Issue adb command
-
Query Simulator/Device instance
-
Send commands to a specific simulator/device instance
-
Installing the Software
-
Forwarding Port
-
Copy or copy files from simulator/device
-
ADB command List
-
Start shell command
-
connect to the database by running sqllite3 from the remote shell side
-
ui/Software test program Monkey
-
Other shell commands
-
Enable Logcat logging
-
using the Logcat command
-
filtering log Output
-
control log Output format
-
View available Log buffers
-
View stdout and stderr
-
logcat Command List
-
Stop ADB Service
Profile
Android debugging system is a face to customer service system, including three components:
- A client that runs on the computer you are using to develop the program. You can start the client by using the ADB command on the shell side. Other Android tools such as ADT plug-ins and Ddms can also generate ADB clients.
- A server running as a background process on the machine you are using to send. The server is responsible for managing the communication between the client and the ADB Daemon (daemon) running on the emulator or device.
- A daemon (daemon) that runs in the form of a background process on the emulator or device.
When you start an ADB client, the client first confirms that an ADB service process is already running. If not, the service process is started. When the server is running, the ADB server binds to the local TCP port 5037 and listens to the commands sent by the ADB client-all ADB clients talk to the ADB server using port 5037.
The server then establishes a connection to all running emulators or device instances. It locates all simulators or devices by scanning all odd ports within the range of 5555 to 5585. Once the server has found the ADB daemon, it will establish a connection to that port. Note that any emulator or device instance will get two contiguous ports-an even port for the corresponding console connection, and an odd port to respond to the ADB connection. For example:
Simulator 1, console: Port 5554
Simulator 1,ADB Port 5555
Console: Port 5556
ADB Port 5557 ...
As shown above, the emulator instance connects to ADB via Port 5555, just as with the 5554 Port connection console.
Once the server is connected to all emulator instances, you can use the ADB command to control and access the instance. Because the server manages the connection of the emulator/device instance, and controls the processing of commands from multiple ADB clients, you can control any emulator or device instance through any client (or script).
The following sections describe the status of using ADB and the Management emulator/device through commands. It is important to note that if you use an eclipse with the ADT plugin to develop an Android program, you do not need to use ADB from the command line. The ADT plugin has transparently integrated adb into eclipse, and of course you can still use ADB directly if necessary, such as debugging.
Issue adb command
Issue Android Commands: You can publish Android commands on the command line or script on your development machine using the method:
When you issue a command, the system enables the Android client. The client is not related to the emulator instance, so if the dual server/device is running, you need to use -d
the option to determine the target instance for the command that should be controlled. For more information on using this option, you can view the simulator/Device Instance Terminology control command.
Query Simulator/Device instance
Before issuing the ADB command, it is necessary to know what emulator/device instance is connected to the ADB server. devices
a series of associated emulators/devices can be obtained by using commands:
ADB devices
? In response, ADB has developed the appropriate status information for each instance:
- ? Serial number-A string created by ADB that
<type>-<consolePort>
uniquely identifies an emulator/device instance through its own control port. Here is an example of a serial number:emulator-5554
- The connection state of the instance has three states:
offline
-this instance is not connected to ADB or is not responding.
device
-this instance is connected to the ADB server. Note that this state does not fully represent the operation and operation of the Android system, so this instance is connected to the ADB when the system is running. However, after the system is booted, it is the state of a simulator/device that is running normally.
The output for each instance has the following fixed format:
[SerialNumber] [State]
Here is an devices
example of displaying commands and outputs:
$ adb deviceslist of devices attached emulator-5554 deviceemulator-5556 deviceemulator-5558 device
If no emulator/device is currently running, ADB returns no device
.
Send commands to a specific simulator/device instance
If more than one emulator/device instance is running, you need to specify a target instance when you publish the ADB command. To do this, use -s
the Options command. The options that -s
are used are
As shown above, a target instance is specified for a command that uses the serial number assigned by ADB. You can use the devices
command to get the serial number of the emulator/device instance running
Examples are as follows:
Adb-s emulator-5556 Install helloworld.apk
Note that if you do not specify a target emulator/device instance to execute -s
This command, the ADB generates an error.
Installing the Software
You can use ADB to copy an application from your development computer and install it on an emulator/device instance. Like this, use the install
command. This install
command requires you to specify the path to the. apk file that you want to install:
ADB install <path_to_apk>
To get more information on how to create an. apk file that can be installed on an emulator/device instance, refer to the Android Asset packaging Tool (AAPT).
Note that if you are using the Eclipse IDE and you have already installed the ADT plugin, you do not need to use ADB (or AAPT) to install the emulator/device application directly. Otherwise, the ADT plugin handles the packaging and installation of the application on your behalf.
Forwarding Port
You can use the forward
command to forward any port-a specific host port of one emulator/device instance to a forwarding request to another different port. The following shows how to establish a forwarding from host port 6100 to emulator/device port 7100.
ADB forward tcp:6100 tcp:7100
Similarly, you can use ADB to create a UNIX domain socket interface named abstract, as shown in the following procedure:
Copy or copy files from simulator/device
You can use the ADB pull
push
command to copy files to a data file for an emulator/device instance or to copy from a data file. The install
command copies only one. apk file to a specific location, unlike the pull
command that push
allows you to copy arbitrary directories and files to any location on an emulator/device instance.
To copy a file or directory from a simulator or device, use the following (life):
ADB pull <remote> <local>
To copy a file or directory to an emulator or device, use (command below)
ADB push <local> <remote>
In these commands, and respectively, the path to the <local>
<remote>
destination file/directory on your own development machine (local) and simulator/device instance (remote)
Here's an example:
ADB push Foo.txt/sdcard/foo.txt
ADB command List
The following table lists all the commands supported by ADB and describes their meanings and how they are used.
Category
Command
Description
Comments
Options
-d
Manage ABD only via USB interface.
If you do not just use the USB interface to manage it, the error is returned.
-e
Manage adb only through simulator instances.
Returns an error if it is not managed only by the emulator instance.
-s <serialNumber>
The command is sent via the allowed command number of the simulator/device to manage the ADB (e.g. "emulator-5556").
If no number is specified, an error will be given.
General
devices
View a list of all the facilities that connect to the simulator/device.
Find out more about querying for Emulator/device Instances.
help
View all the commands supported by ADB:
version
View the version number of ADB.
Debug
logcat [<option>] [<filter-specs>]
Output the log data to the screen.
bugreport
View bug reports, such as dumpsys
, dumpstate
, and logcat
information.
jdwp
View the available JDWP information for the specified facility.
You can use forward jdwp:<pid>
port mapping information to connect to the specified JDWP process. For example:
adb forward tcp:8000 jdwp:472
jdb -attach localhost:8000
Data
install <path-to-apk>
Install Android for (can simulator/facility data file. APK specifies the full path).
pull <remote> <local>
Copies the specified files from the emulator/facility to the computer.
push <local> <remote>
Copies the specified file from the computer to the emulator/device.
Ports and Networking
forward <local> <remote>
Remote connection Simulator/facility using the socket method with a locally specified port
The port needs to describe the following information:
tcp:<portnum>
local:<UNIX domain socket name>
dev:<character device name>
jdwp:<pid>
ppp <tty> [parm]...
To run PPP via USB:
<tty>
-the TTY for PPP stream. For example dev:/dev/omap_csmi_ttyl
.
[parm]...
&mdash zero or more PPP/PPPD options, such as defaultroute
, local
, notty
, etc.
Need to remind you that the PDP connection cannot be started automatically.
Scripting
get-serialno
View the serial number of the ADB instance.
See querying for Emulator/device Instances to get more information.
get-state
View the current status of the simulator/facility.
wait-for-device
If the device is not online, it is not allowed to execute,--that is, when the instance state is device
.
You can reprint the command in the ADB command in advance, and commands in the command will not execute other commands until the emulator/device is connected. Examples are as follows:
ADB wait-for-device Shell Getprop
It is necessary to note that these commands do not start the ADB until all systems start up, so you cannot perform any other commands until all the systems start up. For example: using
install
When you need the Android package, these packages will only be fully booted from the system. For example:
ADB wait-for-device Install <app>.apk
The above command is only connected to the emulator/device connection on which the ADB service will be executed, and an error occurs before the Android system is fully booted.
Server
start-server
Select whether the service starts the ADB service process.
kill-server
Terminates the ADB service process.
Shell
shell
Control emulator/Device instances with remote shell commands.
View more information for more information.
shell [<shellCommand>]
The connection Simulator/facility executes the shell command and exits the remote shell-side L after execution is complete.
Start shell command
The ADB provides the shell side, through the shell side you can run various commands on the emulator or device. These commands are stored in the file system of the local emulator or device in 2 binary form:
/system/bin/...
Whether or not you fully enter the ADB remote shell of the simulator/device, you can shell
command to execute the command.
When not fully entering the remote shell, use the shell
command to execute a command:
adb [-d|-e|-s {<serialnumber>}] Shell <shellCommand>
When you do not use the remote shell side in the simulator/device, this uses the shell
life:
adb [-d|-e|-s {<serialnumber>}] Shell
The CTRL+D
exit
shell remote connection can be exited either by operation or by.
Some of the following will tell you more about shell commands.
Connect to the database by running sqllite3 from the remote shell side
With the ADB remote shell side, you can manage the database through the Android Soft sqlite3 command program. The sqlite3
tool contains a number of commands, such as displaying the contents of a .dump
table, and .schema
displaying the SQL create result set for a table space that already exists. Sqlite3 also allows you to execute SQL commands remotely.
By sqlite3
logging in to the remote shell side of the simulator as described in the previous sections, and then starting the tool you can use the sqlite3
command. When sqlite3
you start, you can also specify the full path of the database you want to view. The emulator/Device instance saves the SQLite3 database in the folder. /data/data/<package_name> /databases /
.
Examples are as follows:
$ adb-s emulator-5554 shell# sqlite3/data/data/com.example.google.rss.rssexample/databases/rssitems.dbsqlite Version 3.3.12Enter ". Help" for instructions .... Enter commands, then quit ...
When you start Sqlite3, you can send it through the shell sqlite3
and command it. Use exit
or CTRL+D
exit the ADB remote shell side.
ui/Software test program Monkey
When the monkey program is running in a simulator or device, it generates random pulses when a user starts a click, touch, gesture, or some system-level event, so you can use monkey to load test your software with a random, repetitive approach.
The simplest way is to use monkey with the following command, which will launch your software and trigger 500 events.
$ adb shell monkey-v-P Your.package.name 500
For more information about command Monkey commands, you can view ui/application exerciser Monkey documentation page.
Document page
Other shell commands
The following table lists some of the Adbshell commands, and if you need all the commands and programs, you can start the emulator instance and use the adb -help
command.
ADB Shell Ls/system/bin
Help is available for large-department orders.
Shell Command
Description
Comments
dumpsys
Clears the system data from the screen N.
The Dalvik debug Monitor Service (DDMS) tool provides complete debugging,.
dumpstate
Clears the status of a file.
logcat [<option>]... [<filter-spec>]...
The information log is started and is output to the screen.
dmesg
Output the main debugging information to the screen.
start
Start or restart an emulator/device instance.
stop
Close an emulator/device instance.
Enable Logcat logging
The Android log system provides the ability to record and view system debug information. Logs are recorded from a variety of software and some system buffers, and buffers can be logcat
viewed and used by commands.
Using the Logcat command
You can use logcat
the command to view the contents of the System log buffer:
[ADB] logcat [<option>] ... [<filter-spec>] ...
See the listing of Logcat command Options for a detailed description of LOGCAT commands.
You can also use commands on your computer or on the remote ADB shell that runs on the emulator/device, or you logcat
can view the log output on your computer.
$ adb Logcat
You also use this:
# Logcat
Filtering log output
Each output of the Android log information has a label and its priority.
- The label of the log is a brief indication of the original information of the system part. (For example, "View" is to view the system's label).
- Priority has the following concentrations, which are arranged smoothly from low to High:
V
-verbose (Lowest priority)
D
-debug
I
-info
W
-warning
E
-error
F
-fatal
S
-silent (highest priority, on which nothing is ever printed)
In the first two columns of information you can see logcat
the list of tags and the priority level when you run Logcat, which is labeled as: <priority>/<tag>
.
Here is an example of a logcat output, which has the precedence of I, the tag is activitymanage:
I/activitymanager ( 585): Starting activity:intent {action=android.intent.action ...}
In order for the log output to reflect the level of management, you can also use filters to control the log output, and filters can help you describe the system's label level.
The filter statement is described in the following format as tag:priority ...
tag
a label, which priority
is the lowest level of reporting for the label. You can get the priority of the log from the tag above. You can write multiple times in a filter tag:priority
.
These instructions are only to the blank end. Here is an example that shows support for all log information except those labeled "Activitymanager" and the priority "Info" above and labeled "MYAPP" and Priority "Debug" above. The priority report is the tag.
ADB logcat activitymanager:i Myapp:d *:s
The last element of the expression above, *:S
is to set all the labels as "silent", all logs only show "View" and "MyApp", *:S
another use is to be able to ensure that the log output is in accordance with the filter description limit, Also let the filter output to the log as an item.
The following filter statements refer to log information that shows priority warning or higher:
ADB logcat *:w
If you are running on your computer logcat
, you can also ANDROID_LOG_TAGS
set the default filter for environment variables: Enter a parameter compared to the remote Adbshell side.
Export android_log_tags= "activitymanager:i Myapp:d *:s "
It is important to note that ANDROID_LOG_TAGS
if the filter is running through a remote shell logcat
or running the adb shell logcat
emulator/device, the log cannot be output.
Control log Output format
The log information includes many metadata fields including labels and precedence. You can modify the output format of the log so that a specific metadata field can be displayed. Information about -v
the output log can be formatted with the option.
brief
-display Priority/tag and PID of originating process (the default format).
process
-display PID only.
tag
-display the Priority/tag only.
thread
-display Process:thread and Priority/tag only.
raw
-display the raw log message with and no other metadata fields.
time
-display the date, invocation time, Priority/tag, and PID of the originating process.
long
-display all metadata fields and separate messages with a blank lines.
When started logcat
, you can specify the -v
output format with the option:
[ADB] logcat [-v <format>]
The following are thread
the resulting log formats:
ADB logcat-v Thread
Note that you can only have -v
options to specify the output format option.
View available Log buffers
The Android log system has a loop buffer, and not all log systems have a default loop buffer. In order to get the log information, you need to start with the -b
option logcat
. If you want to use a loop buffer, you need to see the remaining loop buffer period:
radio
-View the relevant information for the buffer.
events
-View the buffer associated with the event.
main
-View the primary log buffer
-b
How to use options:
[ADB] logcat [-b <buffer>]
The following example shows how to view the log buffer containing radio and telephony information:
ADB logcat-b Radio
View stdout and stderr
By default, the Android system has a stdout
and stderr
( System.out
and System.err
) output to /dev/null
, in the process of running the Dalvik VM, there is a system that can back up the log files. In this case, the system uses the stdout
and stderr
and the priority I to record the log information
In this way, you specify the path to the output, stop the emulator/device that is running, and then enter the log remotely by using a setprop
command
$ adb shell stop$ adb shell setprop log.redirect-stdio true$ adb shell start
System until you close the simulator/device before the settings will remain, can be added by /data/local.prop
using the emulator/device default settings
Logcat Command List
Option
Description
-b <buffer>
Load a log buffer that can be used for viewing, such as event
and radio
. The default value is main
. See Viewing alternative Log buffers specifically.
-c
Clear the Log on the screen.
-d
Output the log to the screen.
-f <filename>
Specifies the output log information <filename>
, which is the default stdout
.
-g
Outputs the specified log buffer and exits after output.
-n <count>
Sets the maximum number of logs <count>
. The default value is 4 and needs to be used with the -r
option.
-r <kbytes>
<kbytes>
output log per hour, default value of 16, needs to be -f
used with options.
-s
Set the default filter level to silent.
-v <format>
To set the log input format, the default is brief
format, to know more supported formats, see Controlling log Output format.
Stopping the ADB Server
In some cases, you may need to stop the Android debugging system from running and then restart it. For example, if the Android debugging system does not respond to commands, you can terminate the server and then restart it, which may solve the problem.
Use kill-server
to terminate the ADB server. You can restart the server with any command issued by ADB.
Turn: Android Debug Bridge (ADB) is a multi-purpose tool