MagiskDocument

英文

Android 引导诡计

术语

以下是一些参数,可帮助您更精确地定义设备的 Android 版本:

我们将使用 Android API 级别 来表示 LV 和 RV 。API 级别和 Android 版本之间的映射可以在这张表格中看到。例如:Pixel XL 随 Android 7.1 发布,并运行 Android 10,这些参数将为 (LV = 25, RV = 29)

引导方法

Android 启动可以大致分为 3 种主要的不同方法。我们提供了一个一般的经验法则,以确定您的设备最有可能使用哪种方法,但例外情况单独列出。

方法 初始根目录 最终根目录
A rootfs rootfs
B system system
C rootfs system

讨论

从文档来看,谷歌对 SAR 的定义只考虑了内核如何引导设备(上表中的初始根目录),这意味着从谷歌的角度来看,只有使用方法B的设备才被正式视为 SAR 设备。

然而,对于 Magisk 来说,真正的区别在于设备在完全启动时使用的是什么(上表中的最终根目录),这意味着就 Magisk 而言,方法 B 和方法 C 都是 SAR 的一种形式,但实施方式不同。除非另有特别说明,否则本文件后面提到的每一个 SAR 实例都将参考 Magisk 的定义

通俗地说,方法 C 的标准有点复杂:您的设备足够现代,可以使用 Android 10+ 启动,或者您在使用方法 A 的设备上运行 Android 10+ 第三方 ROM。

SAR 是 Project Treble 中非常重要的一部分,因为 rootdir 应该与平台绑定。这也是方法 B 和 C 带有 (LV >= ver) 标准的原因,因为谷歌每年都强制所有 OEM 遵守更新的要求。

一些历史

当谷歌发布第一代 Pixel 时,它还推出了 A/B(无缝)系统更新。由于存储大小问题,与仅 A 相比有几个区别,最相关的是删除 recovery 分区和 recovery ramdisk ,合并到boot中。

让我们回到 Google 第一次设计 A/B 的时候。如果使用 SAR(当时只有引导方法 B 存在),内核不需要 initramfs 来引导 Android(因为 rootdir 在 system 中)。这意味着我们可以很聪明,只需将 recovery ramdisk(包含极简的 Linux 环境)塞入 boot ,删除 recovery ,然后让内核根据引导加载程序的信息选择要使用的任何根目录(ramdisk 或 system)。

随着时间从 Android 7.1 到 Android 10 的流逝,谷歌推出了动态分区。这对 SAR 来说是个坏消息,因为 Linux 内核无法直接理解这种新的分区格式,因此无法直接将 system 挂载为 rootdir。这是他们想出引导方法 C 的时候:总是引导到 initramfs ,并让 userspace 处理其余的引导。这包括决定启动到 Android 或 recovery,或者他们正式称之为 USES_RECOVERY_AS_BOOT

一些使用带有 2SI 的 A/B 的现代设备还带有 recovery_a/_b 分区。谷歌的标准正式支持这一点。当 recovery 存储在单独的分区中时,这些设备将只使用 boot ramdisk 引导到 Android。

将这些拼凑在一起

有了上面的所有知识,现在我们可以将所有 Android 设备分类为以下不同类型:

类型 引导方式 分区 2SI boot 里的 ramdisk
I A A-only No boot ramdisk
II B A/B Any recovery ramdisk
III B A-only Any N/A
IV C Any Yes 混合 ramdisk

这些类型按首次可用时的时间顺序排序。

关于 III 类设备的更多详细信息:Magisk 始终安装在引导映像的 ramdisk 中。对于所有其他类型的设备,由于其 boot 分区包含 ramdisk,因此可以通过 Magisk app 或第三方 recovery 中的刷入 ZIP 修补引导映像来轻松安装 Magisk。然而,对于 III 型设备,它们仅限于将 Magisk 安装到 recovery 分区中。Magisk 在正常启动时无法运行;相反,III 类设备用户必须始终重新启动到 recovery,以保持 Magisk 访问。

一些 III 类设备的引导加载程序仍然会接受并提供手动添加到内核 boot 映像中的 initramfs(例如一些小米手机),但许多设备不接受(例如三星 S10,Note 10)。这完全取决于 OEM 如何实现其引导加载程序。