博客园_You Know ,I Can Do it .

udev的实现原理（转）

2012-05-27T14:54:00Z

相对于linux来说，udev还是一个新事物。然而，尽管它03年才出现，尽管它很低调(J)，但它无疑已经成为linux下不可或缺的组件了。udev是什么？它是如何实现的？最近研究Linux设备管理时，花了一些时间去研究udev的实现。

udev是什么？u 是指user space，dev是指device，udev是用户空间的设备驱动程序吗？最初我也这样认为，调试内核空间的程序要比调试用户空间的程序复杂得多，内核空间的程序的BUG所引起的后果也严重得多，device driver是内核空间中所占比较最大的代码，如果把这些device driver中硬件无关的代码，从内核空间移动到用户空间，自然是一个不错的想法。

但我的想法并不正确，udev的文档是这样说的，

1. dynamic replacement for /dev。作为devfs的替代者，传统的devfs不能动态分配major和minor的值，而major和minor非常有限，很快就会用完了。udev能够像DHCP动态分配IP地址一样去动态分配major和minor。

2. device naming。提供设备命名持久化的机制。传统设备命名方式不具直观性，像/dev/hda1这样的名字肯定没有boot_disk这样的名字直观。udev能够像DNS解析域名一样去给设备指定一个有意义的名称。

3. API to access info about current system devices 。提供了一组易用的API去操作sysfs，避免重复实现同样的代码，这没有什么好说的。

我们知道，用户空间的程序与设备通信的方法，主要有以下几种方式，

1. 通过ioperm获取操作IO端口的权限，然后用inb/inw/ inl/ outb/outw/outl等函数，避开设备驱动程序，直接去操作IO端口。（没有用过）

2. 用ioctl函数去操作/dev目录下对应的设备，这是设备驱动程序提供的接口。像键盘、鼠标和触摸屏等输入设备一般都是这样做的。

3. 用write/read/mmap去操作/dev目录下对应的设备，这也是设备驱动程序提供的接口。像framebuffer等都是这样做的。

上面的方法在大多数情况下，都可以正常工作，但是对于热插拨(hotplug)的设备，比如像U盘，就有点困难了，因为你不知道：什么时候设备插上了，什么时候设备拔掉了。这就是所谓的hotplug问题了。

处理hotplug传统的方法是，在内核中执行一个称为hotplug的程序，相关参数通过环境变量传递过来，再由hotplug通知其它关注hotplug事件的应用程序。这样做不但效率低下，而且感觉也不那么优雅。新的方法是采用NETLINK实现的，这是一种特殊类型的socket，专门用于内核空间与用户空间的异步通信。下面的这个简单的例子，可以监听来自内核hotplug的事件。

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <ctype.h>

#include <sys/un.h>

#include <sys/ioctl.h>

#include <sys/socket.h>

#include <linux/types.h>

#include <linux/netlink.h>

#include <errno.h>

static int init_hotplug_sock(void)

{

struct sockaddr_nl snl;

const int buffersize = 16 * 1024 * 1024;

int retval;

memset(&snl, 0x00, sizeof(struct sockaddr_nl));

snl.nl_family = AF_NETLINK;

snl.nl_pid = getpid();

snl.nl_groups = 1;

int hotplug_sock = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);

if (hotplug_sock == -1) {

printf("error getting socket: %s", strerror(errno));

return -1;

}

/* set receive buffersize */

setsockopt(hotplug_sock, SOL_SOCKET, SO_RCVBUFFORCE, &buffersize, sizeof(buffersize));

retval = bind(hotplug_sock, (struct sockaddr *) &snl, sizeof(struct sockaddr_nl));

if (retval < 0) {

printf("bind failed: %s", strerror(errno));

close(hotplug_sock);

hotplug_sock = -1;

return -1;

}

return hotplug_sock;

}

#define UEVENT_BUFFER_SIZE 2048

int main(int argc, char* argv[])

{

int hotplug_sock = init_hotplug_sock();

while(1)

{

char buf[UEVENT_BUFFER_SIZE*2] = {0};

recv(hotplug_sock, &buf, sizeof(buf), 0);

printf("%s/n", buf);

}

return 0;

}

编译：

gcc -g hotplug.c -o hotplug_monitor

运行后插/拔U盘，可以看到：

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/usbdev2.2_ep00

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0

add@/class/scsi_host/host2

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep81

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep02

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep83

add@/class/usb_device/usbdev2.2

add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/host2/target2:0:0/2:0:0:0

add@/class/scsi_disk/2:0:0:0

add@/block/sda

add@/block/sda/sda1

add@/class/scsi_device/2:0:0:0

add@/class/scsi_generic/sg0

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep81

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep02

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/usbdev2.2_ep83

remove@/class/scsi_generic/sg0

remove@/class/scsi_device/2:0:0:0

remove@/class/scsi_disk/2:0:0:0

remove@/block/sda/sda1

remove@/block/sda

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/host2/target2:0:0/2:0:0:0

remove@/class/scsi_host/host2

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0

remove@/class/usb_device/usbdev2.2

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1/usbdev2.2_ep00

remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-1

udev的主体部分在udevd.c文件中，它主要监控来自4个文件描述符的事件/消息，并做出处理：

1. 来自客户端的控制消息。这通常由udevcontrol命令通过地址为/org/kernel/udev/udevd的本地socket，向udevd发送的控制消息。其中消息类型有：

l UDEVD_CTRL_STOP_EXEC_QUEUE 停止处理消息队列。

l UDEVD_CTRL_START_EXEC_QUEUE 开始处理消息队列。

l UDEVD_CTRL_SET_LOG_LEVEL 设置LOG的级别。

l UDEVD_CTRL_SET_MAX_CHILDS 设置最大子进程数限制。好像没有用。

l UDEVD_CTRL_SET_MAX_CHILDS_RUNNING 设置最大运行子进程数限制(遍历proc目录下所有进程，根据session的值判断)。

l UDEVD_CTRL_RELOAD_RULES 重新加载配置文件。

2. 来自内核的hotplug事件。如果有事件来源于hotplug，它读取该事件，创建一个udevd_uevent_msg对象，记录当前的消息序列号，设置消息的状态为EVENT_QUEUED,然后并放入running_list和exec_list两个队列中，稍后再进行处理。

3. 来自signal handler中的事件。signal handler是异步执行的，即使有signal产生，主进程的select并不会唤醒，为了唤醒主进程的select，它建立了一个管道，在signal handler中，向该管道写入长度为1个子节的数据，这样就可以唤醒主进程的select了。

4. 来自配置文件变化的事件。udev通过文件系统inotify功能，监控其配置文件目录/etc/udev/rules.d，一旦该目录中文件有变化，它就重新加载配置文件。

其中最主要的事件，当然是来自内核的hotplug事件，如何处理这些事件是udev的关键。udev本身并不知道如何处理这些事件，也没有必要知道，因为它只实现机制，而不实现策略。事件的处理是由配置文件决定的，这些配置文件即所谓的rule。

关于rule的编写方法可以参考《writing_udev_rules》，udev_rules.c实现了对规则的解析。

在规则中，可以让外部应用程序处理某个事件，这有两种方式，一种是直接执行命令，通常是让modprobe去加载驱动程序，或者让mount去加载分区。另外一种是通过本地socket发送消息给某个应用程序。

在udevd.c:udev_event_process函数中，我们可以看到，如果RUN参数以”socket:”开头则认为是发到socket，否则认为是执行指定的程序。

下面的规则是执行指定程序：

60-pcmcia.rules: RUN+="/sbin/modprobe pcmcia"

下面的规则是通过socket发送消息：

90-hal.rules:RUN+="socket:/org/freedesktop/hal/udev_event"

hal正是我们下一步要关心的，接下来我会分析HAL的实现原理。

本文链接

I/O端口和I/O内存

2012-05-25T09:57:00Z

CPU对外设IO端口物理地址的编址方式有两种：一种是I/O映射方式（I/O－mapped），另一种是内存映射方式（Memory－mapped）.

