Android Debugging Bridge (ADB)

Android Debugging Bridge (ADB)

Turn from: http://emck.avaw.com/?p=116

The Android Debugging Bridge (ADB) is a versatile tool that can help you manage the status of your device or emulator.

There are several ways to join the ADB: Run the shell command on the device to manage the simulator or device copy from the emulator or device or copy the file out of the port

The following is an introduction to ADB and a description of common uses. Contents Overview Issue Adb command query simulator/device instance Send command to specific simulator/device instance to install software turn the originator to copy or copy files from simulator/device Adb command list launch shell command via remote shell end-to-end Row Sqllite3 Connection Database ui/Software test program Monkey Other shell commands enable Logcat logging use Logcat command filter log output control log Output format view available log buffers view stdout and stderr LOGCA T command list stop ADB service

Summary

The Android debugging system is a customer-facing service system that includes three components: a client that runs on the computer you use to develop the program. You can start the client using the ADB command from the shell side. Other Android tools such as ADT Plug-ins and DDMS can also generate ADB clients. A server that runs as a background process on the machine you use to send it. 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 an emulator or device.

When you start a ADB client, the client first confirms that a ADB service process is running. If not, the service process is started. When the server is running, the ADB server binds the local TCP port 5037 and listens for commands from the ADB client-all ADB clients are talking to the ADB server with Port 5037.

The server then establishes a connection for all running emulators or device instances. It locates all the simulators or devices by scanning all odd ports in the range 5555 to 5585. Once the server finds the ADB daemon, it establishes a connection to that port. Note that any emulator or device instance obtains two consecutive 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 the ADB through Port 5555, just as it does with the 5554-Port connection console.

Once the server establishes a connection to all instances of the emulator, 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 state of using the ADB and managing emulators/Devices by command. Note that if you use the eclipse with the ADT plug-in to develop the Android program, you don't need to use the ADB through the command line. The ADT plugin has transparently integrated the ADB into eclipse, and, of course, you can still use the ADB directly if necessary, such as debugging.

issue adb order

Issue the Android command: You can publish the Android command on the command line or script on your development machine, using the method:

adb [-d|-e|-s <serialnumber>] <command>

When you issue a command, the system enables the Android client. The client is not associated with an emulator instance, so if the dual server/device is running, you need to use the-D option to determine the target instance for the command that should be controlled. For more information about using this option, you can view the emulator/Device Instance Terminology control commands.

Query Simulator/device instance

Before issuing the ADB command, it is necessary to know what simulator/device instance is connected to the ADB server. You can get a series of associated emulators/devices by using the devices command:

ADB devices

• In response, ADB has developed a corresponding status message for each instance: • Serial number-A string created by the ADB that uniquely identifies an emulator/device instance through its own control port <type>-<consolePort>. Here is an example of a serial number: The connection state of the emulator-5554 instance has three states: offline-This instance is not connected to the ADB or cannot be answered. device-This instance is connecting 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 started, it is the normal running state of the simulator/device state.

The output of each instance has the following fixed format:

[SerialNumber] [State]

Here is an example that shows the devices command and output:

$ ADB devices

List of devices attached

emulator-5554 Device

emulator-5556 Device

emulator-5558 Device

If no simulator/device is currently running, the ADB returns no device.

send a command to a specific emulator/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, please use the-s option command. The-s option in use is

Adb-s <serialNumber> <command>

As shown above, a target instance is specified for a command that uses the serial number assigned by the ADB. You can use the Devices command to get the serial number of the emulator/device instance that is 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 the-s command, the ADB will produce an error. Installing software

You can use ADB to copy an application from your development computer and install it in an emulator/device instance. Do it like this, using the install command. This install command requires you to specify the path to the. apk file you want to install:

ADB install <path_to_apk>

To get more information on how to create a. 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 have already installed the ADT plug-in, there is no need to use ADB (or AAPT) directly to install the application on the emulator/device. Otherwise, the ADT plugin will give you carte blanche to handle the packaging and installation of your application.

turn the mouth of the originator

You can use the forward command to forward any port--a specific host port for a simulator/device instance to forward requests to another port. The following shows how to establish forwarding from host port 6100 to simulator/device port 7100.

ADB forward tcp:6100 tcp:7100

Similarly, the ADB can be used to establish a UNIX domain socket named abstract, as shown in the following procedure:

ADB forward tcp:6100 LOCAL:LOGD

copy or copy a file from an emulator/device

