安天下

为了方便bash script执行，根据进程的名称来获取进程的PID会很有帮助。我总结到的两种方法是（这里以init这个进程为例）：

1.     ps –C init –o pid=

2.     pgrep init

以上两种方法都可以得到init进程的pid，结果为1。很显然第二种方法要简单易记得多。

 

引申一：

根据进程PID获取进程名称可以使用如下命令：

ps –p 1 –o cmd=

以上命令可以获取到PID=1的进程命令为：/sbin/init

 

引申二：

通过jobs命令可以查看当前shell下的背景程序，通过下列命令可以查看背景程序的PID：

jobs –p

这一点也对编写bash script很有帮助。

2010年马上就要结束了，这一年过得还算比较顺利，个人认为有点成就的是以下几件事：

1. 通过Android平板电脑对Android系统和ARM架构都有了一些认识和了解。2010年最火的平板电脑莫过于Apple的iPad，其次就是Samsung的Galaxy Tab了。平板真正进入到混战阶段应该是在2011年，届时，为数众多的Android的平板与Apple的iPad二代到底孰优孰劣，现在还很难预期。我很荣幸能在这个时候接触到平板与Android系统。说到平板，一定要提nVIDIA的Tegra 2，明年的平板电脑有很大一票都是以Tegra 2作为核心的，nVIDIA能否借这样一股平板风来挽救它在X86平台上的逐渐失利呢，不管结果怎样，nVIDIA肯定对此报以极大期望。目前看来，Google的Android系统在智能手机(SmartPhone)和平板电脑(SmartPad)上目前都是Apple的iOS最有力的竞争者，Microsoft的Windows Phone 7，Nokia的Meego，HP(Parm)的WebOS以及RIM的BlackBerry和Playbook，目前还处于落后和追赶的地位。我自己也买了一部Android手机，经过这么一年的接触，Android的优势和弱势我大致上都有了一些认识。

2. 自学AutoIt 3，并写了两个工具PreTest和AID。写PreTest的时候我刚学AutoIt 3，现在再看当时写的代码，很多地方都不够完美，不过好在它的功能都是OK的。写AID时，我已经开始有得心应手的感觉了，并且在一个星期之内就完成了AID的最初版本，又另外花了一个星期来完善它，补充它。到我将它交接给Mchr时，它已经非常不错了。而且它实用性很不错，有了它，我们在安装Driver时，可以节省至少20分钟时间，设备较多的机器，甚至可以节省30~40分钟。不过，我也不清楚会有多少人用到它。

3. 在学习Android的过程中进一步巩固了我的Linux。因为长时间不使用，我现在的Linux在知识面上已经不及两年前，但这一年的Android学习，也让我不时应用Linux。可以说，我的Linux熟练程度要比两年前好多了。

4. 帮助PDD的同事解决了一个因为分区错误引起的客诉，并因此帮公司避免了经济上的损失。(约人民币60万元)在这件事上，我用到了自己所学的分区、启动引导、diskpart以及批处理的知识。这个问题，严格说来，不是我所在岗位的问题，而是另外一个岗位的问题，在其他人没有更好解决方案的情况下，我首先给出了这个解决方案，并且，我所运用到的这些知识，基本都是我自学的成果，所以这件事也让我很有成就感。我的学习、能力部门内部的同事都看得到，但部门之外就少有人知，通过这件事，其他的一些人也开始认识到我。

5. 找到了一份新工作。现在的这份工作让我学到了很多东西，我的几位老板给我很大支持和鼓励，我的部门老大Blue对我非常照顾和欣赏，我所在的部门同事之间相处非常融洽，我非常舍不得这个环境。为了自己的将来，我还是决定离开。新的工作，新的挑战，希望我能够好好面对。

因为原链接被墙，所以将adb的帮助文档贴在这里，以备有人需要。

原链接地址：http://developer.android.com/guide/developing/tools/adb.html

 

Android Debug Bridge

ADB quickview

