深入浅出 - 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框架图

mr_raptor CSDN认证博客专家 精益工程 驱动开发
北京同远天下创始人,专注于企业服务,企业系统解决方案,物联网,智慧社区,产品有众狐邮箱验证www.verify-mail.net,众狐微客服系统,著有《深入浅出嵌入式底层软件开发》北航出版社
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 代码科技 设计师:Amelia_0503 返回首页