前言
- 刚开始接触需要了解的概念
- 理解过程遇到了什么问题
- 代码的位置和流程分析
- 如何分析和调试遇到的问题
基本的概念
-
.rc 文件
这个文件在Android framework 中服务相关代码可以看到。类似surfaceflinger.rc 、mediaserver.rc等等。 在这些rc里面定义了某一个service，如下面的surfaceFlinger.rc定义了surfaceflinger 这样一个service，其应用程序的路径在/system/bin/surfaceflinger，是属于core 这一类别，还有其他详细的信息在后面说明
service surfaceflinger /system/bin/surfaceflinger class core animation经常在看rc文件会产生相关的问题：
-
rc文件在哪里解析的？
rc文件在init进程的第二阶段进行解析，init进程启动后没有马上就开启rc文件的解析。会先进行一些必要准备工作。
-
rc中定义的service进程是怎么启动的？
rc中定义service 一般是一个应用程序，执行这个应用程序，就是执行程序里面的main。 在init进程启动后解析到service名字后开始执行，但是service不是解析到一个service标签就执行一个，跟service所处的阶段的标记有关系。比如是在early-init、init、late-init等等。某个标记里面所有的service都解析出来了会一个个生成进程去执行。
-
怎么理解rc文件定义的各个项？
主要是几个关键值的确认
on：定义条件比如on init，表示在init这个条件成立的时间执行 -
init中各个标签init early-init 等等是什么时候执行的？
首先在代码中是按照early-init、init、late-init这样的顺序去执行的，在 init.rc中就按照下面的顺序去trigger一系列的标签。这些标签定义的service就有了先后关系。比如init标签定义的service是需要等early-init中所有的service 执行后在执行，但这边并不会等待sevice执行而是起一个进程去执行。除了exec_start 执行的serivice， exec_start执行的 服务需要等待这个服务执行完成才能执行排在他之后的。一般是用在相互之间有依赖关系的服务。
on late-init trigger early-fs trigger fs trigger post-fs trigger late-fs trigger post-fs-data trigger load_persist_props_action trigger load_bpf_programs trigger zygote-start trigger firmware_mounts_complete trigger early-boot trigger boot
-
-
init 进程
init 进程是Android 启动的第一个进程，启动过程中从内核空间到用户空间启动的第一个进程，进程号为1。
- init进程执行了哪些流程？如果目标是缩短某个服务的启动时间，要关注哪些方面？
如果关注启动的时间，那么要找到某个服务之前的所有服务，看哪些是必要。同时要特别注意那么exec_start的服务。
- init 读取各个路径下的rc文件 如何看哪些是会耗时的？
android init默认有相关的日志，需要在kernel中去掉打印速率的限制。 - android 系统下面的各个路径什么时候创建，怎么创建的？
跟具体的目录相关，一部分如system/vendor 在init第一阶段，一部分在init.rc文件 - property属性服务什么时候启动的，在什么阶段能够获取到设置的某个属性的值。
- apex是什么？ 如何影响开机时间?
init进程流程
-
main函数，init进程也是一个bin，其名字就是init.bin。对于一个bin一般就存在一个mian 函数，main函数肯定就可以传递执行的参数。 在init的main函数里面也是一样的。默认从kernel起来的时候是没有参数的，这个时候执行的 FirstStageMain.
-
FirstStageMain 执行完调用main传递 selinux_setup ，执行 SetupSelinux 。 SetupSelinux 执行完调用main传递 second_stage 执行 second_stage 。所以init的流程就可以分为这样三个流程。
-
FirstStageMain
- DoFirstStageMount: 初始化一些必须的分区 主要去解析/proc/device-tree/firmware/android/fstab, 得到"/system", “/vendor”, "/odm"三个目录的挂载信息
-
second_stage
-
新建epoll并初始化子进程终止信号处理函数，
-
建立属性服务property_service
-
解析init.rc等文件，启动android系统各种各样的服务
-
-
总结
- first 完成目录的创建 基本的文件目录的挂载 system、vendror 等目录解析
- system/etc/init、vendor/etc/init下所有的.rc文件
- rc文件，重要的init.rc 和其他分散在各个目录的services相关的rc
- 按照early-init init late-init这几个标签的先后顺序 执行标签中的任务比如创建文件夹 修改权限等。
- services 的start，start是启动一个进程来进行相关服务执行，不会等待服务执行完成
- exec_start必须等待服务执行完成之后才进行下一个services。用后续服务需要依赖的关键服务
property_service
问题：在rc文件中类似下面需要property属性来判断执行时机的service。最快可以在init的什么时候执行。
换句话就是最快什么时候getprop可以从系统中获取到属性。
on property:vold.decrypt=trigger_shutdown_framework
class_reset late_start
class_reset main
class_reset_post_data core
class_reset_post_data hal
- init.rc定义 on late-init 中的trigger load_persist_props_action会启动属性服务执行
- 其调用builtins do_load_persist_props，发送消息到propertyserviceThread 中进行处理
- 线程中会进行一系列的权限检查 然后调用PropertySet进行设置，这个时候系统就可以获取到这个属性设置属性的时候
- 同时会唤醒init进程的主线程 然后将on依赖于属性的action 放入到执行队列中进行执行。
总结：在late-init 之后才可以获取属性的值。
APEX
- Android官网的说明
对于init来说，就是有些系统库是通过APEX的服务来解压 生成的。如果没有apex的服务，会缺失某个库导致依赖于apex的服务起不来。
-
early init的时候启动 apexd-bootstrap 这个服务。
-
而在post-fs-data中启动apex完整的服务，这个是在late init中在trigger load_persist_props_action之前。
-
apex的启动过程 会告知其他服务apex已经启动，会设置 apexd.status的属性为ready。
问题调试
-
log打印
修改kernel下面的代码 重新编译kernel。这样有关启动阶段的action和耗时都会打印出来。
依据下面的log就可以分析相关的耗时问题。
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index e2534757a4f14..5cbb6f17e2b8d 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -734,8 +734,8 @@ static ssize_t devkmsg_write(struct kiocb *iocb, struct iov_iter *from) /* Ratelimit when not explicitly enabled. */ if (!(devkmsg_log & DEVKMSG_LOG_MASK_ON)) { - if (!___ratelimit(&user->rs, current->comm)) - return ret; + // if (!___ratelimit(&user->rs, current->comm)) + // return ret; }Line 1968: [ 6.297233][ T1] init: Service 'boringssl_self_test32' (pid 307) exited with status 0 waiting took 0.079000 seconds Line 1974: [ 6.364255][ T1] init: Service 'boringssl_self_test64' (pid 309) exited with status 0 waiting took 0.065000 seconds Line 1994: [ 6.508128][ T1] init: Service 'boringssl_self_test32_vendor' (pid 314) exited with status 0 waiting took 0.025000 seconds Line 2000: [ 6.522300][ T1] init: Service 'boringssl_self_test64_vendor' (pid 315) exited with status 0 waiting took 0.011000 seconds
surfaceFlinger.rc 文件解析
service surfaceflinger /system/bin/surfaceflinger
class core animation
user system
group graphics drmrpc readproc
capabilities SYS_NICE
onrestart restart --only-if-running zygote
task_profiles HighPerformance
socket pdx/system/vr/display/client stream 0666 system graphics u:object_r:pdx_display_client_endpoint_socket:s0
socket pdx/system/vr/display/manager stream 0666 system graphics u:object_r:pdx_display_manager_endpoint_socket:s0
service surfaceflinger /system/bin/surfaceflinger: 定义了一个名为 “surfaceflinger” 的服务，并指定了服务的可执行文件路径为 “/system/bin/surfaceflinger”。class core animation: 指定了服务的 class（类别），在这里是 “core” 和 “animation”。这些类别用于权限控制和进程调度。user system: 指定了运行服务的用户为 “system”。group graphics drmrpc readproc: 指定了服务所属的用户组。在这里，服务属于 “graphics”、“drmrpc” 和 “readproc” 用户组。capabilities SYS_NICE: 指定了服务的特殊权限，这里是 “SYS_NICE”。它允许服务在调度上具有更高的优先级。onrestart restart --only-if-running zygote: 指定了在服务重新启动时要执行的命令。这里是当 zygote 进程正在运行时才重新启动服务。task_profiles HighPerformance: 指定了任务配置文件（task profile）为 “HighPerformance”。这可以影响服务的资源分配和调度。socket pdx/system/vr/display/client stream 0666 system graphics u:object_r:pdx_display_client_endpoint_socket:s0: 定义了一个名为 “pdx/system/vr/display/client” 的 UNIX 域套接字（socket），并指定了套接字的权限、所有者和安全上下文。socket pdx/system/vr/display/manager stream 0666 system graphics u:object_r:pdx_display_manager_endpoint_socket:s0: 定义了一个名为 “pdx/system/vr/display/manager” 的 UNIX 域套接字（socket），并指定了套接字的权限、所有者和安全上下文。
基本是其他的rc文件包含的内容也类似。