• Manage the state of an emulator or device
• Run shell commands on a device
• Manage port forwarding on an emulator or device
• Copy files to/from an emulator or device

In this document

1. Issuing ADB Commands
2. Querying for Emulator/Device Instances
3. Directing Commands to a Specific Emulator/Device Instance
4. Installing an Application
5. Forwarding Ports
6. Copying Files to or from an Emulator/Device Instance
7. Listing of adb Commands
8. Issuing Shell Commands
9. Enabling logcat Logging
10. Stopping the adb Server

See also

1. Emulator

Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device. It is a client-server program that includes three components:

• A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
• A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
• A daemon, which runs as a background process on each emulator or device instance.

When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.

The server then sets up connections to all running emulator/device instances. It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices. Where the server finds an adb daemon, it sets up a connection to that port. Note that each emulator/device instance acquires a pair of sequential ports — an even-numbered port for console connections and an odd-numbered port for adb connections. For example:

Emulator 1, console: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557 ...

As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console listens on port 5554.

Once the server has set up connections to all emulator instances, you can use adb commands to control and access those instances. Because the server manages connections to emulator/device instances and handles commands from multiple adb clients, you can control any emulator/device instance from any client (or from a script).

The sections below describe the commands that you can use to access adb capabilities and manage the state of an emulator/device. Note that if you are developing Android applications in Eclipse and have installed the ADT plugin, you do not need to access adb from the command line. The ADT plugin provides a transparent integration of adb into the Eclipse IDE. However, you can still use adb directly as necessary, such as for debugging.

Issuing adb Commands

You can issue adb commands from a command line on your development machine or from a script. The usage is:

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

When you issue a command, the program invokes an adb client. The client is not specifically associated with any emulator instance, so if multiple emulators/devices are running, you need to use the -d option to specify the target instance to which the command should be directed. For more information about using this option, see Directing Commands to a Specific Emulator/Device Instance.

Querying for Emulator/Device Instances

Before issuing adb commands, it is helpful to know what emulator/device instances are connected to the adb server. You can generate a list of attached emulators/devices using the devices command:

adb devices

In response, adb prints this status information for each instance:

• Serial number — A string created by adb to uniquely identify an emulator/device instance by its console port number. The format of the serial number is<type>-<consolePort>. Here's an example serial number: emulator-5554
• State — The connection state of the instance. Three states are supported:
  • offline — the instance is not connected to adb or is not responding.
  • device — the instance is now connected to the adb server. Note that this state does not imply that the Android system is fully booted and operational, since the instance connects to adb while the system is still booting. However, after boot-up, this is the normal operational state of an emulator/device instance.

The output for each instance is formatted like this:

[serialNumber] [state]

Here's an example showing the devices command and its output:

$ adb devices
List of devices attached 
emulator-5554  device
emulator-5556  device
emulator-5558  device

If there is no emulator/device running, adb returns no device.

Directing Commands to a Specific Emulator/Device Instance

If multiple emulator/device instances are running, you need to specify a target instance when issuing adb commands. To so so, use the -s option in the commands. The usage for the -s option is:

adb -s <serialNumber> <command> 

As shown, you specify the target instance for a command using its adb-assigned serial number. You can use the devices command to obtain the serial numbers of running emulator/device instances.

Here is an example:

adb -s emulator-5556 install helloWorld.apk

Note that, if you issue a command without specifying a target emulator/device instance using -s, adb generates an error.

Installing an Application

You can use adb to copy an application from your development computer and install it on an emulator/device instance. To do so, use the install command. With the command, you must specify the path to the .apk file that you want to install:

adb install <path_to_apk>

For more information about how to create an .apk file that you can install on an emulator/device instance, see Android Asset Packaging Tool (aapt).

Note that, if you are using the Eclipse IDE and have the ADT plugin installed, you do not need to use adb (or aapt) directly to install your application on the emulator/device. Instead, the ADT plugin handles the packaging and installation of the application for you.

Forwarding Ports

