您现在的位置是:首页 >其他 >Android 12 init流程分析网站首页其他

Android 12 init流程分析

dawnminghuang 2024-07-04 11:18:00
简介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/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系统各种各样的服务

  • 总结

  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_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官网的说明
    • 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 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
  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文件包含的内容也类似。

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。