有些体系结构的CPU（如，PowerPC、m68k等）通常只实现一个物理地址空间（RAM）。在这种情况下，外设I/O端口的物理地址就被映射到CPU的单一物理地址空间中，而成为内存的一部分。此时，CPU可以象访问一个内存单元那样访问外设I/O端口，而不需要设立专门的外设I/O指令。这就是所谓的"内存映射方式"（Memory－mapped）。

　而另外一些体系结构的CPU（典型地如X86）则为外设专门实现了一个单独地地址空间，称为"I/O地址空间"或者"I/O端口空间"。这是一个与CPU地RAM物理地址空间不同的地址空间，所有外设的I/O端口均在这一空间中进行编址。CPU通过设立专门的I/O指令（如X86的IN和OUT指令）来访问这一空间中的地址单元（也即I/O端口）。这就是所谓的"I/O映射方式"（I/O－mapped）。与RAM物理地址空间相比，I/O地址空间通常都比较小，如x86 CPU的I/O空间就只有64KB（0－0xffff）。这是"I/O映射方式"的一个主要缺点。

Linux将基于I/O映射方式的或内存映射方式的I/O端口通称为"I/O区域"（I/O region）。

===============================================================================

1、外设都是通过读写设备上的寄存器来进行的，外设寄存器也称为"I/O端口"，而IO端口有两种编址方式：独立编址和统一编制。而具体采用哪一种则取决于CPU的体系结构。如，PowerPC、m68k等采用统一编址，而X86等则采用独立编址。但对于Linux内核而言，它可能用于不同的CPU，所以它必须都要考虑这两种方式，于是它采用一种新的方法，将基于I/O映射方式的或内存映射方式的I/O端口通称为"I/O区域"（I/O region），不论你采用哪种方式，都要先申请IO区域：request_resource()，结束时释放它：release_resource()。
对于某一既定的系统，它要么是独立编址，也即"I/O端口"方式，外设寄存器位于"I/O空间"；要么是统一编制，也即"I/O内存"方式，外设寄存器位于"内存空间"（很多外设有自己的内存、缓冲区，外设的寄存器和内存统称"I/O空间"）。

2、对外设的访问分为IO端口访问和IO内存访问。
访问IO内存的流程是：request_mem_region() -> ioremap() -> ioread8()/iowrite8() -> iounmap() -> release_mem_region() 。
访问IO端口有2种途径，I/O映射方式（I/O－mapped）、内存映射方式（Memory－mapped）。前一种途径直接使用intb()/outb()之类的函数来读写IO端口，后一种是（为了达到接口的同一性）先把IO端口映射到IO内存（"内存空间"）：ioport_map()，再使用访问IO内存的函数来访问IO端口。

本文链接

BroadcastReceiver应用详解（转)

2012-05-21T10:27:00Z

转自：http://blog.csdn.net/liuhe688/article/details/6955668

BroadcastReceiver也就是“广播接收者”的意思，顾名思义，它就是用来接收来自系统和应用中的广播。

在Android系统中，广播体现在方方面面，例如当开机完成后系统会产生一条广播，接收到这条广播就能实现开机启动服务的功能；当网络状态改变时系统会产生一条广播，接收到这条广播就能及时地做出提示和保存数据等操作；当电池电量改变时，系统会产生一条广播，接收到这条广播就能在电量低时告知用户及时保存进度，等等。

Android中的广播机制设计的非常出色，很多事情原本需要开发者亲自操作的，现在只需等待广播告知自己就可以了，大大减少了开发的工作量和开发周期。而作为应用开发者，就需要数练掌握Android系统提供的一个开发利器，那就是BroadcastReceiver。下面我们就对BroadcastReceiver逐一地分析和演练，了解和掌握它的各种功能和用法。

首先，我们来演示一下创建一个BroadcastReceiver，并让这个BroadcastReceiver能够根据我们的需要来运行。

要创建自己的BroadcastReceiver对象，我们需要继承android.content.BroadcastReceiver，并实现其onReceive方法。下面我们就创建一个名为MyReceiver广播接收者：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
public class MyReceiver extends BroadcastReceiver {
private static final String TAG = "MyReceiver";
@Override
public void onReceive(Context context, Intent intent) {
String msg = intent.getStringExtra("msg");
Log.i(TAG, msg);
}
}

在onReceive方法内，我们可以获取随广播而来的Intent中的数据，这非常重要，就像无线电一样，包含很多有用的信息。

在创建完我们的BroadcastReceiver之后，还不能够使它进入工作状态，我们需要为它注册一个指定的广播地址。没有注册广播地址的BroadcastReceiver就像一个缺少选台按钮的收音机，虽然功能俱备，但也无法收到电台的信号。下面我们就来介绍一下如何为BroadcastReceiver注册广播地址。

静态注册

静态注册是在AndroidManifest.xml文件中配置的，我们就来为MyReceiver注册一个广播地址：

[html] view plain copy

<receiver android:name=".MyReceiver">
<intent-filter>
<action android:name="android.intent.action.MY_BROADCAST"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>

配置了以上信息之后，只要是android.intent.action.MY_BROADCAST这个地址的广播，MyReceiver都能够接收的到。注意，这种方式的注册是常驻型的，也就是说当应用关闭后，如果有广播信息传来，MyReceiver也会被系统调用而自动运行。

动态注册

动态注册需要在代码中动态的指定广播地址并注册，通常我们是在Activity或Service注册一个广播，下面我们就来看一下注册的代码：

[java] view plain copy

MyReceiver receiver = new MyReceiver();
IntentFilter filter = new IntentFilter();
filter.addAction("android.intent.action.MY_BROADCAST");
registerReceiver(receiver, filter);

注意，registerReceiver是android.content.ContextWrapper类中的方法，Activity和Service都继承了ContextWrapper，所以可以直接调用。在实际应用中，我们在Activity或Service中注册了一个BroadcastReceiver，当这个Activity或Service被销毁时如果没有解除注册，系统会报一个异常，提示我们是否忘记解除注册了。所以，记得在特定的地方执行解除注册操作：

[java] view plain copy

@Override
protected void onDestroy() {
super.onDestroy();
unregisterReceiver(receiver);
}

执行这样行代码就可以解决问题了。注意，这种注册方式与静态注册相反，不是常驻型的，也就是说广播会跟随程序的生命周期。

我们可以根据以上任意一种方法完成注册，当注册完成之后，这个接收者就可以正常工作了。我们可以用以下方式向其发送一条广播：

[java] view plain copy

public void send(View view) {
Intent intent = new Intent("android.intent.action.MY_BROADCAST");
intent.putExtra("msg", "hello receiver.");
sendBroadcast(intent);
}

注意，sendBroadcast也是android.content.ContextWrapper类中的方法，它可以将一个指定地址和参数信息的Intent对象以广播的形式发送出去。

点击发送按钮，执行send方法，控制台打印如下：

看到这样的打印信息，表明我们的广播已经发出去了，并且被MyReceiver准确无误的接收到了。

上面的例子只是一个接收者来接收广播，如果有多个接收者都注册了相同的广播地址，又会是什么情况呢，能同时接收到同一条广播吗，相互之间会不会有干扰呢？这就涉及到普通广播和有序广播的概念了。

普通广播（Normal Broadcast）

普通广播对于多个接收者来说是完全异步的，通常每个接收者都无需等待即可以接收到广播，接收者相互之间不会有影响。对于这种广播，接收者无法终止广播，即无法阻止其他接收者的接收动作。

为了验证以上论断，我们新建三个BroadcastReceiver，演示一下这个过程，FirstReceiver、SecondReceiver和ThirdReceiver的代码如下：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
public class FirstReceiver extends BroadcastReceiver {
private static final String TAG = "NormalBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = intent.getStringExtra("msg");
Log.i(TAG, "FirstReceiver: " + msg);
}
}

[java] view plain copy

public class SecondReceiver extends BroadcastReceiver {
private static final String TAG = "NormalBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = intent.getStringExtra("msg");
Log.i(TAG, "SecondReceiver: " + msg);
}
}

[java] view plain copy

public class ThirdReceiver extends BroadcastReceiver {
private static final String TAG = "NormalBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = intent.getStringExtra("msg");
Log.i(TAG, "ThirdReceiver: " + msg);
}
}

