Magisk原理之系统启动流程
由于经历多个版本Android的核心启动流程方式发生多次改变，我们不一一讨论
本文重点讨论Android10的启动流程
从 Android 10 开始，Google 推出了新的 两阶段初始化机制，也被称为 2SI（Two-Stage Init），来优化系统启动流程。这种机制主要为了支持分区系统（Project Treble）和动态系统更新（Dynamic System Updates, DSU），将系统初始化逻辑分为两个阶段。
术语
- initramfs：android boot.img中的一部分，内核会将它处理成rootfs（就是初始的根文件系统），更常见的说法是ramdisk
第一阶段：First-Stage Init
加载并解压 boot.img
在设备上电后，Bootloader 加载 boot.img，并解压出 内核（kernel） 和 初始 RAM 磁盘（ramdisk.img）。
ramdisk.img 被解压为内存中的临时根文件系统。
使用 ramdisk.img 中的第一阶段 init 作为入口程序。
完成 早期关键初始化 工作（挂载分区、加载 SELinux 策略等）。
挂载关键分区（如 system、vendor 等）后，切换根文件系统到 system 分区，并交给第二阶段 init。
第二阶段：Second-Stage Init
第二阶段 init 是完整的 Android 初始化进程：
从 system 分区加载。
解析并执行初始化配置文件（如 init.rc）。
启动各个系统服务。
- Zygote：启动 Java 虚拟机，负责创建 Java 进程。
- SurfaceFlinger：图形显示服务。
- 其他服务：例如 logd、vold、netd 等。
boot.img格式
我们先来了解一下第一阶段的init是从哪里来的，正常情况它是来着boot.img的ramdisk
这个ramdisk在系统引导节点将临时作为根文件系统，依赖这个临时作为根文件系统，我们将执行其中的init
boot.img解压后的目录
output_dir/
├── kernel # 解压出来的内核文件
├── ramdisk.img # 初始 RAM 磁盘
├── dtb # 设备树文件（如果有）
└── header.txt # boot.img 的头部信息
ramdisk.img解压后的目录
ramdisk/
├── init # 第一阶段的 init 文件
├── fstab.<device> # 分区挂载信息
├── sepolicy # SELinux 策略
├── init.rc # 初始化配置文件
└── ... # 其他启动相关文件
实测解压boot.img
使用abootimg解压
abootimg -x abootimg/boot.img
gzip -dc initrd.img | cpio -id
lineage21解压ramdisk获得的目录
total 3536
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 debug_ramdisk
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 dev
-rw-r----- 1 kali kali 2807 Dec 16 22:56 fstab.qcom
-rwxr-x--- 1 kali kali 3583120 Dec 16 22:56 init
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 metadata
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 mnt
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 proc
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 second_stage_resources
drwxr-xr-x 2 kali kali 4096 Dec 16 22:56 sys
drwxr-xr-x 3 kali kali 4096 Dec 16 22:56 system
Pixel2 Android8解压ramdisk获得的目录
[图片上传失败...(image-467c73-1739457818982)]
解压小米MIX3(system-as-root) boot.img(未能获得ramdisk)
└─$ abootimg -x boot.img
boot.img: ramdisk size is null
boot.img: not a valid Android Boot Image.
可以看到实际情况不同的Android版本和不同的厂商对boot.img的处理方式都不太一样
源码分析
第一第二阶段的入口都是在这
/system/core/init/main.cpp
int main(int argc, char** argv) {
#if __has_feature(address_sanitizer)
__asan_set_error_report_callback(AsanReportCallback);
#endif
if (!strcmp(basename(argv[0]), "ueventd")) {
return ueventd_main(argc, argv);
}
if (argc > 1) {
if (!strcmp(argv[1], "subcontext")) {
android::base::InitLogging(argv, &android::base::KernelLogger);
const BuiltinFunctionMap function_map;
return SubcontextMain(argc, argv, &function_map);
}
if (!strcmp(argv[1], "selinux_setup")) {
return SetupSelinux(argv);
}
if (!strcmp(argv[1], "second_stage")) {
// 第二阶段 init 入口
return SecondStageMain(argc, argv);
}
}
// 第一阶段 init 入口
return FirstStageMain(argc, argv);
}
第一次当然会走第一阶段的 FirstStageMain
int FirstStageMain(int argc, char** argv) {
// 挂载分区、挂载/dev、/proc、sys/fs/selinux
......
InitKernelLogging(argv);
DoFirstStageMount();
// 这里可以看到又再一次执行了init，依照给的selinux_setup参数 这个时候会回到上面的SetupSelinux
const char* path = "/system/bin/init";
const char* args[] = {path, "selinux_setup", nullptr};
auto fd = open("/dev/kmsg", O_WRONLY | O_CLOEXEC);
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
close(fd);
execv(path, const_cast<char**>(args));
}
在执行 SetupSelinux 的时候，system 分区已经被挂载，并替换为了文件根系统。
SetupSelinux 此时相关的分区也已经挂载 这里应该就是执行system分区的init了
这是通过 第一阶段 init 过程中挂载 system 分区的操作所完成的。
int SetupSelinux(char** argv) {
SetStdioToDevNull(argv);
InitKernelLogging(argv);
MountMissingSystemPartitions();
// Set up SELinux, loading the SELinux policy.
// 加载 SELinux 策略，并初始化 SELinux
SelinuxSetupKernelLogging();
SelinuxInitialize();
if (selinux_android_restorecon("/system/bin/init", 0) == -1) {
PLOG(FATAL) << "restorecon failed of /system/bin/init failed";
}
//这里就执行第二阶段的init了
const char* path = "/system/bin/init";
const char* args[] = {path, "second_stage", nullptr};
execv(path, const_cast<char**>(args));
return 1;
}
总结
第一阶段 init：
使用 boot.img 中的 ramdisk.img 提供的临时根文件系统。
挂载关键分区（如 system），为第二阶段准备环境。
第二阶段 init：
切换到完整根文件系统，解析 init.rc 并启动系统服务。
所以需要在启动阶段对系统进行修改，就要替换第一阶段的init，也就是ramdisk的init文件，
在此处可以进行System分区文件的替换修改操作，因为此时真正的文件根系统还没有挂载
在修改完成后，将备份的init还原回去然后继续执行即可回到系统启动流程
