刷机包解包后如何正确修改system镜像？

Question

解包刷机包后，如何正确修改system.img并确保重新打包后能正常挂载启动？常见问题包括：使用错误的文件系统工具（如误用simg2img处理ext4镜像）、修改权限导致SEAndroid策略拒绝挂载、未更新校验值或签名致使刷机失败。此外，直接修改镜像内文件后未调整分区大小，或忽略ramdisk中对system的挂载参数，也会引发无法开机等问题。需掌握img解包、文件系统操作与重新签名流程。

Answer 1

一、理解刷机包结构与system.img基础

在Android系统定制中，刷机包（如fastboot或OTA包）通常包含多个分区镜像，其中system.img是核心系统分区，存储了操作系统的核心文件。该镜像可能采用sparse image格式（.img）封装ext4文件系统，也可能为raw ext4镜像。

• Sparse Image：压缩格式，节省空间，常见于厂商发布的刷机包。
• Raw Image：直接的ext4文件系统镜像，可直接挂载。

解包前需判断system.img类型，避免误用工具导致损坏。可通过file system.img命令识别：

$ file system.img
system.img: data  # 可能为sparse
# 或
system.img: Linux rev 1.0 ext4 filesystem data, UUID=... # 表示已为raw ext4

二、正确解包system.img：工具选择与流程

根据镜像类型选择合适的转换工具：

镜像类型	检测方法	转换工具	输出格式
Sparse Image	file 显示为 "data"	simg2img	转为 raw ext4 镜像
Raw ext4	file 包含 "ext4 filesystem"	无需转换	直接挂载

执行转换示例：

simg2img system.img system_raw.img

随后可使用loop设备挂载：

sudo mkdir /mnt/system
sudo mount -o loop system_raw.img /mnt/system

三、修改system分区内容与权限管理

在挂载后的目录中可进行文件增删改，但必须注意以下关键点：

1. 保留原始目录结构与符号链接。
2. 修改文件后需确保SELinux上下文正确，否则SEAndroid策略将拒绝访问。
3. 使用ls -Z查看原文件上下文，通过chcon或restorecon修复。

例如，添加一个可执行服务：

cp myservice /mnt/system/bin/
chmod 755 /mnt/system/bin/myservice
chcon u:object_r:system_file:s0 /mnt/system/bin/myservice

若不确定上下文，可参考file_contexts文件（位于ramdisk或vendor分区）定义规则。

四、文件系统完整性与容量规划

修改后需检查镜像是否超出原始分区大小：

du -sh /mnt/system
e2fsck -f system_raw.img
resize2fs -M system_raw.img  # 最小化空间占用

若扩容需求大，需同步修改partition-size参数（如在flash.sh或recovery脚本中），否则刷机时会报错“image too large”。

此外，某些设备要求镜像对齐块边界，建议使用：

resize2fs system_raw.img 2048M  # 明确指定大小

五、重新打包与格式转换

完成修改后卸载并转换回sparse格式（如原包为sparse）：

sudo umount /mnt/system
img2simg system_raw.img system_new.img

部分厂商要求校验和或签名验证，此时需替换原刷机包中的system.img，并处理如下问题。

六、签名与校验机制处理

现代Android设备启用AVB（Android Verified Boot），镜像包含哈希树和签名：

avbtool verify_image --image system_new.img

若校验失败，需重新签名：

avbtool add_hash_footer \
    --image system_new.img \
    --partition_size 2048M \
    --partition_name system \
    --key key.pem \
    --algorithm SHA256_RSA2048

对于无AVB但有OTA签名校验的包，需重新对整个zip包签名：

java -jar signapk.jar platform.x509.pem platform.pk8 unsigned.zip signed.zip

七、ramdisk挂载参数检查与调试

即使system.img正确，若ramdisk中init.rc或fstab配置错误，仍无法挂载。需检查：

/etc/fstab
/dev/block/platform/soc/.../by-name/SYSTEM /system ext4 ro,barrier=1 0 0

确认设备节点名、文件系统类型、挂载选项一致。特别注意：

• ro vs rw：系统分区应为只读。
• context=...：若启用SELinux，需保留安全上下文挂载参数。

八、完整流程图：从解包到刷机

graph TD
            A[获取刷机包] --> B{解析system.img类型}
            B -->|Sparse| C[simg2img 转换]
            B -->|Raw ext4| D[直接挂载]
            C --> E[挂载到/mnt/system]
            D --> E
            E --> F[修改文件与权限]
            F --> G[检查SELinux上下文]
            G --> H[卸载并resize2fs]
            H --> I{是否需sparse?}
            I -->|是| J[img2simg]
            I -->|否| K[保留raw]
            J --> L[AVB签名或OTA重签]
            K --> L
            L --> M[集成回刷机包]
            M --> N[烧录测试]

九、常见故障排查表

现象	可能原因	解决方案
开机卡logo	system未挂载	检查fstab、镜像大小、签名
提示“dm-verity corruption”	AVB校验失败	重新add_hash_footer
App崩溃或权限拒绝	SELinux上下文错误	使用audit2allow分析日志
刷机失败：“image too large”	超过partition-size	resize2fs或修改分区定义
无法写入system	挂载为ro	临时改为rw调试，正式版恢复ro

十、高级技巧与自动化建议

对于频繁定制场景，建议构建自动化脚本：

#!/bin/bash
# extract_system.sh
simg2img $1 system.raw
mkdir -p /tmp/system_mnt
mount -o loop system.raw /tmp/system_mnt
cp -a custom_files/* /tmp/system_mnt/
chcon -R u:object_r:system_file:s0 /tmp/system_mnt/custom_bin/
umount /tmp/system_mnt
resize2fs system.raw 2G
img2simg system.raw system_new.img

结合CI/CD流水线，集成签名服务与设备兼容性测试，提升发布效率与稳定性。