然后再次点击发送按钮，发送一条广播，控制台打印如下：

看来这三个接收者都接收到这条广播了，我们稍微修改一下三个接收者，在onReceive方法的最后一行添加以下代码，试图终止广播：

[java] view plain copy

abortBroadcast();

再次点击发送按钮，我们会发现，控制台中三个接收者仍然都打印了自己的日志，表明接收者并不能终止广播。

有序广播（Ordered Broadcast）

有序广播比较特殊，它每次只发送到优先级较高的接收者那里，然后由优先级高的接受者再传播到优先级低的接收者那里，优先级高的接收者有能力终止这个广播。

为了演示有序广播的流程，我们修改一下上面三个接收者的代码，如下：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
public class FirstReceiver extends BroadcastReceiver {
private static final String TAG = "OrderedBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = intent.getStringExtra("msg");
Log.i(TAG, "FirstReceiver: " + msg);
Bundle bundle = new Bundle();
bundle.putString("msg", msg + "@FirstReceiver");
setResultExtras(bundle);
}
}

[java] view plain copy

public class SecondReceiver extends BroadcastReceiver {
private static final String TAG = "OrderedBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = getResultExtras(true).getString("msg");
Log.i(TAG, "SecondReceiver: " + msg);
Bundle bundle = new Bundle();
bundle.putString("msg", msg + "@SecondReceiver");
setResultExtras(bundle);
}
}

[java] view plain copy

public class ThirdReceiver extends BroadcastReceiver {
private static final String TAG = "OrderedBroadcast";
@Override
public void onReceive(Context context, Intent intent) {
String msg = getResultExtras(true).getString("msg");
Log.i(TAG, "ThirdReceiver: " + msg);
}
}

我们注意到，在FirstReceiver和SecondReceiver中最后都使用了setResultExtras方法将一个Bundle对象设置为结果集对象，传递到下一个接收者那里，这样以来，优先级低的接收者可以用getResultExtras获取到最新的经过处理的信息集合。

代码改完之后，我们需要为三个接收者注册广播地址，我们修改一下AndroidMainfest.xml文件：

[html] view plain copy

<receiver android:name=".FirstReceiver">
<intent-filter android:priority="1000">
<action android:name="android.intent.action.MY_BROADCAST"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>
<receiver android:name=".SecondReceiver">
<intent-filter android:priority="999">
<action android:name="android.intent.action.MY_BROADCAST"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>
<receiver android:name=".ThirdReceiver">
<intent-filter android:priority="998">
<action android:name="android.intent.action.MY_BROADCAST"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>

我们看到，现在这三个接收者的<intent-filter>多了一个android:priority属性，并且依次减小。这个属性的范围在-1000到1000，数值越大，优先级越高。

现在，我们需要修改一下发送广播的代码，如下：

[java] view plain copy

public void send(View view) {
Intent intent = new Intent("android.intent.action.MY_BROADCAST");
intent.putExtra("msg", "hello receiver.");
sendOrderedBroadcast(intent, "scott.permission.MY_BROADCAST_PERMISSION");
}

注意，使用sendOrderedBroadcast方法发送有序广播时，需要一个权限参数，如果为null则表示不要求接收者声明指定的权限，如果不为null，则表示接收者若要接收此广播，需声明指定权限。这样做是从安全角度考虑的，例如系统的短信就是有序广播的形式，一个应用可能是具有拦截垃圾短信的功能，当短信到来时它可以先接受到短信广播，必要时终止广播传递，这样的软件就必须声明接收短信的权限。

所以我们在AndroidMainfest.xml中定义一个权限：

[html] view plain copy

<permission android:protectionLevel="normal"
android:name="scott.permission.MY_BROADCAST_PERMISSION" />

然后声明使用了此权限：

[html] view plain copy

<uses-permission android:name="scott.permission.MY_BROADCAST_PERMISSION" />

关于这部分如果有不明白的地方可以参考我之前写过的一篇文章：Android声明和使用权限

然后我们点击发送按钮发送一条广播，控制台打印如下：

我们看到接收是按照顺序的，第一个和第二个都在结果集中加入了自己的标记，并且向优先级低的接收者传递下去。

既然是顺序传递，试着终止这种传递，看一看效果如何，我们修改FirstReceiver的代码，在onReceive的最后一行添加以下代码：

[java] view plain copy

abortBroadcast();

然后再次运行程序，控制台打印如下：

此次，只有第一个接收者执行了，其它两个都没能执行，因为广播被第一个接收者终止了。

上面就是BroadcastReceiver的介绍，下面我将会举几个常见的例子加深一下大家对广播的理解和应用：

1.开机启动服务

我们经常会有这样的应用场合，比如消息推送服务，需要实现开机启动的功能。要实现这个功能，我们就可以订阅系统“启动完成”这条广播，接收到这条广播后我们就可以启动自己的服务了。我们来看一下BootCompleteReceiver和MsgPushService的具体实现：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
public class BootCompleteReceiver extends BroadcastReceiver {
private static final String TAG = "BootCompleteReceiver";
@Override
public void onReceive(Context context, Intent intent) {
Intent service = new Intent(context, MsgPushService.class);
context.startService(service);
Log.i(TAG, "Boot Complete. Starting MsgPushService...");
}
}

[java] view plain copy

package com.scott.receiver;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;
public class MsgPushService extends Service {
private static final String TAG = "MsgPushService";
@Override
public void onCreate() {
super.onCreate();
Log.i(TAG, "onCreate called.");
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.i(TAG, "onStartCommand called.");
return super.onStartCommand(intent, flags, startId);
}
@Override
public IBinder onBind(Intent arg0) {
return null;
}
}

然后我们需要在AndroidManifest.xml中配置相关信息：

[html] view plain copy

<receiver android:name=".BootCompleteReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>
<service android:name=".MsgPushService"/>

我们看到BootCompleteReceiver注册了“android.intent.action.BOOT_COMPLETED”这个开机广播地址，从安全角度考虑，系统要求必须声明接收开机启动广播的权限，于是我们再声明使用下面的权限：

[html] view plain copy

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

经过上面的几个步骤之后，我们就完成了开机启动的功能，将应用运行在模拟器上，然后重启模拟器，控制台打印如下：

如果我们查看已运行的服务就会发现，MsgPushService已经运行起来了。

2.网络状态变化

在某些场合，比如用户浏览网络信息时，网络突然断开，我们要及时地提醒用户网络已断开。要实现这个功能，我们可以接收网络状态改变这样一条广播，当由连接状态变为断开状态时，系统就会发送一条广播，我们接收到之后，再通过网络的状态做出相应的操作。下面就来实现一下这个功能：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.net.ConnectivityManager;
import android.net.NetworkInfo;
import android.util.Log;
import android.widget.Toast;
public class NetworkStateReceiver extends BroadcastReceiver {
private static final String TAG = "NetworkStateReceiver";
@Override
public void onReceive(Context context, Intent intent) {
Log.i(TAG, "network state changed.");
if (!isNetworkAvailable(context)) {
Toast.makeText(context, "network disconnected!", 0).show();
}
}
/**
* 网络是否可用
*
* @param context
* @return
*/
public static boolean isNetworkAvailable(Context context) {
ConnectivityManager mgr = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo[] info = mgr.getAllNetworkInfo();
if (info != null) {
for (int i = 0; i < info.length; i++) {
if (info[i].getState() == NetworkInfo.State.CONNECTED) {
return true;
}
}
}
return false;
}
}

再注册一下这个接收者的信息：

[html] view plain copy

<receiver android:name=".NetworkStateReceiver">
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>

因为在isNetworkAvailable方法中我们使用到了网络状态相关的API，所以需要声明相关的权限才行，下面就是对应的权限声明：

[html] view plain copy

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

我们可以测试一下，比如关闭WiFi，看看有什么效果。

3.电量变化

如果我们阅读软件，可能是全屏阅读，这个时候用户就看不到剩余的电量，我们就可以为他们提供电量的信息。要想做到这一点，我们需要接收一条电量变化的广播，然后获取百分比信息，这听上去挺简单的，我们就来实现以下：

[java] view plain copy

