深入浅出 - Android系统移植与平台开发（八）- Android系统的本地服务

3.2 Android本地守护进程

由上节可知，最后一个Action boot的最后一个Command为class_startdefault，用来启动所有class为default的Service，其实在init.rc里定义的Service其class类别都没有定义，都使用default，这也意味着所有的Service都会被class_startdefault命令启动，下面列表了Android2.3中的一些主要Service：

Service	对应程序及参数	Options
ueventd	/sbin/ueventd	critical
console	/system/bin/sh	console，disabled，user shell，group log
adbd	/sbin/adbd	disabled
servicemanager	/system/bin/servicemanager	user system，critical，onrestart restart zygote，onrestart restart media
vold	/system/bin/vold	socket vold stream 0660 root mount，ioprio be 2
netd	/system/bin/netd	socket netd stream 0660 root system
debuggerd	/system/bin/debuggerd	无
ril-daemon	/system/bin/rild	socket rild stream 660 root radio，socket rild-debug stream 660 radio system，user root，group radio cache inet misc audio sdcard_rw
surfaceflinger	/system/bin/surfaceflinger	user system，critical，onrestart restart zygote，onrestart restart media
zygote	/system/bin/app_process -Xzygote /system/bin --zygote--start-system-server	socket zygote stream 666，onrestart write /sys/android_power/request_state wake，onrestart write /sys/power/state on，onrestart restart media，onrestart restart netd
media	/system/bin/mediaserver	user media      group system audio camera graphics inet net_bt net_bt_admin net_rawioprio rt 4

init进程将init.rc中的Services解析之后，存放到service_list链表中，这些service的options用来修辞并影响Service的运行，下面我们将一些重要的Service单独进行介绍。

3.2.1 ueventd进程

         与Linux相同，Android中的应用程序驱动来访问硬件设备。设备节点文件是设备驱动的逻辑文件，应用程序使用设备节点文件来访问设备驱动程序。在Linux中，使用mknod命令来创建设备节点文件，但出于安全考虑，Android未提供类似mknod的命令，而是使用了类似Linux系统中的udev方式来实现对设备的管理，在Android中类似udev功能的进程称为ueventd守护进程，其源码为system/core/init/devices.c。

         在Android系统中，init进程通过两种方式创建设备节点文件。第一种，以预先定义的设备信息为基础，当init进程被启动运行时，统一创建设备节点文件，通常称为ColdPlug（冷插拔）。第二种，在系统运行中，当有设备插入USB端口时，init进程就会接收到这一事件，动态的为新插入设备创建设备节点文件，这种方式通常称为Hot Plug（热插拔）。这两种方式都由ueventd实现。

         在Android系统中，Cold Plug方式是通过事先定义好各驱动程序所需的设备节点文件，这些定义的设备节点信息保存在Android根文件系统中的/ueventd.rc中：

/dev/null                0666   root      root

/dev/zero               0666   root      root

/dev/full                 0666   root      root

/dev/ptmx              0666   root      root

/dev/tty                  0666   root      root

/dev/random          0666  root       root

/dev/urandom        0666  root       root

/dev/ashmem        0666  root       root

/dev/binder           0666   root      root

 

# logger should be worldwritable (for logging) but not readable

/dev/log/*               0662   root      log

 

# the msm hw3d clientdevice node is world writable/readable.

/dev/msm_hw3dc   0666  root       root

 

# gpu driver for adreno200is globally accessible

/dev/kgsl                 0666   root      root

 

# these should not beworld writable

/dev/diag                 0660   radio     radio

/dev/diag_arm9      0660  radio      radio

/dev/android_adb    0660  adb        adb

/dev/android_adb_enable   0660  adb        adb

第一列定义了设备文件名，第二列定义了设备文件的访问权限，第三、四列定义了设备文件的用户、组名。该脚本由ueventd守护进程解释执行，因此，如果用户自己编写了驱动程序想让系统帮我们创建设备节点，可以在ueventd.rc中添加对应的设备信息即可。

         对于Hot Plug的实现，则要依赖于内核的实现。当设备被插入时，内核就会加载则需要与该设备相关的驱动程序，而后设备驱动通过device_create将设备信息写入到sysfs文件系统中，然后内核发出uevent事件。而ueventd守护进程就用来等待接收uevent事件，然后读取sysfs里的设备信息，自动创建设备节点。

 

图 xx-xx ueventd创建设备节点文件

 

3.2.2adbd进程

adbd进程是adb调试桥的服务器端，它的实现在system/core/adb目录下，当我们在ecilpse开发环境里高度程序时，在移动设备里必须运行adbd守护进程，二者之间通过Socket进行通信。

 

图 xx-xx  adb调试示意图

3.2.3 servicemanager进程

Servicemanager即：服务管理器，是整个Android系统里服务的大总管，它用来管理Android系统所提供的各种服务Service（这个服务并非init.rc中定义的Service），如ActivityManagerService、PowerManagerService、PackageManagerService等，这些Android服务用于为用户程序提供功能，而Servicemanager则用于管理这些服务的注册、查找、检查等操作，对Android系统的运行环境有着至关重要的作用，它的源码在frameworks/base/cmds/servicemanager/目录下。

3.2.4 vold进程

Vold（volume daemon）是负责完成系统的CDROM,USB大容量存储，MMC卡等扩展存储的插拨、挂载、卸载、格式化等任务的守护进程。

在Android系统中和Vold联系最密切的是框架层的MountService，一方面，Vold接收来自Linux内核的ueventd消息，并将其转发给MountService，而后MountService将具体对外部存储设备的操作发送给Vold，让Vold做出最终的挂载、卸载、格式化等处理。

 

图 xx-xx vold架构图

 

3.2.5 ril-daemon进程

RIL即：Radio Interface Layer，它是移动设备中无线设备的抽象层，在手机中实现通信功能必须使用Modem硬件，由于Android系统的使用的Modem可能不一样，所以在通信时Modem的初始化序列和操作的执行指令格式不一样，Android为了消除这些差异，减少上层应用程序对底层硬件的直接依赖，设计出了RIL架构，它使用“虚拟电话”的概念，即在Framework层为应用层提供的API是一些抽象接口，而对于这些API的实际操作，则交给Rild，即ril-daemon守护进程实现。Rild起到了手机通信的翻译官的作用。

在Framework层和应用程序直接打交道的是TelephonyManager，它和本地守护进程Rild通过Socket通信，将应用程序的操作（打电话，信息，GPRS等）交给Rild来实现，rild通过ril硬件抽象层来抽象分离Android和Modem硬件的耦合依赖度，将上层的操作转换成Modem可识别的语言：AT指令，控制与Modem的通信。

 

图 xx-xx Ril架构图

 

 

3.2.6 surfaceflinger进程

         在Android系统中任何在屏幕上显示的界面都要经过Surfaceflinger的整合，它是Android系统的显示核心处理单元。

         在Android中，不论是二维图像，还是3D的图像都要在一个Surface上绘制，Surface就好像是一个画布，让应用程序尽情的在上面表现，又由于在手机屏幕上同一时间很有可以显示两个应用程序的界面，所以将所有在屏幕上显示的界面要经过一个“整合器”，整合到一个屏幕上显示出来，这个整合器叫做SurfaceFlinger，最终通过FrameBuffer显示出来。

 

图 xx-xx SurfaceFlinger框架图