You can use the forward command to set up arbitrary port forwarding — forwarding of requests on a specific host port to a different port on an emulator/device instance. Here's how you would set up forwarding of host port 6100 to emulator/device port 7100:

adb forward tcp:6100 tcp:7100

You can also use adb to set up forwarding to named abstract UNIX domain sockets, as illustrated here:

adb forward tcp:6100 local:logd 

Copying Files to or from an Emulator/Device Instance

You can use the adb commands pull and push to copy files to and from an emulator/device instance's data file. Unlike the install command, which only copies an .apk file to a specific location, the pull and push commands let you copy arbitrary directories and files to any location in an emulator/device instance.

To copy a file or directory (recursively) from the emulator or device, use

adb pull <remote> <local>

To copy a file or directory (recursively) to the emulator or device, use

adb push <local> <remote>

In the commands, <local> and <remote> refer to the paths to the target files/directory on your development machine (local) and on the emulator/device instance (remote).

Here's an example:

adb push foo.txt /sdcard/foo.txt

Listing of adb Commands

The table below lists all of the supported adb commands and explains their meaning and usage.

Category
Command
Description
Comments

Options
-d
Direct an adb command to the only attached USB device.
Returns an error if more than one USB device is attached.

-e
Direct an adb command to the only running emulator instance.
Returns an error if more than one emulator instance is running.

-s <serialNumber>
Direct an adb command a specific emulator/device instance, referred to by its adb-assigned serial number (such as "emulator-5556").
If not specified, adb generates an error.

General
devices
Prints a list of all attached emulator/device instances.
See Querying for Emulator/Device Instances for more information.

help
Prints a list of supported adb commands.

version
Prints the adb version number.

Debug
logcat [<option>] [<filter-specs>]
Prints log data to the screen.

bugreport
Prints dumpsys, dumpstate, and logcat data to the screen, for the purposes of bug reporting.

jdwp
Prints a list of available JDWP processes on a given device.
You can use the forward jdwp:<pid> port-forwarding specification to connect to a specific JDWP process. For example:
adb forward tcp:8000 jdwp:472
jdb -attach localhost:8000

Data
install <path-to-apk>
Pushes an Android application (specified as a full path to an .apk file) to the data file of an emulator/device.

pull <remote> <local>
Copies a specified file from an emulator/device instance to your development computer.

push <local> <remote>
Copies a specified file from your development computer to an emulator/device instance.

Ports and Networking
forward <local> <remote>
Forwards socket connections from a specified local port to a specified remote port on the emulator/device instance.
Port specifications can use these schemes:

• tcp:<portnum>
• local:<UNIX domain socket name>
• dev:<character device name>
• jdwp:<pid>

ppp <tty> [parm]...
Run PPP over USB.

• <tty> — the tty for PPP stream. For exampledev:/dev/omap_csmi_ttyl.
• [parm]... — zero or more PPP/PPPD options, such as defaultroute, local,notty, etc.

Note that you should not automatically start a PPP connection.

Scripting
get-serialno
Prints the adb instance serial number string.
See Querying for Emulator/Device Instances for more information.

get-state
Prints the adb state of an emulator/device instance.

wait-for-device
Blocks execution until the device is online — that is, until the instance state isdevice.
You can prepend this command to other adb commands, in which case adb will wait until the emulator/device instance is connected before issuing the other commands. Here's an example:

adb wait-for-device shell getprop

Note that this command does not cause adb to wait until the entire system is fully booted. For that reason, you should not prepend it to other commands that require a fully booted system. As an example, the installrequires the Android package manager, which is available only after the system is fully booted. A command such as

adb wait-for-device install <app>.apk

would issue the install command as soon as the emulator or device instance connected to the adb server, but before the Android system was fully booted, so it would result in an error.

Server
start-server
Checks whether the adb server process is running and starts it, if not.

kill-server
Terminates the adb server process.

Shell
shell
Starts a remote shell in the target emulator/device instance.
See Issuing Shell Commands for more information.