package com.scott.receiver;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.os.BatteryManager;
import android.util.Log;
public class BatteryChangedReceiver extends BroadcastReceiver {
private static final String TAG = "BatteryChangedReceiver";
@Override
public void onReceive(Context context, Intent intent) {
int currLevel = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, 0); //当前电量
int total = intent.getIntExtra(BatteryManager.EXTRA_SCALE, 1); //总电量
int percent = currLevel * 100 / total;
Log.i(TAG, "battery: " + percent + "%");
}
}

然后再注册一下广播接地址信息就可以了：

[html] view plain copy

<receiver android:name=".BatteryChangedReceiver">
<intent-filter>
<action android:name="android.intent.action.BATTERY_CHANGED"/>
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</receiver>

当然，有些时候我们是要立即获取电量的，而不是等电量变化的广播，比如当阅读软件打开时立即显示出电池电量。我们可以按以下方式获取：

[java] view plain copy

Intent batteryIntent = getApplicationContext().registerReceiver(null,
new IntentFilter(Intent.ACTION_BATTERY_CHANGED));
int currLevel = batteryIntent.getIntExtra(BatteryManager.EXTRA_LEVEL, 0);
int total = batteryIntent.getIntExtra(BatteryManager.EXTRA_SCALE, 1);
int percent = currLevel * 100 / total;
Log.i("battery", "battery: " + percent + "%");

本文链接

android 获取路径目录方法以及判断目录是否存在，创建目录（转）

2012-05-18T07:24:00Z

Environment 常用方法：

* 方法：getDataDirectory()
解释：返回 File ，获取 Android 数据目录。
* 方法：getDownloadCacheDirectory()
解释：返回 File ，获取 Android 下载/缓存内容目录。
* 方法：getExternalStorageDirectory()
解释：返回 File ，获取外部存储目录即 SDCard
* 方法：getExternalStoragePublicDirectory(String type)
解释：返回 File ，取一个高端的公用的外部存储器目录来摆放某些类型的文件
* 方法：getExternalStorageState()
解释：返回 File ，获取外部存储设备的当前状态
* 方法：getRootDirectory()
解释：返回 File ，获取 Android 的根目录

public void getSDPath(){
File sdDir = null;
File sdDir1 = null;
File sdDir2 = null;
boolean sdCardExist = Environment.getExternalStorageState()
.equals(android.os.Environment.MEDIA_MOUNTED); //判断sd卡是否存在
if (sdCardExist)
{
sdDir = Environment.getExternalStorageDirectory();//获取跟目录
sdDir1 = Environment.getDataDirectory();
sdDir2 =Environment.getRootDirectory();
}
System.out.println("getExternalStorageDirectory(): "+sdDir.toString());
System.out.println("getDataDirectory(): "+sdDir1.toString());
System.out.println("getRootDirectory(): "+sdDir2.toString());
}

//判断一个路径下的文件（文件夹）是否存在

public class IsExist {
public static void main(String[] args) {
isExist("e://12");
}
/**
*
* @param path 文件夹路径
*/
public static void isExist(String path) {
File file = new File(path);
//判断文件夹是否存在,如果不存在则创建文件夹
if (!file.exists()) {
file.mkdir();
}
}
}

1.在SD卡上创建一个文件夹
public class make extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
File sd=Environment.getExternalStorageDirectory();
String path=sd.getPath()+"/notes";
File file=new File(path);
if(!file.exists())
file.mkdir();

}

本文链接

PackageInstaller 原理简述 & PackageManagerService注记 & PackageParser和AndroidManifest.xml注记（转）

2012-05-17T09:55:00Z

PackageInstaller 原理简述

应用安装是智能机的主要特点，即用户可以把各种应用（如游戏等）安装到手机上，并可以对其进行卸载等管理操作。APK是Android Package的缩写，即Android安装包。APK是类似Symbian Sis或Sisx的文件格式。通过将APK文件直接传到Android模拟器或Android手机中执行即可安装。

Android应用安装有如下四种方式
1. 系统应用安装――开机时完成，没有安装界面
2. 网络下载应用安装――通过market应用完成，没有安装界面
3. ADB工具安装――没有安装界面。
4. 第三方应用安装――通过SD卡里的APK文件安装，有安装界面，由packageinstaller.apk应用处理安装及卸载过程的界面。
应用安装的流程及路径
应用安装涉及到如下几个目录：
system/app 系统自带的应用程序，无法删除
data/app 用户程序安装的目录，有删除权限。
安装时把apk文件复制到此目录
data/data 存放应用程序的数据
Data/dalvik-cache 将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件,其大小约为原始apk文件大小的四分之一)

安装过程：复制APK安装包到data/app目录下，解压并扫描安装包，把dex文件(Dalvik字节码)保存到dalvik-cache目录，并data/data目录下创建对应的应用数据目录。
卸载过程：删除安装过程中在上述三个目录下创建的文件及目录。

一、系统应用安装：
PackageManager Service处理各种应用的安装，卸载，管理等工作，开机时由systemServer启动此服务
(源文件路径：android/frameworks/base/services/java/com/android/server/ PackageManagerService.java)

PackageManager Service服务启动的流程：
1. 首先扫描安装“system/framework”目录下的jar包
1. scanDirLI(mFrameworkDir, PackageParser.PARSE_IS_SYSTEM,
scanMode | SCAN_NO_DEX);

2.第二步扫描安装“system/app”目录下的各个系统应用
scanDirLI(mSystemAppDir, PackageParser.PARSE_IS_SYSTEM, scanMode);

3.第三步扫描“data/app”目录，即用户安装的第三方应用
scanDirLI(mAppInstallDir, 0, scanMode);

4.第四步扫描" data/app-private"目录，即安装DRM保护的APK文件（目前没有遇到过此类的应用）。
scanDirLI(mDrmAppPrivateInstallDir, 0, scanMode | SCAN_FORWARD_LOCKED);

安装应用的过程
1.scanDirLI(File dir, int flags, int scanMode) 遍历安装指定目录下的文件

2.scanPackageLI(File scanFile,
File destCodeFile, File destResourceFile, int parseFlags,
int scanMode) 安装package文件

3.scanPackageLI(
File scanFile, File destCodeFile, File destResourceFile,
PackageParser.Package pkg, int parseFlags, int scanMode)
通过解析安装包parsePackage获取到安装包的信息结构

4.mInstaller.install(pkgName, pkg.applicationInfo.uid,
pkg.applicationInfo.uid); 实现文件复制的安装过程
（源文件路径：frameworks/base/cmds/installd/installd.install）

二、从market上下载应用：
Google Market应用需要使用gmail账户登录才可以使用，选择某一应用后，开始下载安装包，此过程中，在手机的信号区有进度条提示，下载完成后，会自动调用Packagemanager的接口安装，调用接口如下：
public void installPackage(final Uri packageURI, final IPackageInstallObserver observer, final int flags)
final Uri packageURI：文件下载完成后保存的路径
final IPackageInstallObserver observer：处理返回的安装结果
final int flags：安装的参数，从market上下载的应用，安装参数为-r (replace)
installPackage接口函数的安装过程：
1.public void installPackage(
final Uri packageURI, final IPackageInstallObserver observer, final int flags,
final String installerPackageName)
final String installerPackageName:安装完成后此名称保存在settings里，一般为null,不是关键参数
2.File tmpPackageFile = copyTempInstallFile(packageURI, res);
把apk文件复制到临时目录下的临时文件
3.private void installPackageLI(Uri pPackageURI,
int pFlags, boolean newInstall, String installerPackageName,
File tmpPackageFile, PackageInstalledInfo res)
解析临时文件，获取应用包名pkgName = PackageParser.parsePackageName(
tmpPackageFile.getAbsolutePath(), 0);
4.判断如果带有参数INSTALL_REPLACE_EXISTING，则调用replacePackageLI(pkgName,
tmpPackageFile,
destFilePath, destPackageFile, destResourceFile,
pkg, forwardLocked, newInstall, installerPackageName,
res)
5.如果没有，则调用installNewPackageLI(pkgName,
tmpPackageFile,
destFilePath, destPackageFile, destResourceFile,
pkg, forwardLocked, newInstall, installerPackageName,
res);
6.private PackageParser.Package scanPackageLI(
File scanFile, File destCodeFile, File destResourceFile,
PackageParser.Package pkg, int parseFlags, int scanMode)
scanPackageLI以后的流程，与开机时的应用安装流程相同。
三、从ADB工具安装
Android Debug Bridge (adb) 是SDK自带的管理设备的工具，通过ADB命令行的方式也可以为手机或模拟器安装应用，其入口函数源文件为pm.java
(源文件路径：android/frameworks/base/cmds/pm/src/com/android/commands/pm/pm.java)
ADB命令行的形式为adb install <path_to_apk> ,还可以带安装参数如："-l" "-r" "-i" "-t"
函数runInstall()中判断参数
"-l"――INSTALL_FORWARD_LOCK
"-r"—— INSTALL_REPLACE_EXISTING
"-i" ——installerPackageName
"-t"——INSTALL_ALLOW_TEST
我们常用的参数为-r，表示覆盖安装手机上已安装的同名应用。从market上下载的应用，也是直接传入这个参数安装的。
runInstall与market调用同样的接口完成应用安装。
public void installPackage(android.net.Uri packageURI, android.content.pm.IPackageInstallObserver observer, int flags, java.lang.String installerPackageName)
四、第三方应用安装――通过SD卡里的APK文件安装
把APK安装包保存在SD卡中，从手机里访问SD卡中的APK安装包，点击就可以启动安装界面，系统应用Packageinstaller.apk处理这种方式下的安装及卸载界面流程，如下图：

