深入Super.img：用lpunpack拆解与lpmake命令手动打包Android动态分区镜像
深入Super.img：用lpunpack拆解与lpmake命令手动打包Android动态分区镜像
如果你曾经尝试过修改Android系统镜像，可能会对super.img这个神秘的容器感到好奇。不同于传统的system.img或vendor.img，super.img是一个包含了多个子分区的复合镜像，它代表了Android从静态分区向动态分区架构的重大转变。本文将带你深入这个技术细节，掌握手动拆解和重组super.img的核心技能。
1. 动态分区：Android存储架构的进化
Android的动态分区（Dynamic Partitions）设计始于Android 10（Q），并在Android 11（R）中成为主流。它解决了传统分区方案中几个关键痛点：
- 固定分区大小的限制：在传统方案中，
system、vendor等分区大小在编译时就被固定，无法根据实际需求动态调整 - OTA更新困难：当系统需要增加新功能时，可能需要重新调整分区布局
- 存储空间浪费：每个分区需要预留额外空间，导致整体存储利用率低下
动态分区通过引入super分区概念，将多个逻辑分区（如system、vendor、product）合并到一个物理分区中。这种设计带来了几个显著优势：
| 特性 | 传统分区 | 动态分区 |
|---|---|---|
| 分区大小 | 固定不变 | 可动态调整 |
| 存储利用率 | 较低（需预留空间） | 较高（共享空间池） |
| OTA灵活性 | 受限 | 更灵活 |
| 管理复杂度 | 简单 | 需要额外元数据管理 |
在底层实现上，动态分区利用了Linux内核的device-mapper框架，特别是dm-linear目标。启动时，bootloader会加载super分区，init进程则负责解析其中的元数据，并创建对应的虚拟块设备。
2. 工具链准备：获取lpunpack和lpmake
要操作super.img，我们需要两个关键工具：lpunpack（用于解包）和lpmake（用于打包）。虽然这些工具是AOSP的一部分，但它们默认不会被编译，需要手动构建。
2.1 从源码编译工具
假设你已经配置好了Android编译环境，以下是获取这些工具的步骤：
# 进入AOSP根目录 source build/envsetup.sh lunch aosp_arm64-eng # 或选择你的目标设备 # 单独编译分区工具 make lpunpack lpmake编译完成后，工具会出现在以下路径：
out/host/linux-x86/bin/lpunpackout/host/linux-x86/bin/lpmake
提示：如果你不想编译整个AOSP，也可以只初始化构建环境并单独编译这些工具。
2.2 验证工具可用性
使用--help参数检查工具是否正常工作：
out/host/linux-x86/bin/lpunpack --help out/host/linux-x86/bin/lpmake --help你应该能看到各自的用法说明。如果遇到权限问题，记得给这些二进制文件添加可执行权限。
3. 解构super.img：使用lpunpack深入分析
有了lpunpack，我们就可以开始解剖super.img了。这个镜像通常位于设备的/dev/block/by-name/super或刷机包的super.img中。
3.1 基本解包命令
解包super.img的基本命令格式如下：
lpunpack super.img output_dir/这个命令会将super.img中的所有子分区提取到指定的输出目录。例如：
mkdir unpacked lpunpack super.img unpacked/解包完成后，你会在输出目录中看到类似这样的文件结构：
unpacked/ ├── system.img ├── vendor.img ├── product.img └── system_ext.img3.2 高级解包选项
lpunpack还提供了一些有用的选项：
-p <partition>：只解包指定的分区-v：详细输出模式-s：处理稀疏镜像
例如，只解包system分区：
lpunpack -p system super.img unpacked/3.3 分析解包结果
解包后，你可以使用标准工具进一步分析各个子镜像：
# 检查system.img文件系统类型 file unpacked/system.img # 挂载system.img进行检查 mkdir system_mount sudo mount -o loop unpacked/system.img system_mount对于Android 10+的镜像，你可能会发现它们是erofs文件系统，而不是传统的ext4：
sudo mount -t erofs -o loop unpacked/system.img system_mount4. 重组super.img：掌握lpmake的艺术
解包只是第一步，真正的技术在于如何修改后重新打包。这就是lpmake的用武之地。
4.1 lpmake命令结构
lpmake的基本语法如下：
lpmake --metadata-size <size> \ --metadata-slots <count> \ --device <device_name>:<size> \ --group <group_name>:<size> \ --partition <name>:<attr>:<size>:<group> \ --image <name>=<file> \ --sparse \ --output <output.img>让我们分解这些关键参数：
--metadata-size：元数据区域大小（通常65536字节）--metadata-slots：元数据副本数量（通常2或3）--device：指定super分区设备名和总大小--group：定义分区组及其可用空间--partition：定义单个分区的属性--image：关联分区名和实际镜像文件--sparse：生成稀疏镜像--output：指定输出文件
4.2 实际打包示例
假设我们要打包包含system和vendor分区的super.img，命令可能如下：
lpmake --metadata-size 65536 \ --metadata-slots 2 \ --device super:4294967296 \ --group main:3221225472 \ --partition system:readonly:1610612736:main \ --image system=system.img \ --partition vendor:readonly:1073741824:main \ --image vendor=vendor.img \ --sparse \ --output new_super.img4.3 参数详解
**分区属性（attr）**可以包含以下标志的组合：
readonly：分区只读none：无特殊属性slotselect：支持A/B分区的槽选择
分区组概念允许你将多个分区组织在一起，共享存储空间。这在A/B系统更新中特别有用。
元数据管理是动态分区的核心。--metadata-slots指定了元数据的副本数量，这提高了系统的可靠性。通常建议使用2或3个副本。
5. 实战技巧与常见问题
5.1 确定分区大小
获取正确分区大小的方法：
- 从原
super.img的元数据中提取 - 使用
lpdump工具（如果可用）查看原始配置 - 根据实际镜像文件大小计算
# 获取system.img的实际大小（字节） stat -c %s system.img5.2 处理稀疏镜像
Android系统镜像通常使用稀疏格式节省空间。如果你处理的是稀疏镜像：
- 解包时添加
-s参数 - 打包时添加
--sparse参数 - 可以使用
img2simg和simg2img工具转换格式
5.3 调试技巧
当lpmake失败时，可以：
- 增加
-v参数获取详细输出 - 检查元数据大小是否足够（通常65536字节）
- 确保分区大小总和不超过组大小
- 验证输入镜像的完整性
5.4 AVB2.0验证考虑
如果你修改了分区内容，可能需要处理AVB（Android Verified Boot）验证：
- 更新
vbmeta签名 - 调整hashtree描述符
- 可能需要禁用验证进行测试
# 使用avbtool更新hashtree avbtool add_hashtree_footer --image system.img \ --partition_name system \ --partition_size 1610612736 \ --algorithm SHA256_RSA2048 \ --key testkey.pem \ --salt deadbeef6. 高级应用场景
掌握了这些基础知识后，你可以尝试更高级的操作：
6.1 自定义分区布局
创建完全自定义的动态分区布局：
lpmake --metadata-size 65536 \ --metadata-slots 2 \ --device super:6442450944 \ --group custom:5368709120 \ --partition my_system:readonly:3221225472:custom \ --image my_system=custom_system.img \ --partition my_vendor:readonly:1073741824:custom \ --image my_vendor=custom_vendor.img \ --output custom_super.img6.2 合并多个更新包
在OTA场景中，可能需要合并多个更新包的分区：
- 解包两个版本的
super.img - 选择性替换需要更新的分区
- 重新打包为新的
super.img
6.3 开发调试技巧
对于系统开发者，可以：
- 快速验证分区大小调整的影响
- 测试不同的文件系统组合
- 调试init阶段的挂载问题
# 在模拟器上测试自定义super.img emulator -partition-size 4096 -superimage custom_super.img7. 底层原理深入
要真正掌握动态分区，需要理解其底层实现机制。
7.1 元数据结构
super.img的元数据使用protobuf格式存储，主要包含：
- 分区列表（名称、大小、属性）
- 组定义（名称、最大大小、分区列表）
- 区块分配信息
- 校验和数据
7.2 设备映射器交互
启动时，init进程会：
- 读取
super分区的元数据 - 验证元数据的完整性和有效性
- 通过
device-mapper创建设备节点 - 为每个逻辑分区建立映射关系
这个过程可以在first_stage_mount的日志中观察到。
7.3 与dm-verity的集成
动态分区与Android的验证启动（AVB）紧密集成：
vbmeta包含vbmeta_system的描述符vbmeta_system包含super分区中各子分区的描述符- 每个子分区可以独立进行hashtree验证
这种分层验证机制既保持了安全性，又提供了灵活性。