Android 12 init流程分析

前言

1. 刚开始接触需要了解的概念
2. 理解过程遇到了什么问题
3. 代码的位置和流程分析
4. 如何分析和调试遇到的问题

基本的概念

• .rc 文件

  这个文件在Android framework 中服务相关代码可以看到。类似surfaceflinger.rc 、mediaserver.rc等等。 在这些rc里面定义了某一个service，如下面的surfaceFlinger.rc定义了surfaceflinger 这样一个service，其应用程序的路径在/system/bin/surfaceflinger，是属于core 这一类别，还有其他详细的信息在后面说明

  service surfaceflinger /system/bin/surfaceflingerclass 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-inittrigger early-fstrigger fstrigger post-fstrigger late-fstrigger post-fs-datatrigger load_persist_props_actiontrigger load_bpf_programstrigger zygote-starttrigger firmware_mounts_completetrigger early-boottrigger 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系统各种各样的服务

• 总结

1. first 完成目录的创建 基本的文件目录的挂载 system、vendror 等目录解析
2. system/etc/init、vendor/etc/init下所有的.rc文件
3. rc文件，重要的init.rc 和其他分散在各个目录的services相关的rc
4. 按照early-init init late-init这几个标签的先后顺序 执行标签中的任务比如创建文件夹 修改权限等。
5. services 的start，start是启动一个进程来进行相关服务执行，不会等待服务执行完成
6. exec_start必须等待服务执行完成之后才进行下一个services。用后续服务需要依赖的关键服务

property_service

问题：在rc文件中类似下面需要property属性来判断执行时机的service。最快可以在init的什么时候执行。

换句话就是最快什么时候getprop可以从系统中获取到属性。

on property:vold.decrypt=trigger_shutdown_frameworkclass_reset late_startclass_reset mainclass_reset_post_data coreclass_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官网的说明
  • Android Pony EXpress (APEX) 是 Android 10 中引入的一种容器格式，用于较低级别系统模块的安装流程中。此格式可帮助更新不适用于标准 Android 应用模型的系统组件。一些示例组件包括原生服务和原生库、硬件抽象层 (HAL))、运行时 (ART) 以及类库。
  • APEX 管理器（即 apexd）是一个独立的原生进程，负责验证、安装和卸载 APEX 文件。此进程已启动，并在引导序列早期准备就绪。APEX 文件通常预安装在设备的 /system/apex 下。如果没有可用的更新，APEX 管理器默认使用这些软件包。

对于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 secondsLine 1974: [    6.364255][    T1] init: Service 'boringssl_self_test64' (pid 309) exited with status 0 waiting took 0.065000 secondsLine 1994: [    6.508128][    T1] init: Service 'boringssl_self_test32_vendor' (pid 314) exited with status 0 waiting took 0.025000 secondsLine 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/surfaceflingerclass core animationuser systemgroup graphics drmrpc readproccapabilities SYS_NICEonrestart restart --only-if-running zygotetask_profiles HighPerformancesocket pdx/system/vr/display/client     stream 0666 system graphics u:object_r:pdx_display_client_endpoint_socket:s0socket pdx/system/vr/display/manager    stream 0666 system graphics u:object_r:pdx_display_manager_endpoint_socket:s0

1. service surfaceflinger /system/bin/surfaceflinger: 定义了一个名为 “surfaceflinger” 的服务，并指定了服务的可执行文件路径为 “/system/bin/surfaceflinger”。
2. class core animation: 指定了服务的 class（类别），在这里是 “core” 和 “animation”。这些类别用于权限控制和进程调度。
3. user system: 指定了运行服务的用户为 “system”。
4. group graphics drmrpc readproc: 指定了服务所属的用户组。在这里，服务属于 “graphics”、“drmrpc” 和 “readproc” 用户组。
5. capabilities SYS_NICE: 指定了服务的特殊权限，这里是 “SYS_NICE”。它允许服务在调度上具有更高的优先级。
6. onrestart restart --only-if-running zygote: 指定了在服务重新启动时要执行的命令。这里是当 zygote 进程正在运行时才重新启动服务。
7. task_profiles HighPerformance: 指定了任务配置文件（task profile）为 “HighPerformance”。这可以影响服务的资源分配和调度。
8. 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），并指定了套接字的权限、所有者和安全上下文。
9. 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文件包含的内容也类似。