PackageInstallerActivity负责解析包，判断是否是可用的Apk文件
创建临时安装文件/data/data/com.android.packageinstaller/files/ApiDemos.apk
并启动安装确认界面startInstallConfirm，列出解析得到的该应用基本信息。如果手机上已安装有同名应用，则需要用户确认是否要替换安装。
确认安装后，启动InstallAppProgress，调用安装接口完成安装。
pm.installPackage(mPackageURI, observer, installFlags);
其它：
1. PackageManagerService.java的内部类AppDirObserver实现了监听app目录的功能：当把某个APK拖到app目录下时，可以直接调用scanPackageLI完成安装。
2.手机数据区目录“data/system/packages.xml”文件中，包含了手机上所有已安装应用的基本信息，如安装路径，申请的permission等信息。

------------------------------------------------------华丽的分割线---------------------------------------------------------------

PackageManagerService注记

PackageManagerService的方法大致可以分成这样几类,
1)从apk, xml中载入pacakge信息, 存储到内部成员变量中, 用于后面的查找. 关键的方法是scanPackageLI().
2)各种查询操作, 包括query Intent操作.
3)install package和delete package的操作. 关键的方法是installPackageLI().
4)其它操作, 包括permission, signature, freeStorage等等.

首先看看PacakgeManagerService用到的几个重要的支撑类, 然后罗列几个PackageManagerService的几个关键内部数据成员变量. 最后注记几个关键流程.

PackageManagerService用到了几个重要的支撑类:

PackageParser, 这个类主要用于解析apk, 分析其AndroidManifest.xml得到package的各种信息. 前已有注记文章,此不赘述. 特别的PackageParser.Package这个类用于容纳解析出的信息.

PackageManagerService.Settings, 用于容纳当前有效的package信息, 它是动态的. 例如, user id, shareUser, permission, signature以及origPackage(也就是mRenamedPackages)相关信息. 所谓的install package就包括从要安装的package中抽取信息更新PackageManagerService.Settings中的内容. 特别的, Settings针对shareUser和origPackage做了特别的关照. 另外, 为了加速启动速度, Settings的内容会写入到/data/system/packages.xml, packages-backup.xml, 和packages.list中, 下次启动时会直接载入.

Installer, 这个类协助安装过程, 更多的是将针对文件/路径的操作放到了c/cpp实现. 真正的工作是是由installd承担的, Installer只是通过named socket "installd"连接installd, 使用简单的cmd-respond协议指挥installd完成工作. 在其'install'命令中可以看到, 其实只是创建了/data/data/<pkgName>目录而已.

PackageManagerService中的几个关键成员变量:

// (pkgName => Package), package is the one installed.

final HashMap<String, PackageParser.Package> mPackages =

new HashMap<String, PackageParser.Package>();

// current package settings info, such as userid, origPackage

// , shareUser, permission, signature, etc

final Settings mSettings;

// (system uid => permission), permissions read from /system/etc/permissions/<files> are stored here.

// especially /system/etc/permissions/platform.xml

final SparseArray<HashSet<String>> mSystemPermissions =

new SparseArray<HashSet<String>>();

//(pkgName => sharedLib), corresponding to <library> tag

final HashMap<String, String> mSharedLibraries =

new HashMap<String, String>();

// All available activities, for resolving intent

final ActivityIntentResolver mActivities =

new ActivityIntentResolver();

// All available receivers, for resolving intent

final ActivityIntentResolver mReceivers =

new ActivityIntentResolver();

// All available services, for resolving intent

final ServiceIntentResolver mServices =

new ServiceIntentResolver();

几个关键流程,

初始化过程
--------------

PackageManagerService由SystemServer在创建ActivityManagerService后调用main创建, 是单实例的.

Slog.i(TAG, "Power Manager");

power = new PowerManagerService();

ServiceManager.addService(Context.POWER_SERVICE, power);

Slog.i(TAG, "Activity Manager");

context = ActivityManagerService.main(factoryTest);

Slog.i(TAG, "Telephony Registry");

ServiceManager.addService("telephony.registry", new TelephonyRegistry(context));

AttributeCache.init(context);

Slog.i(TAG, "Package Manager");

pm = PackageManagerService.main(context,

factoryTest != SystemServer.FACTORY_TEST_OFF);

ActivityManagerService.setSystemProcess();

mContentResolver = context.getContentResolver();

在构造函数中, PackageManagerService会做这些工作,

1)启动自己的handlerThread, 生成自己的mHandler.
2)从/system/etc/permissions/的所有xml文件中, 尤其是platform.xml, 读入systemPermissions. 这些是系统默认的permission配置.
3)扫描/system/framework/, /system/app/, /data/app/, 和/data/app-private/下的apk文件, 收集package各种信息, 更新到内部成员变量中. 这些将在PackageManagerService执行各种功能时用到. 尤其是query intent.

更详尽的笔记,
PackageManagerService
mHandlerThread.start();

mHandler = new PackageHandler(mHandlerThread.getLooper());

readPermissions();

mRestoredSettings = mSettings.readLP();

--/system/framework/
scanDirLI(mFrameworkDir, PackageParser.PARSE_IS_SYSTEM| PackageParser.PARSE_IS_SYSTEM_DIR, scanMode | SCAN_NO_DEX);

--/system/app/
scanDirLI(mSystemAppDir, PackageParser.PARSE_IS_SYSTEM | PackageParser.PARSE_IS_SYSTEM_DIR, scanMode);

--Prune any system packages that no longer exist.

--clean up any incomplete package installations

--delete tmp files

--/data/app/
scanDirLI(mAppInstallDir, 0, scanMode);

--/data/app-private/
scanDirLI(mDrmAppPrivateInstallDir, PackageParser.PARSE_FORWARD_LOCK, scanMode);

mSettings.writeLP();

private PackageParser.Package scanPackageLI(File scanFile, int parseFlags, int scanMode)
PackageParser pp = new PackageParser(scanPath);

pkg = pp.parsePackage(scanFile, scanPath, mMetrics, parseFlags);

collectCertificatesLI(pp, ps, pkg, scanFile, parseFlags)

setApplicationInfoPaths(pkg, codePath, resPath);

scanPackageLI(pkg, parseFlags, scanMode | SCAN_UPDATE_SIGNATURE);
--set mAndroidApplication and mResolveActivity to'Android' package

--Check all shared libraries and map to their actual file path.

--check pkg.usesLibraries are contained in mSharedLibraries.

--fill in pkg.usesLibraryFiles according to pkg.usesLibraries and pkg.usesOptionalLibraries

--check pkg.reqFeatures in mAvailableFeatures

--if not in mSettings, create one ShareUserSettings and insert into mSettings.