You can use the Adbpull, push command to copy files to a data file in an emulator/device instance, or from a data file. The install command copies only a. apk file to a specific location, and unlike the pull and push commands, you can copy any directory and file to any location of an emulator/device instance.

To copy a file or directory from an emulator or device, using (The following life):

ADB pull <remote> <local>

Copy a file or directory to an emulator or device, using (the following command)

ADB push <local> <remote>

In these commands, <local> and <remote> refer respectively to the path to the destination file/directory on your own development machine (local) and emulator/Device instance (remote)

Here is an example:

ADB push Foo.txt/sdcard/foo.txt

adb command List

The following table lists all the commands that ADB supports and explains their meaning and how they are used.

Category	Command	Description	Comments
Options	-D	Manage ABD only via USB interface.	Returns an error if you are not only managing with a USB interface.
-E	Manage the ADB only through an emulator instance.	Returns an error if it is not managed simply through an emulator instance.
-S <serialNumber>	Manage ADB (for example: "Emulator-5556″) by sending commands to the permitted command number of the simulator/device.	If no number is specified, an error is given.
General	Devices	View a list of all facilities connected to the simulator/device.	See querying for Emulator/device instances for more information.
Help	View all the commands supported by ADB.
Version	View the ADB version serial number.
Debug	Logcat [<option>] [<filter-specs>]	Prints the log data to the screen.
Bugreport	View reports of bugs, 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 as a data file that can simulator/facility, APK specify the full path.
Pull <remote> <local>	Copies the specified files from the simulator/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 via socket method with 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] ...	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 not to automatically start PDP connection.
Scripting	Get-serialno	View the serial number of the ADB instance.	See querying for Emulator/device instances for more information.
Get-state	View the current status of the emulator/facility.
Wait-for-device	If the device does not go online, it is not allowed to execute – that is, when the instance state is device.	You can reprint the command in the ADB's command in advance, and the 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 The caveat is that these commands will not start the ADB until all systems start up and you won't be able to execute any other commands until all systems start up. For example: When using Install, Android packages are needed, and these packages are only fully activated by the system. For example: ADB wait-for-device Install <app>.apk The above command will only be executed if the ADB service is connected to the emulator/device connection, and the execution occurs before the Android system is fully booted.
Server	Start-server	Select whether the service starts the ADB service process.
Kill-server	Terminate the ADB service process.
Shell	Shell	Control the emulator/device instance through a remote shell command.	View more information for the more information.
Shell [<shellcommand>]	Connect simulator/Facility Execute shell command, quit remote shell end L after execution completes.

Start shell command

The ADB provides a shell-side through which you can run commands on an emulator or device. These commands are stored in a 2-form file system on a local emulator or device:

/system/bin/...

Regardless of whether or not you are fully on the ADB remote shell side of the simulator/device, you can execute the command with the shell command.

When you do not fully enter the remote shell, use the shell command to execute a command:

adb [-d|-e|-s {<serialnumber>}] Shell <shellCommand>

Use shell when using a remote shell end in an emulator/device:

adb [-d|-e|-s {<serialnumber>}] Shell

You can exit the shell remote connection by manipulating ctrl+d or exit.

Some of the following will tell you more about shell commands.

running the Sqllite3 connection database through the remote shell side

Through the ADB remote shell side, you can manage the database via the Android Soft sqlite3 command program. The Sqlite3 tool contains a number of commands for using, such as:. Dump displays the contents of the table,. Schema can display the SQL create result set of a table space that already exists. Sqlite3 also allows you to execute SQL commands remotely.

By Sqlite3, the remote shell side of the simulator is logged in the previous sections, and the Sqlite3 command is available for the startup tool. When Sqlite3 is started, you can also specify the full path to 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.db

SQLite version 3.3.12

Enter '. Help ' for instructions
... enter commands, then quit ...



Sqlite>. Exit

When you start Sqlite3, you can send sqlite3 through the shell, and command. Exit the ADB remote shell end with exit or Ctrl+d. ui/Software test program Monkey

When a monkey program is running on a simulator or device, it generates random pulses if the user embarks, such as clicks, touches, gestures, or some system-level events, so you can use the monkey to load test your software with random repetitive methods.

The easiest way to do this is to use monkey with the following command, which will start 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 the Ui/application exerciser Monkey documentation page.

Document pages other shell commands

The table below lists some Adbshell commands, and if you need all of the commands and programs, you can start the emulator instance and use the Adb-help command.

