Android的img镜像
一个完整的Android img镜像通常由多个文件构成，其中最主要的三个文件分别是boot.img、system.img和recovery.img。
boot.img，即引导镜像文件，包含了kernel（内核）和ramdisk（内存磁盘）等关键信息。这个文件的作用是引导设备启动，加载并运行Android系统的核心组件。
system.img，即系统镜像文件，包含了Android系统的所有文件。这些文件是设备运行Android应用程序和服务的基础，也是设备实现各种功能的关键。
recovery.img，即恢复镜像文件，主要用于恢复系统或进行刷机操作。这个文件同样包含了一个Linux内核（zImage）和一个内存磁盘镜像（ramdisk.img）。与boot.img不同的是，recovery.img中的Linux内核调用的init命令解析的init.rc及其相关文件的内容有一定的差异。这种差异使得设备在启动时可以根据用户的选择，选择使用boot.img中的Linux内核正常启动系统，或者选择使用recovery.img中的Linux内核进入恢复模式，进行系统的恢复或刷机操作。
了解了Android img镜像的基本组成后，我们再来探讨其生成原理。Android img镜像的生成过程实际上是一个打包过程，即将上述提到的各个文件按照一定的规则和结构打包成一个img文件。这个过程通常由专门的工具完成，如make工具等。通过配置相应的Makefile文件，我们可以指定要打包的文件、打包后的文件名以及打包选项等。当执行make命令时，工具会根据Makefile中的配置信息，将各个文件按照指定的结构和规则打包成一个img文件。
生成的img文件可以直接刷入Android设备中，从而实现系统的升级或刷机。在刷机过程中，设备会首先从boot.img或recovery.img中选择一个Linux内核启动系统。如果选择boot.img中的Linux内核，则设备会正常启动并运行Android系统；如果选择recovery.img中的Linux内核，则设备会进入恢复模式，允许用户进行系统的恢复或刷机操作。
在实际应用中，我们可以通过修改img镜像中的文件来实现对Android系统的定制和优化。例如，我们可以替换system.img中的文件来添加或删除系统应用程序，从而改变设备的功能和外观。同时，我们也可以利用recovery.img来备份和恢复系统，以及在设备出现故障时进行刷机修复。
总之，Android的img镜像生成原理涉及到多个文件的打包和组合。通过深入了解其组成和差异，我们可以更好地理解Android系统的升级和刷机过程，从而更好地维护和优化我们的Android设备。
不同 IMG 的打包方式差异
- system.img / vendor.img / product.img
- 这些属于文件系统镜像。编译系统先把对应的文件放到 out/…/system/、out/…/vendor/等临时根目录，再用工具打包：
- 老版本常用 make_ext4fs 或 mkuserimg_mke2fs 打成 ext4 sparse 镜像；
- Android 10+ 很多设备改用 mkfs.erofs 打成 EROFS 只读镜像。
- boot.img / recovery.img
- 不是普通文件系统，而是用 mkbootimg 把内核（kernel Image） + ramdisk.img（cpio 归档） + 偏移参数拼接成单一二进制镜像，同时写入头部信息供 bootloader 解析。
- userdata.img / cache.img
- 通常是创建一个空的文件系统镜像（ext4/ f2fs），格式化后输出，真正的数据是设备首次开机时由系统写入的。
- vbmeta.img
- 由 avbtool 根据其他镜像的哈希值生成，用于 AVB（Android Verified Boot）安全校验签名。
U盘刷机和线刷原理区别
U盘刷机是设备自己从U盘里读镜像并在本地写内部存储，通常运行在 Recovery 或 Bootloader 层级； 线刷是设备被PC通过USB控制，实时接收镜像数据并在 BootROM/Bootloader 层级写入内部存储
设备端运行的程序阶段不同
U盘刷机常见运行阶段
- Recovery 模式（最常见）
- 完整 Linux 内核 + Android 恢复环境
- 挂载 U盘（vfat/exFAT），解析 ZIP，调用 updater/ dd/ 文件系统写入
- Bootloader / SPL 阶段（部分盒子、开发板）
- 支持从 USB Mass Storage 读取 image 并裸写分区
- BootROM 级（少数 SoC）
- ROM 代码支持从 USB 存储引导烧录程序（工厂用） 👉 总体偏向较高层级或可选功能，依赖固件里实现了 U盘 读取和解析能力。 线刷常见运行阶段
- Bootloader / Fastboot
- BootROM（EDL / Download / Preloader） 👉 偏向更底层、标准化、强制存在的烧录通道，通常由 SoC 架构保证。
二、核心解答：SoC 与 Android system_ext/product/vendor 的区别
在图中，8397 SoC 和 Android system_ext/product/vendor 代表了完全不同的软硬件层级和所有权边界。
| 维度 | 8397 SoC（含 lun aios/models） | Android system_ext / product / vendor |
|---|---|---|
| 本质定义 | 硬件芯片及底层 Bootloader/固件层。代表 SoC 厂商（高通）提供的硬件算力与最基础的底层软件环境。 | 操作系统层。代表 Android 开源项目（AOSP）编译出的系统文件，运行在 Linux 内核之上。 |
| 包含内容 | – lun aios: 运行在 SoC 底层或独立安全域的 AI Agent 操作系统。- lun models: 端侧大模型二进制资源。- （隐含）Bootloader、TEE、底层 DSP 固件等。 |
– system_ext: AOSP 核心框架的扩展（如 OEM 深度定制的系统服务）。- product: 设备制造商（OEM）定制的应用、主题、铃声等。- vendor: 芯片供应商（SoC 厂商，如高通）提供的硬件抽象层（HAL）和驱动库。 |
| 所有者 | SoC 供应商（高通）及特定的 AI 软件团队。 | – system_ext/product: Google (AOSP) & OEM（如车企）。- vendor: SoC 供应商（高通等）。 |
| 更新与刷写方式 | – img 刷写 / 线刷包刷写：通常需要进入 EDL（紧急下载）模式或专用的底层刷机模式（如 QFIL）。- 权限极高，可直接操作 UFS 存储。 | – 二进制发布，集成到 super 分区：通过 Recovery、OTA 或 Fastboot 更新 super.img 来间接更新。- 运行时受 Android 框架管理。 |
| 核心职责 | 提供最底层的硬件算力、安全隔离（如 Hypervisor 多 OS 并行）以及极速的 AI 推理环境。 | 提供用户界面、应用运行框架、系统服务以及与硬件交互的标准化接口。 |