--Check and note if we are renaming from an original package name

pkgSetting = mSettings.getPackageLP(pkg, origPackage, realName, suid, destCodeFile, destResourceFile, pkg.applicationInfo.flags, true, false);

verifySignaturesLP(pkgSetting, pkg);

--Verify that this new package doesn't have any content providers that conflict with existing packages.

--get data dir. if not exists, install or create the data dir. if exists but uid not correct, reinstall.

--Perform shared library installation and dex validation and optimization, if this is not a system app.

--Request the ActivityManager to kill the process(only for existing packages)

mSettings.insertPackageSettingLP(pkgSetting, pkg); --Add the new setting to mSettings

mPackages.put(pkg.applicationInfo.packageName, pkg);

--set mProvidersByComponent and mProviders according to pkg.providers

--set mServices according to pkg.services

--set mReceivers according to pkg.receivers

--set mActivites according to pkg.activities

--set mPermissionGroups according to pkg.permissionGroups

--set mSettings.mPermissionTrees or mSettings.mPermissions according to pkg.permissions

--set mInstrumentation according to pkg.instrumentation

--set mProtectedBroadcasts according to pkg.protectedBroadcasts

install package过程
--------------

install package的入口是installPackage(). install package通常是个耗时的过程, 因此会使用到android的handler机制.
首先, 参数封装成INIT_COPY message, 发到handlerThread.
handlerThread收到message后, 将参数排队到mPendingInstalls中. 随后,MCS_BOUND流程将会处理这个队列, 执行安装.
MCS_BOUND的整个安装流程借助了几个InstallParams和InstallArgs完成其中的参数和安装结果的传递. 最终会调用processPendingInstall(), 进而调用到install过程的核心 installPackageLI().
installPackageLI()的复杂性很大程度上是考虑了1)新安装还是升级情况, 2)origPackage情况

-----------------------------------华丽的分割线--------------------------------------------------------------------

PackageParser和AndroidManifest.xml注记

apk包中的AndroidManifest.xml文件包含了package的各种描述信息. 分析和获取这些信息的工作是由PackageParser完成的. 这里简述之. 首先我们先罗列AndroidManifest.xml文件的简要结构, 其次在大致整理PackageParser的逻辑.

AndroidManifest.xml的简要结构
====================================
AndroidManifest.xml的内容在frameworks/base/core/res/res/values/attrs_manifest.xml中定义. 这里简要罗列, 按照层进关系, xml element用 "tagName, Name"的形式标记, 对于某些xml element的重要属性(attribute), 用"attr NAME"标记.

AndridManifest.xml
manifest, AndroidManifest
attr versionCode
attr versionName
attr sharedUserId
attr sharedUserLabel
attr installLocation

permission, AndroidManifestPermission
attr name, label, icon
attr permissionGroup
attr protectionLevel

permission-group, AndroidManifestPermissionGroup
attr name, label, icon

permission-tree, AndroidManifestPermissionTree
attr name, label, icon

uses-sdk, AndroidManifestUsesSdk

uses-permission, AndroidManifestUsesPermission
attr name

uses-configuration, AndroidManifestUsesConfiguration
attr reqTouchScreen
attr requKeyboardType
attr reqHardKeyboard
attr reqNavigation
attr reqFiveWayNav

application, AndroidManifestApplication
attr name, label, icon
attr permission
attr process
attr taskAffinity
attr persistent

service, AndroidManifestService
attr name, label, icon
attr permission
attr process
attr enabled
attr exported

receiver, AndroidManifestReceiver
attr name, label, icon
attr permission
attr process
attr enabled
attr exported

provider, AndroidManifestProvider
attr name, label, icon
attr process, authorities, syncable
attr readPermission, writePermission, grantUriPermissions
attr permission
attr mulitprocess
attr enabled
attr exported
grant-uri-permission, AndroidManifestGrantUriPermission
attr path, pathPrefix, pathPattern

path-permission, AndroidManifestPathPermission
attr path, pathPrefix, pathPattern
attr permission, readPermission, writePermission

activity, AndroidManifestActivity
attr name, label, icon
attr theme, launchMode, screenOrientation
attr configChanges, permission, multiprocess
attr process, taskAffinity, allowTaskReparenting
attr finishOnTaskLaunch, finishOnCloseSystemDialogs
attr clearTaskOnLauch, noHistory
attr alwaysRetainTaskState, stateNotNeeded
attr excludeFromRecents
attr enabled, exported
attr windowSoftInputMode

activity-alias, AndroidManifestActivityAlias
attr name, label, icon
attr targetActivity
attr permission
attr enabled, exported

uses-library, AndroidManifestUsesLibrary
attr name
attr required

instrumentation, AnroidManifestInstrumentation
attr name, label, icon
attr targetPackage, handleProfiling
attr functionalTest

uses-feature, AndroidManifestUsesFeature
attr glEsVersion
attr name
attr required

supports-screens, AndroidManifestSupportsScreens
attr smallScreens, normalScreens, largeScreens
attr resizeable, anyDensity

protected-broadcast, AndroidManifestProtectedBroadcast
attr name

adopt-permissions, AndroidManifestOriginalPackage
attr name

还有几个特别的xml element, 可以有多个parent element.
application
activity, receiver, provider, service
permission, permissionGroup
instrumentation
meta-data, AndroidManifestMetaData
attr name, value, resource

activity, receiver, service
intent-filter, AndroidManifestIntentFilter
attr label, icon, priority

action, AndroidManifestAction
attr name

data, AndroidManifestData
attr mimeType, scheme, host
attr port, path, pathPrefix
attr pathPattern

category, AndroidManifestCategory
attr name

intent, Intent
attr action, data, mimeType
attr targetPackage, targetClass

category, IntentCategory
attr name

extra, Extra
attr name, value

PackageParser的逻辑
====================================
PackageParser的parsePackage()方法会读取apk包中的AndroidManifest.xml文件, 调用各子par***XX()方法, 解析出包信息. 同时, PackageParser定义了一些class, 容纳这些解析得到的信息. 下面是对应的关系.

class xml elements
------------- --------------------------------------
Package package
Permission permission, permission-tree
PermissionGroup permission-group
Activity activity, activity-alias, receiver
Service service
Provider provider
Instrumentation instrumentation
ActivityIntentInfo intent-filter @ activity or receiver
ServiceIntentInfo intent-filter @ service

PacakgeParser的结果主要被PackageManagerService使用.

本文链接

标记化结构初始化语法(C语言)

2012-05-10T10:21:00Z

以前在看Linux代码时，就对它的结构体初始化写法感到奇怪，所有的初始化代码都写清了变量名，并且变量名前面还有一个诡异的点。最近学习Linux设备驱动，又遇到了，就查了一下，发现自己的知识果然纰漏不少，此种初始化写法并不是什么特殊的代码风格，而是所谓的C语言标记化结构初始化语法（designated initializer），而且还是一个ISO标准。

[cpp] view plain copy

#include <stdio.h>
#include <stdlib.h>
struct operators
{
void (*read1)(char *);
void (*read2)(char *);
void (*read3)(char *);
int n;
};
void read1(char *data)
{
printf("read1: %s/n",data);
}
void read2(char *data)
{
printf("read2: %s/n",data);
}
void read3(char *data)
{
printf("read3: %s/n",data);
}
int main()
{ //传统的初始化方法
//struct operators my_op = {read1, read2, read3, 100}; //所谓的标记化结构初始化语法
struct operators my_op = {.read2 = read2,
.read1 = read1,
.read3 = read3,
.n = 100};
my_op.read1("wangyang");
my_op.read2("wangyang");
my_op.read3("wangyang");
return 0;
}

重点就在于main()函数中对my_op结构体的初始化语句，使用点加变量名进行初始化。用过python的人会马上感觉到这与关键字传参是多么的相似。

那它的好处在哪里呢？我想好处有三:

首先，标记传参不用理会参数传递的顺序，正如我上面的例子表示的那样，我是先初始化了read2，然后再初始化了read1，程序员不用记忆参数的顺序；

其次，我们可以选择性传参，在传统C语言顺序传参中，如果你只想对第三个变量进行初始化，那么你不得不给第一个, 第二个参数进行初始化，而有时候一个变量并没有很合适的默认值，而使用标记初始化法，你可以相当自由地对你有把握的参数进行初始化；