ADB Shell Ls/system/bin

For large department commands, help is available.

Shell Command	Description	Comments
Dumpsys	Clears system data n from the screen.	The Dalvik debug Monitor Service (DDMS) tool provides complete debugging,.
Dumpstate	Clears the state of a file.
Logcat [<option>] [<filter-spec>]	The Infolog is started and is output to the screen.
Dmesg	Outputs the primary 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 debugging information. Logs are recorded from a variety of software and some system buffers, which can be viewed and used by the Logcat command.

using the Logcat command

You can use the Logcat command to view the contents of the System log buffer:

[ADB] logcat [<option>] [<filter-spec>]

Check the listing of Logcat command Options, which has a detailed description of the Logcat commands.

You can also use the LOGCAT command on your computer or on the remote ADB shell side running on the simulator/device, or you 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 level. 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). The precedence has the following concentrations, which are arranged smoothly from lowest to highest: V-verbose (lowest priority) D-debug I-info w-warning e-error f-fatal s-silent (highes T priority, on which what is ever printed)

In the first two columns of information when you run Logcat you can see the Logcat label list and priority level, which is the:<priority>/<tag>.

The following is an example of a logcat output, and its priority seems to be I, and the label 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 the filter to control the log output, filters can help you describe the system's label level.

The filter statements are described in the following format tag:priority ..., tag is the label, priority is the lowest level of the report that represents the label. The priority of the log can be obtained from the tag above. You can write tag:priority multiple times in a filter.

These instructions are only at the end of the blank. Here is an example that supports all log information except those labeled "Activitymanager" and the Priority "Info" and the label is "MYAPP" and the priority is "Debug". Small rank, priority report for tag.

ADB logcat activitymanager:i Myapp:d *:s

The last element of the above expression, *:s, is to set all the tags as "silent" and all the logs show only "View" and "MyApp", and another use of *:s is to ensure that the log output is limited by the description of the filter, Also let the filter be output to the log as an item.

The following filtering statement refers to the display of log information with a priority of warning or higher:

ADB logcat *:w

If you run Logcat on your computer, you can also android_log_tags for environment variables by entering a parameter to set the default filter, compared to the remote Adbshell side.

Export android_log_tags= "activitymanager:i Myapp:d *:s "

Note that the Android_log_tags filter can not output logs if it runs logcat through a remote shell or runs an emulator/device using the ADB shell logcat.

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 you can display a specific metadata field. Information about the formatted output log can be obtained through the-v option. Brief-display Priority/tag and PID of the 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 and the 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 Logcat is started, you can specify the output format by using the-V option:

[ADB] logcat [-v <format>]

The following is the log format produced with thread:

ADB logcat-v Thread

Note that you can only use the-V option to specify the output format option.

View available Log buffers

The Android log system has a circular buffer, and not all log systems have a default loop buffer. In order to get the log information, you need to use the-B option to start Logcat. If you want to use a circular buffer, you need to see the remaining loop buffer period: radio-to see the relevant information for the buffer. events-view the buffer associated with the event. main-View Primary Log buffers

-B Option Usage:

[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 stdout and stderr (System.out and System.err) output to/dev/null, and in the process of running the Dalvik VM, a system can back up the log files. In this case, the system uses STDOUT and stderr and priority I. To log information.

In this way, you specify the path of the output, stop the emulator/device that is running, and then enter the log remotely by using the SetProp command

$ adb shell stop

$ adb shell SetProp Log.redirect-stdio true

$ adb shell start

System until you turn off the emulator/device, the settings remain, and you can use the default settings on the emulator/device by adding/data/local.prop

logcat Command List

-b <buffer>

Option	Description
load an available log buffer for viewing, such as event and radio. The default value is main. Specifically view viewing alternative Log buffers.
-C	clear the Log on the screen.
-D	output logs to the screen.
-f <filename>	Specifies the <filename> of the output log information, which is stdout by default.
-G	outputs the specified log buffer and exits after the 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>	output logs per <kbytes>, the default value is 16, and it needs to be used with the-f option.
-S	sets the default filtering level to silent.
-v <format>	Sets the log input format, the default is brief format, to know more supported formats, see Controlling Log Output form At.

stopping the ADB Server

In some cases, you may want to terminate the operation of the Android debugging system and then restart it. For example, if the Android debugging system does not respond to commands, you can terminate the server before restarting it, which may solve the problem.

The ADB server can be terminated with kill-server. You can restart the server with any commands issued by the ADB.