shell [<shellCommand>]
Issues a shell command in the target emulator/device instance and then exits the remote shell.

Issuing Shell Commands

Adb provides an ash shell that you can use to run a variety of commands on an emulator or device. The command binaries are stored in the file system of the emulator or device, in this location:

/system/bin/...

You can use the shell command to issue commands, with or without entering the adb remote shell on the emulator/device.

To issue a single command without entering a remote shell, use the shell command like this:

adb [-d|-e|-s {<serialNumber>}] shell <shellCommand>

To drop into a remote shell on a emulator/device instance, use the shell command like this:

adb [-d|-e|-s {<serialNumber>}] shell

When you are ready to exit the remote shell, use CTRL+D or exit to end the shell session.

The sections below provide more information about shell commands that you can use.

Examining sqlite3 Databases from a Remote Shell

From an adb remote shell, you can use the sqlite3 command-line program to manage SQLite databases created by Android applications. The sqlite3 tool includes many useful commands, such as .dump to print out the contents of a table and .schema to print the SQL CREATE statement for an existing table. The tool also gives you the ability to execute SQLite commands on the fly.

To use sqlite3, enter a remote shell on the emulator instance, as described above, then invoke the tool using the sqlite3 command. Optionally, when invoking sqlite3you can specify the full path to the database you want to explore. Emulator/device instances store SQLite3 databases in the folder/data/data/<package_name>/databases/.

Here's an example:

$ 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 

Once you've invoked sqlite3, you can issue sqlite3 commands in the shell. To exit and return to the adb remote shell, use exit or CTRL+D.

UI/Application Exerciser Monkey

The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.

The simplest way to use the monkey is with the following command, which will launch your application and send 500 pseudo-random events to it.

$ adb shell monkey -v -p your.package.name 500

For more information about command options for Monkey, see the complete UI/Application Exerciser Monkey documentation page.

Other Shell Commands

The table below lists several of the adb shell commands available. For a complete list of commands and programs, start an emulator instance and use the adb -helpcommand.

adb shell ls /system/bin

Help is available for most of the commands.

Shell Command
Description
Comments

dumpsys
Dumps system data to the screen.
The Dalvik Debug Monitor Service (DDMS) tool offers integrated debug environment that you may find easier to use.

dumpstate
Dumps state to a file.

logcat [<option>]... [<filter-spec>]...
Enables radio logging and prints output to the screen.

dmesg
Prints kernel debugging messages to the screen.

start
Starts (restarts) an emulator/device instance.

stop
Stops execution of an emulator/device instance.

Enabling logcat Logging

The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command.

Using logcat Commands

You can use the logcat command to view and follow the contents of the system's log buffers. The general usage is:

[adb] logcat [<option>] ... [<filter-spec>] ...

The sections below explain filter specifications and the command options. See Listing of logcat Command Options for a summary of options.

You can use the logcat command from your development computer or from a remote adb shell in an emulator/device instance. To view log output in your development computer, you use

$ adb logcat

and from a remote adb shell you use

# logcat

Filtering Log Output

Every Android log message has a tag and a priority associated with it.

• The tag of a log message is a short string indicating the system component from which the message originates (for example, "View" for the view system).
• The priority is one of the following character values, ordered from lowest to highest priority:
• • V — Verbose (lowest priority)
  • D — Debug
  • I — Info
  • W — Warning
  • E — Error
  • F — Fatal
  • S — Silent (highest priority, on which nothing is ever printed)

You can obtain a list of tags used in the system, together with priorities, by running logcat and observing the first two columns of each message, given as<priority>/<tag>.

Here's an example of logcat output that shows that the message relates to priority level "I" and tag "ActivityManager":

I/ActivityManager(  585): Starting activity: Intent { action=android.intent.action...}

To reduce the log output to a manageable level, you can restrict log output using filter expressions. Filter expressions let you indicate to the system the tags-priority combinations that you are interested in — the system suppresses other messages for the specified tags.

