深入浅出 - Android系统移植与平台开发(八)- Android系统的本地服务
2016-07-01 15:12
597 查看
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 |
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框架图
相关文章推荐
- Android 图片压缩也即生成缩略图方法
- 怎么去掉工程中无用的so包(Realm的坑)
- 在Android上面如何使用带有心跳检测的Socket
- Android jni helloworld
- android 基础之配置文件
- Android Studio常见错误归纳
- Launcher3--加载流程
- 【技术分享】Android应用安全开发之浅谈加密算法的坑
- Android录音功能Android Studio实现
- Android命令Monkey压力测试,详解
- 深入浅出 - Android系统移植与平台开发(七)- Android系统的启动
- Android WebView JS交互 混淆打包需要注意的问题
- Android中使用Handler造成内存泄露的分析和解决
- Android实际开发问题11_数字密码输入器
- Android 自定义View 分区域监听 回调
- Android加载大图
- Android中ListView异步加载图片错位、重复、闪烁问题分析及解决方案
- InputStream与String,Byte之间互转
- android studio 拿到sha1
- Android中Bitmap处理注意问题