System_Server进程
运行在system server进程中的服务比较多,这是整个android框架的基础
Native服务
SurfaceFlinger
这是framebuffer合成的服务,将各个应用程序及应用程序中的逻辑窗口图像数据(surface)合成到一个物理窗口中显示(framebuffer)的服务程序
Java服务:
这部分的服务大部分都有一个供应用进程使用的manager类,这就是一个RPC调用,用户通过调用xxxManager的方法,实际上被Binder给迁移到system_server进程中对应的xxxManagerService中对应的方法,并将结果再通过binder带回。
1.EntropyService
熵服务,周期性的加载和保存随机信息。主要是linux开机后,/dev/random的状态可能是可预知的,这样一些需要随机信息的应用程序就可能会有问题。这个无需提供应用程序接口。
2.PowerManagerService –> PowerManager
Android的电源管理也是很重要的一部分。比如在待机的时候关掉不用的设备,待机时屏幕和键盘背光的关闭,用户操作的时候该打开多少设备等等。
3. ActivityManagerService->ActivityManager
这个是整个Android framework框架中最为核心的一个服务,管理整个框架中任务、进程管理, Intent解析等的核心实现。虽然名为Activity的Manager Service,但它管辖的范围,不只是Activity,还有其他三大组件,和它们所在的进程。也就是说用户应用程序的生命管理,都是由他负责的。
4. TelephonyRegistry->TelephonyManager
电话注册、管理服务模块,可以获取电话的链接状态、信号强度等等。<可以删掉,但要看的大概明白>
5. PackageManagerService -> PackageManager
包括对软件包的解包,验证,安装以及升级等等,对于我们现在不能安装.so文件的问题,应该先从这块着手分析原因。
6. AccountManagerService -> AccountManager
A system service that providesaccount, password, and authtoken management for all
accounts on the device。
7.ContentService -> ContentResolver
内容服务,主要是数据库等提供解决方法的服务。
8.BatteryService
监控电池充电及状态的服务,当状态改变时,会广播Intent
9.HardwareService
一般是ring和vibrate的服务程序
10.SensorService -> SensorManager
管理Sensor设备的服务,负责注册client设备及当client需要使用sensor时激活Sensor
11.WindowManagerService -> WindowManager -> PhoneWindowManager
和ActivityManagerService高度粘合
窗口管理,这里最核心的就是输入事件的分发和管理。
12.AlarmManagerService -> AlarmManager
闹钟服务程序
13.BluetoothService -> BluetoothDevice
蓝牙的后台管理和服务程序
14.StatusBarService -> StatusBarManager
负责statusBar上图标的更新、动画等等的服务,服务不大。
15.ClipboardService -> ClipboardManager
和其他系统的clipBoard服务类似,提供复制黏贴功过。
16.InputMethodManagerService -> InputMethodManager
输入法的管理服务程序,包括何时使能输入法,切换输入法等等。
17.NetStatService
手机网络服务
18.ConnectivityService -> ConnectivityManager
网络连接状态服务,可供其他应用查询,当网络状态变化时,也可广播改变。
19.AccessibilityManagerService-> AccessibilityManager
这块可能要仔细看一下,主要是一些View获得点击、焦点、文字改变等事件的分发管理,对整个系统的调试、问题定位等,也需要最这个服务仔细过目一下。
20.NotificationManagerService -> NotificationManager
负责管理和通知后台事件的发生等,这个和statusbar胶黏在一起,一般会在statusbar上添加响应图标。用户可以通过这知道系统后台发生了什么事情。
21.MountService
磁盘加载服务程序,一般要和一个linux daemon程序如vold/mountd等合作起作用,主要负责监听并广播device的mount/unmount/bad removal等等事件。
22.DeviceStorageMonitorService
监控磁盘空间的服务,当磁盘空间不足10%的时候会给用户警告
23.LocationManagerService -> LocationManager
要加入GPS服务等,这部分要细看,现在应用中的navigation没响应,可以从此处着手看一下
24.SearchManagerService -> SearchManager
The search manager service handles the search UI, and maintains a registry of searchable activities.
25.Checkin Service(FallbackCheckinService)
貌似checkin service是google提供的包,没有源代码,源码只有fallbackCheckinService
26.WallpaperManagerService -> WallpaperManager
管理桌面背景的服务,深度定制化桌面系统,需要看懂并扩展<同时要兼容>这部分
27.AudioService -> AudioManager
AudioFlinger的上层管理封装,主要是音量、音效、声道及铃声等的管理
28.HeadsetObserver
耳机插拔事件的监控小循环
29.DockObserver
如果系统有个座子,当手机装上或拔出这个座子的话,就得靠他来管理了
30.BackupManagerService -> BackupManager
备份服务
31.AppWidgetService -> AppWidgetManager
Android可以让用户写的程序以widget的方式放在桌面上,这就是这套管理和服务的接口
32.StatusBarPolicy
管理哪个图标该在status bar上显示的策略。
mediaServer服务进程
MediaServer服务基本上都是native的services,mediaServer进程也是在init.rc中启动的,它不是一个daemon进程,这点容易搞混。他也是和systemserver进程类似的系统服务进程,提供应用进程的RPC调用的真正服务代码所运行的位置。其服务都是和媒体录播放有关,主要有三个服务:
AudioFlinger
声音的录播放服务,包括混音等
MediaPlayerService
提供媒体播放服务,opencore是这块的核心模块,对java端的接口在mediaplayer.java
CameraService
提供camera的录制、preview等功能的服务
AudioPolicyService
主要功能有检查输入输出设备的连接状态及系统的音频策略的切换等。
9.4.1 启动各种系统服务线程
SystemServer进程在Android的运行环境中扮演了"神经中枢"的作用,APK应用中能够直接交互的大部分系统服务都在该进程中运行,常见的比如WindowManagerServer(Wms)、ActivityManagerSystemService(AmS)、PackageManagerServer(PmS)等,这些系统服务都是以一个线程的方式存在于SystemServer进程中。下面就来介绍到底都有哪些服务线程,及其启动的顺序。
SystemServer的main()函数首先调用的是init1()函数,这是一个native函数,内部会进行一些与Dalvik虚拟机相关的初始化工作。该函数执行完毕后,其内部会调用Java端的init2()函数,这就是为什么Java源码中没有引用init2()的地方,主要的系统服务都是在init2()函数中完成的。
该函数首先创建了一个ServerThread对象,该对象是一个线程,然后直接运行该线程,如以下代码所示:
![]() |
于是,从ServerThread的run()方法内部开始真正启动各种服务线程。
基本上每个服务都有对应的Java类,从编码规范的角度来看,启动这些服务的模式可归类为三种,如图9-3所示。
![]() |
图9-3 不同服务的启动方式 |
模式一是指直接使用构造函数构造一个服务,由于大多数服务都对应一个线程,因此,在构造函数内部就会创建一个线程并自动运行。
模式二是指服务类会提供一个getInstance()方法,通过该方法获取该服务对象,这样的好处是保证系统中仅包含一个该服务对象。
模式三是指从服务类的main()函数中开始执行。
无论以上何种模式,当创建了服务对象后,有时可能还需要调用该服务类的init()或者systemReady()函数以完成该对象的启动,当然这些都是服务类内部自定义的。为了区分以上启动的不同,以下采用一种新的方式描述该启动过程。比如当一个服务对象是通过模式一创建,并调用init()完成该服务的启动,我们就用模式1.2表示;如果构造函数返回后就已经启动,而无须任何其他调用,即什么都不做(nothing),我们就用模式1.1表示。
表9-2列出了SystemServer中所启动的所有服务,以及这些服务的启动模式。
表9-2 SystemServer中启动服务列表
服务类名称 | 作用描述 | 启动模式 |
EntropyService | 提供伪随机数 | 1.0 |
PowerManagerService | 电源管理服务 | 1.2/3 |
ActivityManagerService | 最核心的服务之一,管理Activity | 自定义 |
TelephonyRegistry | 通过该服务注册电话模块的事件响应,比如重启、关闭、启动等 | 1.0 |
PackageManagerService | 程序包管理服务 | 3.3 |
AccountManagerService | 账户管理服务,是指联系人账户,而不是Linux系统的账户 | 1.0 |
ContentService | ContentProvider服务,提供跨进程数据交换 | 3.0 |
BatteryService | 电池管理服务 | 1.0 |
LightsService | 自然光强度感应传感器服务 | 1.0 |
VibratorService | 震动器服务 | 1.0 |
AlarmManagerService | 定时器管理服务,提供定时提醒服务 | 1.0 |
WindowManagerService | Framework最核心的服务之一,负责窗口管理 | 3.3 |
BluetoothService | 蓝牙服务 | 1.0 + |
DevicePolicyManagerService | 提供一些系统级别的设置及属性 | 1.3 |
StatusBarManagerService | 状态栏管理服务 | 1.3 |
ClipboardService | 系统剪切板服务 | 1.0 |
InputMethodManagerService | 输入法管理服务 | 1.0 |
NetStatService | 网络状态服务 | 1.0 |
NetworkManagementService | 网络管理服务 | NMS.create() |
ConnectivityService | 网络连接管理服务 | 2.3 |
ThrottleService | 暂不清楚其作用 | 1.3 |
(续表)
服务类名称 | 作用描述 | 启动模式 |
AccessibilityManagerService | 辅助管理程序截获所有的用户输入,并根据这 些输入给用户一些额外的反馈,起到辅助的效果 | 1.0 |
MountService | 挂载服务,可通过该服务调用Linux层面的mount程序 | 1.0 |
NotificationManagerService | 通知栏管理服务,Android中的通知栏和状 态栏在一起,只是界面上前者在左边,后者在右边 | 1.3 |
DeviceStorageMonitorService | 磁盘空间状态检测服务 | 1.0 |
LocationManagerService | 地理位置服务 | 1.3 |
SearchManagerService | 搜索管理服务 | 1.0 |
DropBoxManagerService | 通过该服务访问Linux层面的Dropbox程序 | 1.0 |
WallpaperManagerService | 墙纸管理服务,墙纸不等同于桌面背景, 在View系统内部,墙纸可以作为任何窗口的背景 | 1.3 |
AudioService | 音频管理服务 | 1.0 |
BackupManagerService | 系统备份服务 | 1.0 |
AppWidgetService | Widget服务 | 1.3 |
RecognitionManagerService | 身份识别服务 | 1.3 |
DiskStatsService | 磁盘统计服务 | 1.0 |
AmS的启动模式如下:
调用main()函数,返回一个Context对象,而不是AmS服务本身。
调用AmS.setSystemProcess()。
调用AmS.installProviders()。
调用systemReady(),当AmS执行完systemReady()后,会相继启动相关联服务的systemReady()函数,完成整体初始化。
关于具体某个服务的内部启动过程,请参照源码,这些过程一般都比较简单。