不只是system.img：一次性搞懂Android三大镜像（boot/vendor/system）在Linux下的处理全流程

不只是system.img：深度解析Android三大镜像在Linux下的处理全流程

当你第一次拆解Android刷机包时，可能会被里面各种.img文件搞得晕头转向。作为ROM定制开发者，真正需要掌握的核心镜像其实就三个：承载系统核心的boot.img、包含厂商驱动的vendor.img，以及存放系统应用的system.img。这三种镜像看似相似，实则从格式到处理方式都存在关键差异。

在Linux环境下处理这些镜像，就像同时操作三种不同特性的容器——有的可以直接挂载修改，有的需要专用工具拆解，还有的对签名校验极其敏感。本文将带你跳出零散的知识点，用系统化视角对比这三种镜像的处理全流程，从格式识别、工具选择到修改陷阱，最终整合成一套高效的ROM定制工作流。

1. 镜像格式识别：raw与sparse的奥秘

Android镜像的第一道门槛就是识别格式。你可能已经注意到，system.img和vendor.img通常有两种形态：臃肿的raw镜像和精炼的sparse镜像。而boot.img则自成一派，采用特殊的Android定制格式。

1.1 raw ext4镜像：可直接挂载的完整映像

使用file命令检测时，raw镜像会显示如下特征：

$ file system.img
system.img: Linux rev 1.0 ext4 filesystem data, UUID=da594c53-9beb-f85c-85c5-cedf76546f7a

这种镜像的特点包括：

• 完整的ext4分区结构
• 包含大量全零填充区块
• 典型大小在1GB以上
• 可直接通过mount挂载修改

1.2 sparse镜像：节省空间的稀疏格式

sparse镜像的识别特征截然不同：

$ file vendor.img
ven