第三，扩展性更好，如果你要在该结构体中增加一个字段，传统方式下，为了考虑代码修改量，你最好将新添加的字段放在这个结构体的最后面，否则你将要面对大量且无趣的修改，你可能觉得放在哪里没什么关系，但是我们都习惯了，姓名下面是性别，性别下面是年龄，接着是兴趣爱好，最后是事迹描述，如果年龄放在了最后面，难道不别扭么？！

有人提到，该种语法还有利于提高性能，木有感觉出来，我在这里就不谈这点了。

其实，该种初始化语法并不是什么新技术，新定义，它就是ISO C99的一个标准用法，也就是说99年就有了，再说Linus也不会去赶什么时髦的，据说C Primer Plus第五版中提到了这点，不过，我没有看过该书，遗憾，我是直接投入了面向对象的怀抱。

GCC有扩展标记化结构初始化语法，写法是下面这样的：

struct operators my_op = {read2 : read2, read1 : read1, read3 : read3,};

转自: http://www.hustyx.com/cplusplus/agtodXN0eWl4aWFuZ3IPCxIHQXJjaGl2ZRihigcM

本文链接

Android adb root权限

2012-02-07T06:18:00Z

方法：

修改./default.prop

把ro.secure设为0，persist.service.adb.enable设为1，adbd进程就会以root用户的身份启动。

原理：

可以看一下Android系统根目录下的/init.rc的片段：

... ...

# adbd is controlled by the persist.service.adb.enable system property

service adbd /sbin/adbd

disabled

# adbd on at boot in emulator

on property:ro.kernel.qemu=1

start adbd

on property:persist.service.adb.enable=1

start adbd

on property:persist.service.adb.enable=0

stop adbd

... ...

这里定义了一个触发器，只要persist.service.adb.enable值被置为1，就会启动/sbin/adbd。

在build目录下搜索一下，发现了main.mk中有这样的代码片段

## user/userdebug ##

user_variant := $(filter userdebug user,$(TARGET_BUILD_VARIANT))

enable_target_debugging := true

ifneq (,$(user_variant))

# Target is secure in user builds.

ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=1

tags_to_install := user

ifeq ($(user_variant),userdebug)

# Pick up some extra useful tools

tags_to_install += debug

else

# Disable debugging in plain user builds.

enable_target_debugging :=

endif

# TODO: Always set WITH_DEXPREOPT (for user builds) once it works on OSX.

# Also, remove the corresponding block in config/product_config.make.

ifeq ($(HOST_OS)-$(WITH_DEXPREOPT_buildbot),linux-true)

WITH_DEXPREOPT := true

endif

# Disallow mock locations by default for user builds

ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=0

else # !user_variant

# Turn on checkjni for non-user builds.

ADDITIONAL_BUILD_PROPERTIES += ro.kernel.android.checkjni=1

# Set device insecure for non-user builds.

ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=0

# Allow mock locations by default for non user builds

ADDITIONAL_DEFAULT_PROPERTIES += ro.allow.mock.location=1

endif # !user_variant

ifeq (true,$(strip $(enable_target_debugging)))

# Target is more debuggable and adbd is on by default

ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1 persist.service.adb.enable=1

# Include the debugging/testing OTA keys in this build.

INCLUDE_TEST_OTA_KEYS := true

else # !enable_target_debugging

# Target is less debuggable and adbd is off by default

ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=0 persist.service.adb.enable=0

endif # !enable_target_debugging

这段代码我大致解释一下：

主要通过判断当前的编译模式来给几个属性赋予不同的值，然后把属性存储在ADDITIONAL_DEFAULT_PROPERTIES这个变量中，这个变量在后面是要写到根目录下的/default.prop中去，在系统启动时被属性服务加载的。也就是说我们在/default.prop中看到的几个属性的值是在这里设置的。

只看两个属性ro.secure，persist.service.adb.enable。当前是user模式的话，编译系统会把ro.secure置为1，把persist.service.adb.enable置为0.也就是说，用user模式编译出来的系统运行在安全模式下，adbd默认关闭。即使通过设置属性的方式打开，adbd进程的用户也是shell，不具有root权限。这样，普通用户或者开发者拿到一个机器后，通过PC运行adb shell时，是以shell用户登录机器的。

好了，现在把ro.secure置为0，再重新编译，只要设置属性persist.service.adb.enable的值为1，adbd进程就会以root用户的身份启动。

本文链接

java中Thread与Runnable的区别

2012-01-31T03:14:00Z

在java中可有两种方式实现多线程，一种是继承Thread类，一种是实现Runnable接口；
Thread类是在java.lang包中定义的。一个类只要继承了Thread类同时覆写了本类中的
run()方法就可以实现多线程操作了，但是一个类只能继承一个父类，这是此方法的局限，

下面看例子：
package org.thread.demo;
class MyThread extends Thread{
private String name;
public MyThread(String name) {
super();
this.name = name;
}
public void run(){
for(int i=0;i<10;i++){
System.out.println("线程开始："+this.name+",i="+i);
}
}
}
package org.thread.demo;
public class ThreadDemo01 {
public static void main(String[] args) {
MyThread mt1=new MyThread("线程a");
MyThread mt2=new MyThread("线程b");
mt1.run();
mt2.run();
}
}
但是，此时结果很有规律，先第一个对象执行，然后第二个对象执行，并没有相互运行。在JDK的文档中可以发现，一旦调用start()方法，则会通过JVM找到run()方法。下面启动

start()方法启动线程：
package org.thread.demo;
public class ThreadDemo01 {
public static void main(String[] args) {
MyThread mt1=new MyThread("线程a");
MyThread mt2=new MyThread("线程b");
mt1.start();
mt2.start();
}
};这样程序可以正常完成交互式运行。那么为啥非要使用start();方法启动多线程呢？
在JDK的安装路径下，src.zip是全部的java源程序，通过此代码找到Thread中的start()方法的定义，可以发现此方法中使用了private native void start0();其中native关键字表示可以调用操作系统的底层函数，那么这样的技术成为JNI技术（java Native Interface）

·Runnable接口
在实际开发中一个多线程的操作很少使用Thread类，而是通过Runnable接口完成。
public interface Runnable{
public void run();
}
例子：
package org.runnable.demo;
class MyThread implements Runnable{
private String name;
public MyThread(String name) {
this.name = name;
}
public void run(){
for(int i=0;i<100;i++){
System.out.println("线程开始："+this.name+",i="+i);
}
}
};
但是在使用Runnable定义的子类中没有start()方法，只有Thread类中才有。此时观察Thread类，有一个构造方法：public Thread(Runnable targer)
此构造方法接受Runnable的子类实例，也就是说可以通过Thread类来启动Runnable实现的多

线程。（start()可以协调系统的资源）:
package org.runnable.demo;
import org.runnable.demo.MyThread;
public class ThreadDemo01 {
public static void main(String[] args) {
MyThread mt1=new MyThread("线程a");
MyThread mt2=new MyThread("线程b");
new Thread(mt1).start();
new Thread(mt2).start();
}
}

· 两种实现方式的区别和联系：
在程序开发中只要是多线程肯定永远以实现Runnable接口为主，因为实现Runnable接口相比
继承Thread类有如下好处：
->避免点继承的局限，一个类可以继承多个接口。
->适合于资源的共享

以卖票程序为例，通过Thread类完成：
package org.demo.dff;
class MyThread extends Thread{
private int ticket=10;
public void run(){
for(int i=0;i<20;i++){
if(this.ticket>0){
System.out.println("賣票：ticket"+this.ticket--);
}
}
}
};
下面通过三个线程对象，同时卖票：
package org.demo.dff;
public class ThreadTicket {
public static void main(String[] args) {
MyThread mt1=new MyThread();
MyThread mt2=new MyThread();
MyThread mt3=new MyThread();
mt1.start();//每个线程都各卖了10张，共卖了30张票
mt2.start();//但实际只有10张票，每个线程都卖自己的票
mt3.start();//没有达到资源共享
}
}
如果用Runnable就可以实现资源共享，下面看例子：
package org.demo.runnable;
class MyThread implements Runnable{
private int ticket=10;
public void run(){
for(int i=0;i<20;i++){
if(this.ticket>0){
System.out.println("賣票：ticket"+this.ticket--);
}
}
}
}
package org.demo.runnable;
public class RunnableTicket {
public static void main(String[] args) {
MyThread mt=new MyThread();
new Thread(mt).start();//同一个mt，但是在Thread中就不可以，如果用同一
new Thread(mt).start();//个实例化对象mt，就会出现异常
new Thread(mt).start();
}
};
虽然现在程序中有三个线程，但是一共卖了10张票，也就是说使用Runnable实现多线程可以达到资源共享目的。