A filter expression follows this format tag:priority ..., where tag indicates the tag of interest and priority indicates the minimum level of priority to report for that tag. Messages for that tag at or above the specified priority are written to the log. You can supply any number of tag:priority specifications in a single filter expression. The series of specifications is whitespace-delimited.

Here's an example of a filter expression that suppresses all log messages except those with the tag "ActivityManager", at priority "Info" or above, and all log messages with tag "MyApp", with priority "Debug" or above:

adb logcat ActivityManager:I MyApp:D *:S

The final element in the above expression, *:S, sets the priority level for all tags to "silent", thus ensuring only log messages with "View" and "MyApp" are displayed. Using *:S is an excellent way to ensure that log output is restricted to the filters that you have explicitly specified — it lets your filters serve as a "whitelist" for log output.

The following filter expression displays all log messages with priority level "warning" and higher, on all tags:

adb logcat *:W

If you're running logcat from your development computer (versus running it on a remote adb shell), you can also set a default filter expression by exporting a value for the environment variable ANDROID_LOG_TAGS:

export ANDROID_LOG_TAGS="ActivityManager:I MyApp:D *:S"

Note that ANDROID_LOG_TAGS filter is not exported to the emulator/device instance, if you are running logcat from a remote shell or using adb shell logcat.

Controlling Log Output Format

Log messages contain a number of metadata fields, in addition to the tag and priority. You can modify the output format for messages so that they display a specific metadata field. To do so, you use the -v option and specify one of the supported output formats listed below.

• 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 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 starting logcat, you can specify the output format you want by using the -v option:

[adb] logcat [-v <format>]

Here's an example that shows how to generate messages in thread output format:

adb logcat -v thread

Note that you can only specify one output format with the -v option.

Viewing Alternative Log Buffers

The Android logging system keeps multiple circular buffers for log messages, and not all of the log messages are sent to the default circular buffer. To see additional log messages, you can start logcat with the -b option, to request viewing of an alternate circular buffer. You can view any of these alternate buffers:

• radio — View the buffer that contains radio/telephony related messages.
• events — View the buffer containing events-related messages.
• main — View the main log buffer (default)

The usage of the -b option is:

[adb] logcat [-b <buffer>]

Here's an example of how to view a log buffer containing radio and telephony messages:

adb logcat -b radio

Viewing stdout and stderr

By default, the Android system sends stdout and stderr (System.out and System.err) output to /dev/null. In processes that run the Dalvik VM, you can have the system write a copy of the output to the log file. In this case, the system writes the messages to the log using the log tags stdout and stderr, both with priority I.

To route the output in this way, you stop a running emulator/device instance and then use the shell command setprop to enable the redirection of output. Here's how you do it:

$ adb shell stop
$ adb shell setprop log.redirect-stdio true
$ adb shell start

The system retains this setting until you terminate the emulator/device instance. To use the setting as a default on the emulator/device instance, you can add an entry to /data/local.prop on the device.

Listing of logcat Command Options

Option
Description

-b <buffer>
Loads an alternate log buffer for viewing, such as event or radio. The main buffer is used by default. See Viewing Alternative Log Buffers.

-c
Clears (flushes) the entire log and exits.

-d
Dumps the log to the screen and exits.

-f <filename>
Writes log message output to <filename>. The default is stdout.

-g
Prints the size of the specified log buffer and exits.

-n <count>
Sets the maximum number of rotated logs to <count>. The default value is 4. Requires the -r option.

-r <kbytes>
Rotates the log file every <kbytes> of output. The default value is 16. Requires the -f option.

-s
Sets the default filter spec to silent.

-v <format>
Sets the output format for log messages. The default is brief format. For a list of supported formats, see Controlling Log Output Format.

Stopping the adb Server

In some cases, you might need to terminate the adb server process and then restart it. For example, if adb does not respond to a command, you can terminate the server and restart it and that may resolve the problem.

To stop the adb server, use the kill-server. You can then restart the server by issuing any adb command.

