linux驱动部分,主要利用sysfs文件系统建立一个class一个device和一个file,通过uevent去改变file所存储的值并通知上层,具体为利用一个定时器以固定的时间间隔发送uevent消息
最先接收linux发送的uevent的是vold,这是Android的一个守护进程,主要负责接收底层uevent的事件,并把此事件往上发送
在jni层通过register_Android_server_xxxx 函数不断从sysfs中的file中读取信息，在onLoad.cpp中添加注册些服务
在java层新写一个自己的services，重写onEvent函数不断调用jni层的注册函数而更新信息，并通过Intent向上层广播
在apk层建立一个监听的服务不断监听Intent的事件并过滤，当捕获时改变一个textLabel的值从而显示出结果来
uevent:在 sysfs 下的很多 kobject 下都有 Linux uevent属性，它主要用于内核与 udev (自动设备发现程序)之间的一个通信接口；从 udev 本身与内核的通信接口 netlink 协议套接字来说，它并不需要知道设备的 Linux uevent属性文件，但多了 uevent 这样一个接口。
可用于 udevmonitor 通过内核向 udevd (udev 后台程序)发送消息，也可用于检查设备本身所支持的 netlink 消息上的环境变量，这个特性一般用于开发人员调试 udev 规则文件， udevtrigger 这个调试工具本身就是以写各设备的 Linux uevent属性文件实现的。
这些 Linux uevent属性文件一般都是可写的，其中 /sys/devices/ 树下的很多 Linux uevent属性在较新内核下还支持可读.
每一个设备驱动程序在程序内以某种方式注明了可用于哪些硬件，如所有的 PCI 驱动都使用 MODULE_DEVICE_TABLE 声明了所能驱动的 PCI 硬件的 PCI 设备号。但驱动程序不能预知未来，未来生产的新的硬件有可能兼容现有硬件的工作方式，就还可以使用现有硬件驱动程序来工作。在 bind 和 unbind 发明以前，这种情况除了修改 PCI 设备驱动程序的 DEVICE_TABLE 段落，重新编译驱动程序，以外别无他法，在 2.6 内核上添加了 bind 和 unbind 之后可以在不重新编译的情况下对设备和驱动之间进行手工方式地绑定。
而且对于有些硬件设备可以有多份驱动可用，但任何具体时刻只能有一个驱动程序来驱动这个硬件，这时可以使用 bind/unbind 来强制使用和不使用哪一个驱动程序；(注意关于多种驱动程序的选择，更好的管理方法是使用 modprobe.conf 配置文件，需要重启才生效，而 bind/unbind 提供的是一种临时的无需重启立即生效的途径；)
使用它们可以强制绑定某个设备使用或强制不使用某个驱动程序，操作方法就是通过 bind 和 unbind 接口
