in multiple devices (simulators), you need to specify a device number when you want to view the status of one of them directly with Logcat, or when you install the app directly on the target device.
ADB devices
This command can get the serial number of the current device (serialnumber).
like a simulator, usually a emulator-5554 .
After the ADB directive, add the parameter-s <serialNumber> such as-s emulator-5554
You can specify the target of the ADB directive.
useful when multiple emulators or devices are present.
original link
http://www.iteye.com/topic/260042
Android Debug Bridge
Http://www.androidin.com/docs/reference/adb.html#sqlite
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
Overview
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
Overview
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. Say, 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:
adb [-d|-e|-s <serialnumber>] <command>
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 the-D 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. A series of associated emulators/devices can be obtained by using the devices command:
ADB devices
? In response, ADB has developed the appropriate status information for each instance:
? Serial number-a string created by ADB that uniquely identifies an emulator/device instance through its own control port <type>-<consolePort>. 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 example showing the devices command and output:
$ adb Devices
List of devices attached
emulator-5554 Device
emulator-5556 Device
emulator-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 the-s option for the 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 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 the-s 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 for one emulator/device instance forwarding requests 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:
adb forward tcp:6100 local:logd
copy or copy files from simulator/device
You can use the Adbpull, 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 and push commands that allow 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, <local> and <remote> refer to the path to the destination file/directory on their 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 only manages ABD via the USB interface. Returns an error if it is not only managed with a USB interface.
-E simply manages the ADB through a simulator instance. Returns an error if it is not managed only by the emulator instance.
- s <serialNumber> to administer the ADB (e.g. "emulator-5556") by sending commands via the allowed command number of the simulator/device. If no number is specified, an error will be given.
General devices View a list of all the facilities that connect the simulator/device. See querying for Emulator/device Instances for more information.
help view all the commands supported by ADB:
version view ADB's release sequence number.
Debug Logcat [<option>] [<filter-specs>] Output 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 the 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 of the 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 files from the computer to the emulator/device.
Ports and Networking forward <local> <remote> Remote connection of the simulator/facility port with a locally specified port via the socket method The following information needs to be described:
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, do not let the execution,--that is, when the instance state is device. You can pre-reprint commands in the ADB command, 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 the systems start up, so you cannot execute any other commands until all the systems start up. For example: When using the install, the Android package is required, and the packages are only fully activated by 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.
The shell shell controls the emulator/device instance through a remote shell command. View more information for more information.
shell [<shellcommand>] Connect simulator/Facility Execute shell command, exit 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 side of the simulator/device, you can execute the command with the shell command.
when not fully entering the remote shell, use the shell command to execute a command:
adb [-d|-e|-s {<serialnumber>}] Shell <shellCommand>
this uses the shell when not using the remote shell side in the simulator/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.
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 many use commands, such as:. Dump displays the contents of the table, and the. Schema can display the SQL create result set for the table space that already exists. Sqlite3 also allows you to execute SQL commands remotely.
by Sqlite3, log in to the remote shell of the simulator in the previous sections and start the tool to use the Sqlite3 command. When Sqlite3 is started, 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.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 side, command. Exit the ADB remote shell side with exit or ctrl+d.
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
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.
The DMESG outputs the main debugging information to the screen.
Start starts or restarts an emulator/device instance.
Stop closes 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 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>] ...
See the listing of Logcat command Options for a detailed description of LOGCAT commands.
You can also use the LOGCAT command on your computer or the remote ADB shell running on the emulator/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.
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 when you run Logcat, you can see the LOGCAT tag list and priority level, which is the:<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 statements are described in the following format tag:priority ..., tag is a label, priority is the lowest level of reporting for the label. You can get the log's precedence from the tag above. You can write tag:priority in the filter multiple times.
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 the logs are only shown with "View" and "MyApp", another use of *:s 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 run Logcat on your computer, you can also android_log_tags for environment variables: Enter a parameter to set the default filter, compared to the remote Adbshell side .
Export android_log_tags= "activitymanager:i Myapp:d *:s "
It is important to note that the Android_log_tags filter cannot output the log if it runs logcat through the remote shell or runs the emulator/device with 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 that a specific metadata field can be displayed. Information about the formatted output log can be obtained through the-v 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 Logcat is started, you can specify the output format with the-V option:
[ADB] logcat [-v <format>]
here is the log format generated with thread:
adb logcat-v thread
Note that you only have the-V option to specify the output format options.
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 logcat with the-B option. If you want to use a loop buffer, you need to see the remaining loop buffer period:
radio-View the information about the buffer.
events-View the buffer associated with the event.
main-Viewing the primary log buffer
The- B option uses the method:
[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 the priority I to record the log information.
This method specifies the path to the output, stops the emulator/device running, and then remotely enters the log by using the SetProp command
$ adb shell Stop
$ adb Shell SetProp Log.redirect-stdio true
$ adb shell start
system until you turn off the simulator/device before the settings are retained, you can use the default settings on the emulator/device by adding/data/local.prop
logcat Command List
Option Description
- b <buffer> loads 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 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 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 log per <kbytes>, default value is 16 and needs to be used with the-f option.
- s Sets the default filter level to silent.
- v <format> 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 ADB server. You can restart the server with any command issued by ADB.