android设备的启动分为三个阶段:Boot Loader, Linux Kernel,Android 系统服务。Android系统实际上是运行在Linux Kernel之上的一系列系统服务进程。init进程是Android中被启动的第一个进程,PID = 0 。它通过解析init.rc脚本来构建出android运行初始化形态(android系统服务程序大多是在这个脚本中被启动)
系统启动流程图可以从这个图里面看出,这个网上找的一张,这里是出处
脚本包括actions、commands、services、options四种类型声明。
actions实际上是响应某个触发(也叫事件),当触发(事件)发生时运行action,格式如下:
on ##触发条件
##要执行的命令
##要执行的命令
...
常见触发有下面几种:
services是可执行程序,形式如下
service []*
pathname表示service程序所在路径,里面有程序源码。因为是可执行程序,所有必须有路径。
commands和options比较多,不一一介绍。
由于还没有编译源码,所有在source中找不到代码路径:\system\core\init\init.c,此处盗用网上一般的init.c分析,下次找到了再自己具体分析。
int main(int argc, char **argv)
{
// 1、设置子进程退出的信号处理函数:sigchld_handler
...
// 2、创建文件夹,并挂载设备
mkdir("/dev", 0755);
mkdir("/proc", 0755);
....
// 3、重定向标准输入输出错误到 /dev/__null__
...
// 4、解析 init.rc 脚本
parse_config_file("/init.rc");
// 5、解析机器相关的配置文件,一般相关的放在init.rc中利用service action调过去
snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);
parse_config_file(tmp);
// 6、建立 uevent,用于与linux kernel交互的socket
...
// 7、初始化及加载属性相关资源
...
// 8、执行 on init 、early-boot 及 boot 片段动作,这些定义于 init.rc 中
/* execute all the boot actions to get us started */
action_for_each_trigger("init", action_add_queue_tail);
drain_action_queue();
/* execute all the boot actions to get us started */
action_for_each_trigger("early-boot", action_add_queue_tail);
action_for_each_trigger("boot", action_add_queue_tail);
9.init进程的处理循环
for(;;) {
// I、执行init.rc 脚本中的动作
drain_action_queue();
// II、执行标志为SVC_RESTARTING的进程,利用fork+execve启动新的进程
restart_processes();
...
}
return 0;
}
在上述init程序启动中,通过解析init.rc,实际上也就陆续启动了其他关键服务,这些服务中最重要的就是ServiceManager,Zygote,SystemServer三个系统服务进程。例如在启动boot触发事件中就有启动Zygote服务。
ServiceManager简称SM,是Android Binder机制中的”DNS服务器”,负责域名(某个Binder服务在SM中注册时提供的名字)到IP地址(由底层Binder驱动分配的值)的解析。SM在init.rc中的描述如下所示
service serviceManager /system/bin/servicemanager
class core #同一个class名(此处为core)的所有服务进程同时启动/停止
user system
group system
critical
onrestart restart zygote
onrestart restart media
onrestart restart surfaceflinger
onrestart restart drm
/system/bin/servicemanager路径表示该服务真正的执行程序在该路径下。当SM每次重启时,其他关键进程如zygote , media, surfaceflinger, drm也会重启。
Android中大多数应用进程和系统进程都是通过Zygote来生成的。zygote进程在内部会先启动虚拟机,继而加载一些必要的系统资源和系统类,最后进入一种监听状态。在后续的运作中,当其他系统模块(比如AMS)希望创建新进程时,只需向zygote进程发出请求,zygote进程监听到该请求后,会相应地“分裂”出新的进程,于是这个新进程在初生之时,就先天具有了自己的Dalvik虚拟机以及系统资源。出自这里。Zygote在init.rc中的描述如下所示
service zygote /system/bin/app_process /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onreatart restart netd
在app_process程序中,最核心的代码是下面这句
...
runtime.start("com.android.internal.os.zygoteInit",startSystemServer?"start-system -server":"");
...
runtime 运行时环境变量启动了虚拟机,让ZygoteInit在虚拟机上运行。Zygote.java文件提供几个static方法在ZygoteInit.java等类中被使用。例如ZygoteInit中的startSystemServer方法调用了 Zygote.forkSystemServer()方法。(实际上startSystemServer方法也是ZygoteInit主要作用之一)。
ZygoteInit的作用:
static void main() {
Log.d(TAG, "begin preload");
registerZygoteSocket();
preloadClasses();
preloadResources();
startSystemServer();
runSelectLoop();
closeServerSocket();
}
SystemServer是Android进入Launcher之前的最后准备,它提供了众多的java语言系统服务。由ZygoteInit中的startSystemServer经过层层调用(包括native code),最后到达SystemServer中的run()方法。在run()方法中:
...
// Create the system service manager.
mSystemServiceManager = new SystemServiceManager(mSystemContext);
//应该是添加的第一个LocalService,SSM本身也是服务
LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);
try{
startBootstrapServices();
startCoreServices();
startOtherServices();
}
在startBootstarpServices()中启动并注册了下面几种服务:
在startCoreServices()中启动并注册了下面几种服务:
在startOtherServices()中启动并注册了下面几种服务:
对于zygote,作为一个最原始的“受精卵”,它必须在合适的时机进行必要的细胞分裂。分裂动作也没什么大的花样,不过就是fork()新进程而已。如果fork()出的新进程是system server,那么其最终执行的就是SystemServer类的main()函数,而如果fork()出的新进程是普通的用户进程的话,那么其最终执行的就是ActivityThread类的main()函数。有关ActivityThread的细节,我们有时间再深入探讨,这里就不细说了。上述一段话引用自这里
至此,android启动差不多完成了,原来开机时系统竟然做了这么多事情,66666。下章分析ActivityManagerService,AMS是导致Launcher被启动的关键所在。