PS:Zygote中文名就是孵化器，通过调用Linux的fork()接口，fork出系统所有的应用进程，是应用进程生命周期的大管家。

 文件路径: /system/core/rootdir/init.rc

PS：init.rc文件一般有两个，一个是上面这个启动模拟器时运行的，还有一个是/device路径下真正的机器上的init.rc。out目录下的init.rc则是根据/device路径下的init.rc拷贝过去的用来打包成system.img的init.rc

 

1.1 导入启动配置文件

import /system/etc/init/hw/init.${ro.zygote}.rc

根据${property} 动态导入对应的 Zygote 启动配置文件。总共有以下几种,

init.zygote64.rc()：定义 64 位架构下的 Zygote 启动配置。

init.zygote32.rc()：定义 32 位架构下的 Zygote 启动配置。

init.zygote64_32.rc()：定义同时支持 64 位和 32 位架构的 Zygote 启动配置。

init.no_zygoite.rc()：定义不启用 Zygote 的启动配置。系统不会启动 Zygote 服务，因此无法通过 Zygote进程fork出应用进程。后续在研究下该配置具体应用场景。

 

1.2 zygote的事件触发器

    trigger zygote-start

代码执行到这，会触发所有的on zygote-start的Action块 ，on后面跟着的就是一个事件名,执行一些命令。PS:这里其实是无限套娃，系统启动就是这样的，trigger触发on,on里面再触发其他后面启动的trigger，从而保证系统的时序。init.rc下的指令不同于Linux的bash指令，是独立设计的专用脚本语言，并非基于 Linux 指令修改而来。

 

  1.2.1 通过上电后正常启动系统触发(冷启动)

# Mount filesystems and start core system services.
 on late-init
     trigger early-fs
 
     # Mount fstab in init.{$device}.rc by mount_all command. Optional parameter
     # '--early' can be specified to skip entries with 'latemount'.
     # /system and /vendor must be mounted by the end of the fs stage,
     # while /data is optional.
     trigger fs
     trigger post-fs
 
     # Mount fstab in init.{$device}.rc by mount_all with '--late' parameter
     # to only mount entries with 'latemount'. This is needed if '--early' is
     # specified in the previous mount_all command on the fs stage.
     # With /system mounted and properties form /system + /factory available,
     # some services can be started.
     trigger late-fs
 
     # Now we can mount /data. File encryption requires keymaster to decrypt
     # /data, which in turn can only be loaded when system properties are present.
     trigger post-fs-data
 
     # Should be before netd, but after apex, properties and logging is available.
     trigger load_bpf_programs
 
     # Now we can start zygote.
     trigger zygote-start
 
     # Remove a file to wake up anything waiting for firmware.
     trigger firmware_mounts_complete
 
     trigger early-boot

late-init里通过trigger继续触发后面系统启动的流程(即on),late-init本身也是被前面系统启动流程所触发，从而保证系统启动时序逻辑的准确。

 

  1.2.2 通过用户空间重启触发（热启动）

 on userspace-reboot-resume
   trigger userspace-reboot-fs-remount
   trigger post-fs-data
   trigger zygote-start
   trigger early-boot
   trigger boot

用户空间重启（userspace reboot）是Android 10+引入的高效重启机制，可跳过内核初始化直接启动系统，节省大量资源重新加载。

 

1.3 触发后，启动zygote服务                                                                                                           

# It is recommended to put unnecessary data/ initialization from post-fs-data
 # to start-zygote in device's init.rc
 to unblock zygote start.
 
on zygote-start
    wait_for_prop odsign.verification.done

    1

    # A/B update verifier that marks a successful boot.

    exec_start update_verifier
 
    start statsd
 
    start netd
 
    start zygote
 
    start zygote_secondary

wait_for_prop odsign.verification.done 1

等待odsign.verification.done 的值变为 1时候才继续往下执行，ODS（On-Device Signing）即核心签名验证完成状态，确保所有执行代码均通过Google官方签名验证，阻断恶意篡改的系统级攻击。

exec_start update_verifier

exec_start指令不同于start指令，它是一个同步指令，必须等update_verifier的服务完成后才能继续向下执行代码。update_verifier服务是Android系统更新机制中的核心安全验证服务，主要负责在系统更新过程中执行分区完整性的验证，确保更新包没有被恶意篡改。是Android可信更新链的核心环节。
 
start statsd

start指令是异步指令，服务启动过程中继续向下执行其他指令，statsd服务负责启动网络管理守护进程，处理网络配置和防火墙规则

start netd

启动网络管理守护进程，处理网络配置和防火墙规则
 
 start zygote
 在一系列安全检查以及启动了一些守护进程后，终于轮到了zygote进程，处理孵化64位寄存器的应用程序。

 start zygote_secondary

zygote_secondary进程主要是兼容以前的旧的应用，处理32位寄存器的应用程序

 

争取每两周一更，加油加油。