Android ADB common directives

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. devicesa 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: install when using the Android package, these packages only the system to fully boot. 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

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

Reprinted from: http://www.javaeye.com/topic/260042

Android ADB common directives