Note: 以下内容是我自己的学习、理解，如果您有不同看法，欢迎批评指正。

 

根据我对Android的理解，Android系统大致支持这几种启动模式：Normal, Bootloader, Fastboot, Recovery, Factory(其中Bootloader和Fastboot也可以归为一类)，这些命名是我自己根据实际情况起的名字。这里先简单介绍一下这几种模式：

1. Normal: 即正常启动到OS的模式，对于不同的Android设备来说，一般都是按下电源键开机即可。

2. Bootloader: 即启动到Bootloader。对于Linux来说，目前最常见的Bootloader是GRUB，对Android OS来说，常见的Bootloader是uBoot，不过不同的公司会使用自己的Bootloader，比如HTC的Bootloader是HBoot。另外，Bootloader一般会分为两阶段，IPL(Initial Program Loader)和SPL(Second Program Loader)。

3. Fastboot: Fastboot是SPL的一项特殊功能，即可以通过USB将Android设备与Windows/Linux主机连接起来，然后通过Android SDK的tools目录下的工具Fastboot来对Android设备进行一些操作，比如清除userdata分区(挂载点为/data)，cache分区(挂载点为/data)，甚至是boot分区和system分区(挂载点为/system)，flash update.zip更新文件和一些.img文件。不过一般来说，即使支持Fastboot的Android设备，Fastboot默认也是被锁住的。

4. Recovery: 即启动到恢复模式，进入Recovery模式可以进行恢复出厂设置(所作操作为format /data和/cache两个分区)，执行更新update.zip(一般可以更新Bootloader/boot/Recovery/system这四种image)。

5. Factory: 即进入工厂恢复模式，该模式一般用于重烧整个ROM上的image。

6. Safe mode：安全模式。在该模式下，用户对系统的设置和安装的Apk不会加载，菜单里面也只能看到系统自带的一些apk，目前网络上关于这种模式的资料还很少。有一种观点是：当用户自己安装的Apk导致系统无法正常启动时，可以进入到安装模式下卸载这些Apk。我认为这种观点有它的道理。

 

我自己的手机是HTC Wildfire(野火)，所以下面我会以HTC Wildfire为例来讲解这几种启动模式，下面先看一下HTC Wildfire的相关实体键：

HTC Wildfire机身上有4个键，分别为电源键，音量调大键， 音量调小键以及光学键(也有人称轨迹球，拍照键)。

 

下面讲解HTC Wildfire如何进入不同启动模式(其它Android设备请自行摸索或者Google)：

1. Normal:

HTC Wildfire按一下电源键即可正常开机。

这里也提一下重启的方法：Wildfire同时按下电源键+音量调小键+光学键可以重启。

另外，在Windows/Linux下，也可以借助Android SDK的tools目录下的工具adb来操作让Android设备重启，具体命令为”adb reboot”。

 

2. Bootloader:

HTC Wildfire同时按下电源键+音量调小键开机即可进入Bootloader。下图为HTC Wildfire进入Bootloader后的画面，在该模式下，电源键相当于选择键，音量调大键相当于向上选择，音量调小键相当于向下选择。

另外，在Windows/Linux下，也可以借助Android SDK的tools目录下的工具adb来操作让Android设备进入Bootloader，具体命令为”adb reboot Bootloader”。但是，HTC Wildfire实际进入的是Fastboot。

 

3. Fastboot:

HTC Wildfire同时按下电源键+光学键开机即可进入Fastboot。下图为HTC Wildfire进入Fastboot后的画面，在该模式下，电源键相当于选择键，音量调大键相当于向上选择，音量调小键相当于向下选择。第一行的”S-ON”代表security-on，也就是Fastboot被锁住了。

 

4. Recovery:

HTC Wildfire进入Bootloader后，按音量调小键向下选择”Recovery”，然后按下电源键即可进入Recovery模式。下图为HTC Wildfire进入Recovery模式的画面(已经root过，不是Wildfire进入Recovery模式的默认画面了)，在该模式下，电源键相当于返回键，音量调大键相当于向上选择，音量调小键相当于向下选择，光学键相当于确认。