Runnable接口和Thread之间的联系：
public class Thread extends Object implements Runnable
发现Thread类也是Runnable接口的子类。

本文链接

linux主设备号和次设备号

2011-12-14T02:10:00Z

Linux的设备管理是和文件系统紧密结合的，各种设备都以文件的形式存放在/dev目录下，称为设备文件。应用程序可以打开、关闭和读写这些设备文件，完成对设备的操作，就像操作普通的数据文件一样。为了管理这些设备，系统为设备编了号，每个设备号又分为主设备号和次设备号。主设备号用来区分不同种类的设备，而次设备号用来区分同一类型的多个设备。对于常用设备，Linux有约定俗成的编号，如硬盘的主设备号是3。

Linux为所有的设备文件都提供了统一的操作函数接口，方法是使用数据结构struct file_operations。这个数据结构中包括许多操作函数的指针，如open()、close()、read()和write()等，但由于外设的种类较多，操作方式各不相同。Struct file_operations结构体中的成员为一系列的接口函数，如用于读/写的read/write函数和用于控制的ioctl等。打开一个文件就是调用这个文件file_operations中的open操作。不同类型的文l件有不同的file_operations成员函数，如普通的磁盘数据文件，接口函数完成磁盘数据块读写操作；而对于各种设备文件，则最终调用各自驱动程序中的I/O函数进行具体设备的操作。这样，应用程序根本不必考虑操作的是设备还是普通文件，可一律当作文件处理，具有非常清晰统一的I/O接口。所以file_operations是文件层次的I/O接口。

转自：http://hi.baidu.com/wudaovip/blog/item/479b451e95c475f81ad57621.html

    设备号是在驱动module中分配并注册的，也就是说，驱动module拥有这个设备号(我的理解)，而/dev目录下的设备文件是根据这个设备号创建的，因此，当访问/dev目录下的设备文件时，驱动module就知道，自己该出场服务了(当然是由内核通知)。
    在Linux内核看来，主设备号标识设备对应的驱动程序，告诉Linux内核使用哪一个驱动程序为该设备(也就是/dev下的设备文件)服务；而次设备号则用来标识具体且唯一的某个设备。
    在内核中，用dev_t类型(其实就是一个32位的无符号整数)的变量来保存设备的主次设备号，其中高12位表示主设备号，低20位表示次设备号。
    设备获得主次设备号有两种方式：一种是手动给定一个32位数，并将它与设备联系起来(即用某个函数注册)；另一种是调用系统函数给设备动态分配一个主次设备号。

对于手动给定一个主次设备号，使用以下函数：
int register_chrdev_region(dev_t         first,
                           unsigned int -count,
                           char          *name)
    其中first是我们手动给定的设备号，count是所请求的连续设备号的个数，而name是和该设备号范围关联的设备名称，它将出现在/proc/devices和sysfs中。
    比如，若first为0x3FFFF0，count为0x5，那么该函数就会为5个设备注册设备号，分别是0x3FFFF0、 0x3FFFF1、 0x3FFFF2、 0x3FFFF3、 0x3FFFF4，其中0x3(高12位)为这5个设备所共有的主设备号(也就是说这5个设备都使用同一个驱动程序)。而0xFFFF0、 0xFFFF1、 0xFFFF2、 0xFFFF3、 0xFFFF4就分别是这5个设备的次设备号了。需要注意的是，若count的值太大了，那么所请求的设备号范围可能会和下一个主设备号重叠。比如若 first还是为0x3FFFF0，而count为0x11，那么first+count=0x400001，也就是说为最后两个设备分配的主设备号已经不是0x3，而是0x4了！用这种方法注册设备号有一个缺点，那就是若该驱动module被其他人广泛使用，那么无法保证注册的设备号是其他人的 Linux系统中未分配使用的设备号。

对于动态分配设备号，使用以下函数：
int alloc_chrdev_region(dev_t         *dev,
                        unsigned int -firstminor,
                        unsigned int -count,
                        char          *name)
    该函数需要传递给它指定的第一个次设备号firstminor(一般为0)和要分配的设备数count，以及设备名，调用该函数后自动分配得到的设备号保存在dev中。动态分配设备号可以避免手动指定设备号时带来的缺点，但是它却也有自己的缺点，那就是无法预先在/dev下创建设备节点，因为动态分配设备号不能保证在每次加载驱动module时始终一致(其实若在两次加载同一个驱动module之间并没有加载其他的module，那么自动分配的设备号还是一致的，因为内核分配设备号并不是随机的，但是书上说某些内核开发人员预示不久的将来会用随机方式进行处理)，不过，这个缺点可以避免，因为在加载驱动module后，我们可以读取/proc/devices文件以获得Linux内核分配给该设备的主设备号。

与主次设备号相关的3个宏：
MAJOR(dev_t dev)：根据设备号dev获得主设备号；
MINOR(dev_t dev)：根据设备号dev获得次设备号；
MKDEV(int major, int minor)：根据主设备号major和次设备号minor构建设备号。

另解:

Linux的设备管理是和文件系统紧密结合的，把设备和文件关联起来，这样系统调用可以直接用操作文件一样的方法来操作设备。各种设备都以文件的形式存放在/dev目录下，称为设备文件。应用程序可以打开、关闭和读写这些设备文件，完成对设备的操作，就像操作普通的数据文件一样。为了管理这些设备，系统为设备编了号，每个设备号又分为主设备号和次设备号。主设备号用来区分不同种类的设备，而次设备号用来区分同一类型的多个设备。对于常用设备，Linux有约定俗成的编号，如硬盘的主设备号是3。

转自：http://fanyihui1986.blog.163.com/blog/static/784485920091132043905/

来自: http://hi.baidu.com/vv1133/blog/item/08d271941e1f3213d31b70bd.html

本文链接

android下m、mm、mmm编译命令的使用

2011-12-05T08:28:00Z

通过查看android源码目录下的build/envsetup.sh文件，可知：
- m:       Makes from the top of the tree.
- mm:      Builds all of the modules in the current directory.
- mmm:     Builds all of the modules in the supplied directories.

要想使用这些命令，首先需要在android源码根目录执行. build/envsetup.sh

m：编译所有的模块
mm：编译当前目录下的模块，当前目录下要有Android.mk文件
mmm：编译指定路径下的模块，指定路径下要有Android.mk文件

下面举个例子说明，假设我要编译android下的libjpeg模块，当前目录为源码根目录，方法如下：

1、. build/envsetup.sh
2、mmm external/jpeg/

或者：

1、. build/envsetup.sh
2、cd external/jpeg
3、mm

最后说明一下，envsetup.sh只要source一次就够了，source之后还可以用croot命令返回到源码根目录，很好用。

本文链接

博客园_You Know ,I Can Do it .

udev的实现原理 （转）

I/O端口和I/O内存

BroadcastReceiver应用详解 （转)

android 获取路径目录方法以及判断目录是否存在，创建目录 （转）

PackageInstaller 原理简述 & PackageManagerService注记 & PackageParser和AndroidManifest.xml注记 （转）

标记化结构初始化语法(C语言)

Android adb root权限

java中Thread与Runnable的区别

linux主设备号和次设备号

android下m、mm、mmm编译命令的使用

udev的实现原理（转）

BroadcastReceiver应用详解（转)

android 获取路径目录方法以及判断目录是否存在，创建目录（转）

PackageInstaller 原理简述 & PackageManagerService注记 & PackageParser和AndroidManifest.xml注记（转）