简介：SYSTEM.IMG解包打包工具是一款面向安卓ROM开发者与高级用户的镜像处理软件，适用于Windows环境下对系统镜像进行解包、编辑与重新打包，可完成系统应用和服务的新增、删除、权限调整与性能优化，也能用于修复部分系统故障。资源包为zip格式，共245个文件，约78.72MB，其中以159个xml配置文件、27个exe可执行程序、25个dll动态库为主，辅以sh脚本、jar组件及安卓刷机相关工具，构成完整工具链。版本标记为crb_v221b，内置DEX转换等辅助组件，可帮助用户精简ROM、修复启动问题或深度定制系统，也适合教学环境下演示安卓系统文件结构与定制流程。已有525人学习下载，操作前需注意备份原始镜像，按解包、修改、重打包、验证的流程使用即可。包内含完整可执行程序与动态库，便于直接运行和二次开发。
1. 从刷机包里抠出 SYSTEM.IMG：不只是解压那么简单
很多做 ROM 定制、系统精简或移植的开发者，第一个绕不过去的坎就是 system.img。它不像普通 zip 压缩包，拖出来就能改，它是 ext4 文件系统镜像，里面是 Android 系统的核心分区，包含 framework、app、priv-app 这些目录。直接解压会报错，硬改会变砖，甚至用错了工具连打包都过不了校验。这套 SYSTEM.IMG 解包、打包工具资源，解决的就是这条完整链路：把 sparse 镜像转成 raw，挂载或提取内容，修改后重新打包成可刷入的镜像格式。适合 ROM 爱好者、系统定制开发者和需要批量预装或精简系统应用的工程师。对新手来说，它是能直接照做的完整操作流程；对熟手来说，重点在于上下文标签、文件属性和打包参数的还原，这几处最容易翻车。
2. 镜像格式与工具选型：先搞懂 sparse、raw 和文件系统的关系
2.1 为什么不能直接解压 system.img：sparse 与 raw 两种格式的本质区别
从刷机包解出来的 system.img，通常不是 ext4 文件系统的原始镜像，而是 sparse image。sparse 格式的设计目标很朴素：Android 系统分区里存在大量空洞块，全量写入会浪费存储空间和刷机时间，sparse 通过记录数据块和空洞块的分布来压缩镜像体积。
具体来说，sparse 镜像头部有 56 字节的 sparse header，包含 magic 值 0xED26FF3A、总块数、块大小等字段，每个块描述符记录该块在目标分区中的逻辑偏移。普通解压工具识别不了这种结构，直接解压得到的是格式错误的文件，挂载时系统会直接报超级块错误。
raw image 则是逐块映射的真实文件系统镜像，可以直接通过 loop 设备挂载。常见的转换链路是：sparse -> raw 用 simg2img，raw -> sparse 用 img2simg。这套资源里集成了这两个工具的编译版本，Windows 和 Linux 下都可用，省去自己编译的麻烦。
2.2 工具链清单：simg2img、make_ext4fs、mount 和文件系统检查工具
工具选型直接决定流程能不能走通。核心工具链包括以下几类：
| 工具 | 用途 | 关键参数 |
|---|---|---|
| simg2img | 将 sparse 镜像转换为 raw 镜像 | 输入文件、输出文件 |
| make_ext4fs | 从目录构建 ext4 镜像 | -l 指定分区大小，-L 设置卷标，-T 设置时间戳 |
| mount | 挂载 raw 镜像到宿主机目录 | -o loop, ro 或 rw |
| e2fsck | 检查并修复 ext4 文件系统一致性 | -f 强制执行检查，-y 自动应答修复 |
| img2simg | 将 raw 镜像转换回 sparse 格式 | 输入文件、输出文件、块大小 |
Linux 环境直接通过 apt 安装 e2fsprogs 和 android-tools-adb 即可获得大部分工具。Windows 环境下，资源包内的二进制文件是预编译的，建议放到没有空格的路径下，比如 C:\system_tools\，避免命令行解析出错。
2.3 环境准备：从零搭好解包环境
先确认环境依赖。Linux 下执行以下步骤：
# 安装必要工具 sudo apt update && sudo apt install -y e2fsprogs android-tools-adb unzip # 验证 simg2img 是否可用 simg2img -h逻辑说明：simg2img 是转换链路的第一步，先确认它可用，避免后续脚本执行到一半才发现工具缺失。参数说明：-h 打印帮助信息，如果能正常输出用法说明，证明基础工具链已经就位。
Windows 用户需要把资源包解压到固定目录，并将该目录加入 PATH 环境变量。配置完成后，在 cmd 中执行 simg2img -h 验证。常见做法是写成环境变量后重新打开终端，否则命令无法识别。
3. 完整解包流程：从刷机包到可编辑目录的四步操作法
3.1 第一步：从刷机包中提取 system.img
不同刷机包的解压逻辑不同。zip 格式的直接解压，dat 格式的需要用专门的转换工具。这里以最常见的 zip 包为例：
# 解压刷机包 unzip firmware.zip system.img如果刷机包内 system.img 是稀疏格式，会看到文件体积远小于分区大小，这是正常现象。注意不要这个时候直接去挂载它，必须先做格式转换。
3.2 第二步：sparse 转 raw 并挂载镜像
这一步是整个流程的核心转换环节：
# 查看镜像格式 file system.img # sparse 转 raw simg2img system.img system_raw.img # 挂载 raw 镜像 sudo mkdir -p /mnt/system_extract sudo mount -o loop system_raw.img /mnt/system_extractfile 命令会显示 "Android sparse image" 字样，确认格式后才能继续。mount 命令的 -o loop 参数让系统自动分配 loop 设备，数据流向是镜像文件 -> loop 设备 -> 挂载点。
如果分区文件系统是只读状态，mount 报错时检查 dmesg 输出，常见原因是镜像损坏或格式不对。另外注意挂载点必须是一个空的目录，否则会掩盖原有内容。
3.3 第三步：目录级提取与文件操作
挂载成功后，可以像普通目录一样浏览、拷贝文件：
# 查看目录结构 ls /mnt/system_extract/app /mnt/system_extract/framework # 提取整个镜像内容 sudo cp -a /mnt/system_extract ./system_extracted # 修改后取消挂载 sudo umount /mnt/system_extract拷贝时用 cp -a 保留文件权限、所有者、时间戳和 SELinux 上下文。这一步容易被忽略，如果直接 cp -r 或拖拽拷贝，后续打包出的镜像在设备上会出权限问题。
3.4 第四步：修改内容的常见场景
拿到提取后的目录，常见的定制操作包括：
预装应用：把 APK 放入 system/app 或 system/priv-app，其中 priv-app 下的应用拥有系统权限。 精简系统：删除不需要的系统应用，但要留意依赖关系。比如删掉某个输入法前，先确认没有其他应用调用它。 替换 framework 资源：修改 framework-res.apk 后放回原目录，注意签名保持一致。
4. 打包镜像的完整闭环：从目录回写到可刷入 image
4.1 为什么打包不能直接用 mkfs.ext4：文件上下文和权限的问题
直接对修改后的目录执行 mkfs.ext4 生成的镜像，刷入设备后大概率出现两种问题：应用闪退或直接不开机。核心原因是镜像中的文件缺少正确的 SELinux 上下文标签和 Android 特有的文件属性。
make_ext4fs 在打包时通过 -S 参数指定 file_contexts 文件，来恢复每个文件的安全上下文。这个文件可以从原始镜像中提取，通常位于设备的 /etc/selinux/ 目录或刷机包的 vendor 分区中。没有这套映射，即使镜像格式正确，系统也无法正常访问文件。
4.2 使用 make_ext4fs 构建系统镜像
# 打包 ext4 镜像，关键参数对齐分区大小 make_ext4fs -s -l 2147483648 -L system \ -S file_contexts \ -T 1600000000 \ system_new.img ./system_extracted-s 参数表示生成 sparse 格式镜像，直接输出可刷入的格式。逻辑说明：-l 指定分区大小（以字节为单位），必须大于等于原始分区大小，否则打包过程会报空间不足。这个数值可以从原始镜像的属性中获取。参数说明：-L 设置卷标，通常为 system；-S 指定 file_contexts 路径，用于恢复 SELinux 标签；-T 设置时间戳，目的是保证镜像内文件时间一致，避免增量 OTA 时因时间戳不一致导致校验失败。
4.3 打包后验证镜像完整性
镜像打包完成不代表能直接刷入，先做本地验证：
# 检查镜像文件系统是否一致 e2fsck -f -y system_new.img # 重新挂载检查关键目录 mkdir -p /mnt/system_check && sudo mount -o loop system_new.img /mnt/system_check ls /mnt/system_check/app4.4 恢复 sparse 格式的必要性
部分设备要求刷入 raw 格式也可以，但为了兼容性，统一回到 sparse 格式。如果打包时漏了 -s 参数，可以用 img2simg 转换补救：
# raw 转 sparse img2simg system_new_raw.img system_new_sparse.img 4096第三个参数是块大小（单位字节），默认 4096。这个值与设备分区对齐有关，用 4096 通常不会错。
5. 避坑与排查：解包打包中四个高频翻车现场
5.1 挂载时报错：wrong fs type, bad option, bad superblock
现象：mount 命令直接报错，提示 bad superblock 或无法识别文件系统。 原因：镜像没有经过 simg2img 转换，系统把 sparse 格式当成 ext4 解析，超级块自然找不到。 解决：先用 file 命令验证镜像格式，如果是 "Android sparse image"，执行 simg2img 后再挂载。这条排查路径几乎覆盖 90% 的挂载失败场景。
5.2 打包时提示：No space left on device
现象：make_ext4fs 执行到一半报空间不足，无法生成镜像。 原因：-l 参数指定的分区大小小于目录总占用空间。尤其在精简系统时，删了文件但目录结构里还有残留文件。 解决：先统计目录占用空间：du -sb system_extracted，然后把 -l 参数设置为统计结果向上取整到最近的 4K 对齐值。
5.3 刷入设备后应用闪退或无法启动
现象：镜像成功刷入，但大量应用闪退，system_server 反复重启。 原因：打包时没有指定 -S 参数，所有文件的 SELinux 上下文都变成默认值，系统服务无法正确访问文件。另一种可能是 file_contexts 与镜像版本不匹配。 解决：从原始刷机包提取匹配版本的 file_contexts 文件，打包时必须显式传入。建议把 file_contexts 放在资源包固定位置，每次打包前检查其内容是否与目标系统版本一致。
5.4 镜像刷入后卡在第一屏或循环重启
现象：开机动画结束后一直重启，或停在 boot 动画。 原因：分区大小不匹配是最常见原因。打包时 -l 参数小于原分区大小，导致系统启动时读取到的分区结构异常。 解决：用原始镜像的完整属性确认分区大小。在解包前执行这个命令记录原始信息：
# 获取原始镜像信息 dump_image system | awk '{print $4}'记录下原始大小，打包时设置相同数值。如果设备支持动态分区，还需要检查 super 分区中的 metadata 信息，确保 system 分区大小未被修改。
6. 验证打包结果与后续定制技巧：从刷机到应用层排查
镜像刷入设备后，不能只看能开机就认为成功了，建议从三个层面做验证。
第一层是文件系统层。开机后用 adb 执行 mount 命令，确认 system 分区挂载在 /system（或 /system_root），文件系统是 ext4 且显示 rw 或 ro 状态与预期一致。进一步执行 df -h /system，对比分区大小与打包前设置是否匹配。这套验证能过滤掉 80% 的打包参数错误。
第二层是 SELinux 层。执行 adb shell dmesg | grep avc 查看是否有 denied 日志。如果出现大量 avc denied，说明 file_contexts 恢复得不够完整，需要回到打包步骤重新处理。补充一份正确的 file_contexts 后重打包，可以避免绝大多数权限类问题。
第三层是应用层。逐个打开预装的应用，确认不闪退且在设置中可见。最高效的频率是先做一次开机 + 基础操作冒烟测试，再做全量检查，避免耗时的完整回归。
这个打包流程我反复跑过多个项目之后，养成了一个固定习惯：每次打包前强制走一遍 e2fsck -f 检查源目录镜像的一致性，补上 -T 时间戳参数。这两步组合看起来简单，却能提前拦截大部分异常。从那以后我每次打包都强制走一遍这两步，再也没被奇怪的问题纠缠过。
希望这套 SYSTEM.IMG 解包打包工具资源，能帮你把系统定制这条路走得顺畅一些。
本文还有配套的精品资源，点击获取