另外，在Windows/Linux下，也可以借助Android SDK的tools目录下的工具adb来操作让Android设备进入Bootloader，具体命令为”adb reboot Recovery”。

再另外，在Recovery模式下，ClockworkMod的Recovery image可以使用adb，应该是该image内置了adbd。

 

5. Factory:

HTC Wildfire同时按下电源键+音量调大键即可进入工厂模式。进入该模式时，机器会震动三下。

Ps:Wildfire的这种模式是否就是工厂模式，目前我还有得到确认。不过有一个很有意思的实验，将HTC Wildfire通过USB数据线跟Linux系统连接起来，然后在终端下使用”lsusb”命令来查看系统所认到的设备，USB设备都会有对应的Vendor ID和Device ID，分别指示设备制造商和设备ID。”lsusb”的结果就会显示这两组ID。将HTC Wildfire分别开启到这几种不同的模式，再来通过”lsusb”命令来查看这两组ID时，我们会看到以下结果：

a. Normal: 0BB4:0C8B

b. Bootloader: 0BB4:0C94

c. Fastboot: 0BB4:0FFF

d. Recovery: 0BB4:0C8B

e. Factory: 05c6:9002

可以看到，前四种模式下的Vendor ID都是0BB4，而第五种模式下确实05c6，这很有趣。事实上，0BB4是HTC的USB设备Vendor ID，而05c6则是Qualcomm的USB设备Vendor ID(可以从文末我给的链接去证实)，而HTC Wildfire采用的就是Qualcomm的芯片。所以根据硬件ID信息我推测这第五种模式应该是工厂模式，用于重烧整个ROM上的image。

 

6. Safe mode:

HTC手机在启动过程中，会出现两次HTC画面，第一次是刚开机时的静态画面，第二次是”Quiet brillliant”的动态画面。它们分别对应了Android启动过程中的Bootloader和Kernel加载阶段。

将HTC Wildfire正常开机，当画面开始显示”Quiet brillliant”的时候，长按光学键，直到机器振动一下，进入到系统下后，屏幕左下角会出现”安全模式”的字样。

想要回到普通模式，将手机重开机一次即可。

 

相关链接如下：

1. SPL: http://code.google.com/p/android-roms/wiki/SPL

2. Fastboot: http://wiki.cyanogenmod.com/index.php?title=Fastboot

3. USB ID查询：http://www.linux-usb.org/usb.ids

4. Safe mode： http://androinica.com/2010/08/06/how-to-activate-android%E2%80%99s-safe-mode-to-get-out-of-a-force-close-loop/

      将应用程序安装在SD卡上是Android 2.2(code name Froyo)新增的功能。应用程序转移到SD卡，可以很大程度地避免/data空间不足的状况。因为用户所安装的应用程序都是安装在/data分区下的(我的HTC Wildfire /data分区是175MB)，随着应用程序的数量逐渐增加，/data分区的空间势必逐渐减小，那么何不好好利用有着更大空间的SD卡呢，要知道，现在的SD卡4GB，8GB，甚至16GB都已经很普遍了。在Android 2.2上，这个功能被加入进来了。这个功能的实现很简单，但同时也有些地方需要注意一下。

      这里先介绍如何将已安装的应用程序转移到SD卡：

1. 在home页，按下menu键，然后选择”设置”，并依次进入”应用程序 –> 管理应用程序”，这时你会看到以下画面。其中第一栏的”已下载”里包含着所有由用户所安装的应用程序。

   

2. 点击”已下载”里的应用程序，如果该应用程序允许被移动到SD卡，会有一个白色可点击的”移至SD卡”按钮，点击这个按钮，系统就会将该应用程序移动到SD卡了。

   

3. 返回到”管理应用程序”界面，点击最右侧的一栏”SD卡中”，可以看到所有被移动到SD卡的应用程序。

   

 

      以下是需要注意和了解的地方：

1. 应用程序的默认安装位置是在开发过程中在manifest的”android:installLocation”里声明的，它的值可以是"preferExternal" 和"auto"。如果选择"preferExternal"，那么应用程序默认会被安装在SD卡(但如果SD卡空间不足，那么应用程序仍将被安装在ROM中)，如果是”auto”，则会由系统自动判断应用程序安装的位置。

2. 根据Android开发文档，应用程序被移动到SD卡后，应用程序的性能并不会有什么影响。但是我的疑问是：系统下的分区文件系统(一般是yaffs，yaffs2)和SD上的分区文件系统(一般是FAT32)不同，这一点也不会影响性能吗？

3. 并不是这个应用程序的所有文件都被转移到SD卡了，而是只有.apk文件被转移到SD卡，而其他的.dex，数据库等一些文件仍然会留在/data分区。

4. 转移到SD卡的应用程序只能在一个Android设备上使用，而不能拿到其他设备上使用。

5. 当用户通过USB数据线将Android设备与电脑连接起来，并且USB连接方式是”磁盘驱动器” 时，运行在SD卡上的应用程序会被立马结束。

6. 不是所有的应用程序都应当安装在SD卡上，比如输入法，动态桌面等等，详细情况请参考引文。

 

这里以estrong taskmanager为例来研究Android下App安装的位置以及App移动到SD卡的情况。

研究方法：

1. 在App安装前，安装后，移动后，分别使用adb shell ls -R <path> > <file>将对应路径下的所有文件保存下来，这里的path是/data和/mnt；

2. 通过文件比对工具(Linux下用Meld，Windows下WinMerge)对这些文件进行比对，以查看前后的差异。

以下是实验结果：

App安装后的变化

/data目录下多出文件如下：

/data/app/com.estrongs.android.taskmanager-1.apk

/data/data/com.estrongs.android.taskmanager/cache/

/data/data/com.estrongs.android.taskmanager/cache/webviewCache/

/data/data/com.estrongs.android.taskmanager/databases/

/data/data/com.estrongs.android.taskmanager/databases/webviewCache.db-journal

/data/data/com.estrongs.android.taskmanager/databases/etm_info.db

/data/data/com.estrongs.android.taskmanager/databases/webviewCache.db

/data/data/com.estrongs.android.taskmanager/databases/webview.db

/data/data/com.estrongs.android.taskmanager/shared_prefs/

/data/data/com.estrongs.android.taskmanager/shared_prefs/google_ads.xml.xml

/data/data/com.estrongs.android.taskmanager/shared_prefs/com.estrongs.android.taskmanager_preferences.xml

/data/data/com.estrongs.android.taskmanager/shared_prefs/ignore_list.xml

/data/data/com.estrongs.android.taskmanager/lib/

/data/dalvik-cache/data@app@com.estrongs.android.taskmanger-1.apk@classes.dex

另外，可能发生改变的文件有：

/data/data/com.htc.launcher/share_prefs/WidgetPackageManager.xml

App移动到SD card后的变化

/data目录减少的文件如下：

/data/app/com.estrongs.android.taskmanager-1.apk

/data目录发生变化的文件如下：

原/data/dalvik-cache/data@app@com.estrongs.android.taskmanger-1.apk@classes.dex

变成/data/dalvik-cache/mnt@asec@com.estrongs.android.taskmanger-1@pkg.apk@classes.dex

/data目录可能发生变化的文件如下：

/data/system/appwidgets.xml

/mnt目录多出的文件如下：

/mnt/asec/com.estrongs.android.taskmanager-1/

/mnt/asec/com.estrongs.android.taskmanager-1/pkg.apk

/mnt/secure/asec/com.estrongs.android.taskmanager-1.asec

 

相关链接如下：

1. Android 2.2新功能: http://www.ifanr.com/14463

2. Android APP install location(需要翻墙): http://developer.android.com/guide/appendix/install-location.html