1. 这不是“解个包”那么简单：system.img背后的真实战场
你搜“system.img 解包”，页面上跳出来的大多是三行命令加一句“搞定”。但我在一线做Android固件定制、系统级应用预装、安全加固和ROM适配这十多年，亲手拆过上千个system.img——从高通800系列到联发科天玑，从Android 5.1到14，真正卡住人的从来不是那几条adb命令，而是解包后打开目录那一瞬间的窒息感：为什么/system/app里一堆空文件夹？为什么/system/priv-app里某个APK解压后classes.dex是0字节？为什么改完权限再打包，刷机直接变砖？这些不是操作失误，而是你没看懂system.img本身在说什么。
system.img不是普通压缩包，它是Android系统根分区的完整镜像，承载着整个OS的启动逻辑、服务调度、权限策略与SELinux上下文。它的结构、挂载方式、校验机制、签名依赖，全部深度耦合在Linux内核启动流程中。所谓“解包打包”，本质是在不破坏镜像完整性、不触发内核校验失败、不污染SELinux策略的前提下，对只读根文件系统进行外科手术式干预。关键词“权限管理”绝非指chmod 755这种表面操作——它直指Android的三重权限体系：传统Unix权限（user/group/other）、Android运行时权限（runtime permission）、以及最底层也最容易被忽略的SELinux标签（security context）。这三个层级一旦错位，轻则App崩溃，重则bootloop。
这篇文章面向三类人：一是刚接触AOSP编译的新手，想搞懂自己build出来的system.img怎么改；二是企业级定制工程师，需要为金融、政务类App预置并固化权限；三是安全研究员，要分析厂商预装软件的提权路径。我不讲“先装工具再执行命令”的流水账，而是带你一层层剥开system.img的皮、肉、骨、髓——从ext4文件系统布局开始，到sparse格式的压缩逻辑，再到Android 10+引入的dm-verity签名验证链，最后落到如何用setfattr精准修改文件属性而不触发recovery自动修复。所有步骤都基于实测环境（Ubuntu 22.04 + AOSP 13源码树 + Pixel 4a真机），参数值、错误日志、修复路径全部来自我踩过的坑。如果你只想复制粘贴命令，这篇不适合你；但如果你曾因一个selinux标签写错导致连续刷机失败七次，那你该继续往下看了。
2. 理解system.img：它到底是什么，又为什么这么难动
2.1 镜像类型辨析：sparse、ext4、erofs，选错一步全盘皆输
很多人以为system.img就是个ext4格式的磁盘镜像，直接用sudo mount -t ext4 -o loop system.img /mnt就能挂载。实测结果？90%概率报错“wrong fs type, bad option, bad superblock”。原因很简单：现代Android（8.0+）默认使用sparse格式封装ext4镜像，而非裸ext4。sparse（稀疏）格式是Google为节省OTA升级包体积设计的压缩封装层，它把镜像中连续的零字节块替换成元数据描述，物理文件大小远小于逻辑容量。比如一个4GB逻辑空间的system分区，sparse镜像可能只有1.2GB。
验证方法极其简单：
file system.img # 输出示例：system.img: Android sparse image, version: 1.0, file size: 1234567890, block size: 4096, total blocks: 1048576, total chunks: 2345如果看到“Android sparse image”，就必须先解sparse再处理。强行挂载会因superblock位置偏移而失败。解sparse的命令是：
simg2img system.img system.ext4注意：simg2img是Android build工具链自带的，路径通常在out/host/linux-x86/bin/simg2img（AOSP编译后）或/usr/lib/android-sdk/platform-tools/simg2img（Ubuntu apt安装的sdk）。别用网上随便找的Python脚本替代，它们对Android 12+新增的chunk类型（如RUN_LENGTH）支持不全，解出来的ext4镜像会损坏。
而Android 12起，部分厂商（三星、小米）开始转向erofs（Enhanced ROM File System）——一种只读、高压缩、支持透明解压的文件系统。它的镜像无法用simg2img转换，必须用专用工具：
# 先确认是否erofs file system.img # 若显示"erofs filesystem"则走此路 # 解包需内核模块支持（5.10+）或用户态工具 sudo modprobe erofs sudo mount -t erofs -o ro,loop system.img /mnt/system但更稳妥的做法是用erofs-utils中的unzip_erofs：
git clone https://github.com/hjl-tools/erofs-utils.git cd erofs-utils && make && sudo make install unzip_erofs -x system.img /tmp/system-extracted提示：不要试图用
mkfs.erofs重新打包。Android Bootloader对erofs镜像有特定magic number和checksum要求，官方未开源生成规范，强行打包大概率无法启动。生产环境务必使用AOSP原生mke2fs或make_ext4fs。
2.2 文件系统结构：/system不是普通目录，它是启动链的基石
解包后的/system目录结构，远比ls -l /system看到的复杂。关键点在于三个隐藏层：
第一层：挂载选项（mount options）
/system分区在fstab中定义为ro,barrier=1,inode64,errors=panic。其中ro（只读）是核心——任何写入操作都会被内核拦截。inode64表示使用64位inode编号，避免大容量分区inode耗尽；errors=panic意味着文件系统错误直接触发kernel panic，而非静默降级。这意味着你在解包镜像里修改文件，必须确保所有inode引用一致，否则挂载时校验失败。
第二层：Android专属目录与符号链接/system/app和/system/priv-app看似平级，实则权限天壤之别：
/system/app：普通系统App，运行在system_appSELinux域，无权访问/data/system等敏感路径；/system/priv-app：特权App，运行在platform_app域，可申请android.permission.INTERACT_ACROSS_USERS等高危权限；/system/framework：存放framework.jar等核心库，其classes.dex被Zygote进程预加载，修改后必须更新/system/etc/permissions/下的对应XML声明，否则ClassLoader找不到类。
更隐蔽的是符号链接：/system/bin/toolbox实际指向/system/xbin/toolbox，而/system/xbin又常是/system/bin的硬链接。解包时若用cp -r而非cp -a（保留链接），会导致二进制文件重复占用空间，打包后镜像超出分区限制。
第三层：SELinux上下文（security context）
这是权限管理真正的“心脏”。每个文件都有u:object_r:system_file:s0这样的标签，其中：
u：user（SELinux user，非Linux user）object_r：role（object role，固定为object_r）system_file：type（类型，决定该文件能被哪些进程访问）s0：level（MLS level，多级安全，Android中通常为s0）
例如/system/bin/sh的标签是u:object_r:shell_exec:s0，而/system/bin/su（若存在）必须是u:object_r:su_exec:s0，否则init进程启动shell时因类型不匹配被拒绝。这个标签不存储在文件inode里，而是存放在ext4的xattr（扩展属性）中，ls -Z才能看到。解包时若用普通tar命令（不带--xattrs），所有SELinux标签将丢失，打包后系统无法启动。
2.3 权限管理的三重门：Unix、Android、SELinux，缺一不可
很多工程师只改chmod 755就以为权限到位了，结果App仍报Permission denied。真相是：Android权限检查是三级串联闸门，任一关卡失败即拦截。
第一关：Unix基础权限（POSIX）
对应ls -l输出的-rwxr-xr-x。这是最底层，由VFS（Virtual File System）在open()系统调用时检查。例如/system/bin/logcat必须是-rwxr-xr-x，否则非root进程无法执行。但仅此不够——即使权限正确，第二关仍可能拦下。
第二关：Android运行时权限（Runtime Permission）
针对/data/data/com.xxx/等用户数据目录。即使/data/data/com.bankapp/的owner是u0_a123，且权限为drwx------，BankApp仍需在Manifest中声明<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>，并在运行时调用requestPermissions()。这一层与system.img无关，但影响你预置App的行为逻辑。
第三关：SELinux强制访问控制（MAC）
这才是system.img权限管理的核心战场。它独立于Unix权限，由内核LSM（Linux Security Module）模块执行。规则定义在/system/etc/selinux/plat_sepolicy.cil（Android 8+）或/sepolicy（旧版）中。例如：
# 允许zygote域读取system_file类型 allow zygote system_file:dir { open_dir read getattr }; allow zygote system_file:file { open read getattr ioctl };当你向/system/app/BankApp/BankApp.apk添加新功能时，若该APK需要访问/dev/block/mmcblk0p1，就必须在policy中添加：
allow platform_app block_device:blk_file { open read write };否则logcat会显示avc: denied { open } for pid=1234 comm="BankApp" path="/dev/block/mmcblk0p1" dev="tmpfs" ino=12345 scontext=u:r:platform_app:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0。这个错误不会出现在dmesg里，只在adb logcat -b avc中可见。
注意：Android 10起启用
enforce模式（非permissive），AVC denial直接导致进程被kill。调试阶段可临时设为permissive：adb shell setenforce 0，但生产镜像必须解决根本策略问题。
3. 解包与打包全流程：每一步背后的原理与陷阱
3.1 解包：从sparse到可编辑目录的四步法
步骤1：确认镜像格式与参数
# 获取镜像基本信息（关键！） simg2img -h system.img 2>&1 | grep -E "(size|blocks|chunk)" # 输出示例：Logical size: 4294967296 bytes (4.0G), Blocks: 1048576, Chunk size: 4096记录Logical size（逻辑大小），后续打包必须严格匹配，否则刷机时recovery校验失败。同时检查Block size（通常是4096），它决定文件系统块对齐。
步骤2：解sparse为ext4镜像
# 使用AOSP原生工具（强烈推荐） out/host/linux-x86/bin/simg2img system.img system.ext4 # 验证解包完整性 e2fsck -f system.ext4 # 必须返回"0 errors"若e2fsck报错Group descriptors look bad，说明simg2img版本不匹配（如用Android 10工具解Android 13镜像），需切换至对应AOSP分支的工具。
步骤3：挂载ext4镜像为可读写目录
# 创建挂载点 sudo mkdir -p /mnt/system-src # 关键：使用-o nouuid禁用UUID检查（避免与原设备冲突） sudo mount -t ext4 -o rw,relatime,nouuid,errors=remount-ro system.ext4 /mnt/system-src # 检查挂载效果 ls -lZ /mnt/system-src | head -5 # 确认能看到SELinux标签nouuid选项至关重要。ext4镜像包含UUID，若宿主机已有同UUID分区（如另一台设备的system.img），内核会拒绝挂载。nouuid绕过此检查。
步骤4：提取完整目录结构（保留所有元数据）
# 使用rsync而非cp，确保硬链接、xattr、ACL全量保留 sudo rsync -aHAX --numeric-ids /mnt/system-src/ /home/user/system-modified/ # 参数详解： # -a: 归档模式（递归+权限+时间戳） # -H: 保留硬链接 # -A: 保留ACL（Access Control List） # -X: 保留扩展属性（含SELinux标签） # --numeric-ids: 避免UID/GID映射错误（宿主机用户与镜像内用户ID不同）此时/home/user/system-modified/才是真正的“可编辑副本”。直接编辑挂载点/mnt/system-src风险极高——若编辑中途断电，镜像损坏无法恢复。
3.2 修改：权限管理实战的五个关键操作
操作1：修改文件Unix权限（chmod/chown）
场景：为预置的/system/app/CustomLauncher/CustomLauncher.apk添加执行权限（虽APK无需执行，但某些启动器需chmod +x才能被PackageManager识别）。
# 进入解包目录 cd /home/user/system-modified # 修改APK权限（注意：APK文件本身应为644，目录为755） sudo chmod 644 system/app/CustomLauncher/CustomLauncher.apk sudo chmod 755 system/app/CustomLauncher # 修改属主（必须匹配Android UID） sudo chown root:root system/app/CustomLauncher/CustomLauncher.apk警告：
chown必须用root:root。Android系统文件属主UID必须为0（root），GID为0（root）或2000（shell）。若设为1000:1000（普通用户），init进程启动时因UID不匹配拒绝加载。
操作2：设置SELinux标签（setfattr）
场景：为新增的/system/bin/custom_tool二进制文件设置正确标签。
# 查看当前标签（应为default_type） ls -Z system/bin/custom_tool # 设置为shell_exec类型（允许shell执行） sudo setfattr -n security.selinux -v u:object_r:shell_exec:s0 system/bin/custom_tool # 验证 ls -Z system/bin/custom_tool # 应输出 u:object_r:shell_exec:s0setfattr命令必须指定完整security.selinux属性名，不能简写。u:object_r:shell_exec:s0是标准标签，其他常见标签：
system_file: 普通系统文件（如.so库）system_file: 框架JAR包（/system/framework/*.jar）apk_file: APK文件（/system/app/*.apk）dalvikcache_file: Dex缓存（/system/app/*/oat/*）
操作3：更新SELinux策略（cil文件）
场景：CustomLauncher需读取/proc/cpuinfo获取CPU信息。
# 在AOSP源码中定位策略文件 # 通常位于 device/manufacturer/common/sepolicy/vendor/ 或 system/sepolicy/private/ # 添加规则（以plat_private.cil为例）： # allow platform_app proc_cpuinfo:file { open read getattr }; # 编译策略：m sepolicy # 生成的policy文件位于 out/target/product/device/obj/ETC/plat_policy.cil_intermediates/plat_policy.cil # 将其复制到解包目录的对应位置 cp out/target/product/device/obj/ETC/plat_policy.cil_intermediates/plat_policy.cil \ /home/user/system-modified/system/etc/selinux/plat_sepolicy.cil实操心得：策略文件必须用
cil格式（Android 8+），旧版te（type enforcement）文件已废弃。直接编辑plat_sepolicy.cil风险高，建议在AOSP源码中修改后重新编译，确保语法正确性（checkpolicy工具会校验）。
操作4：修复文件系统超级块（e2fsck）
场景：修改大量文件后，ext4元数据可能不一致。
# 卸载前必须执行 sudo umount /mnt/system-src # 强制检查并修复（-y自动确认） sudo e2fsck -f -y system.ext4 # 重新挂载验证 sudo mount -t ext4 -o ro,nouuid system.ext4 /mnt/system-src sudo ls /mnt/system-src | wc -l # 应正常输出文件数e2fsck -f强制检查，-y自动修复。若提示Resize inode not valid，说明文件系统版本不兼容（如用Android 11工具处理Android 14镜像），需降级工具链。
操作5：计算并写入dm-verity签名（Android 10+必需）
场景：Target Build为userdebug或user版本，启用dm-verity校验。
# 生成verity签名（需AOSP build环境） source build/envsetup.sh lunch aosp_arm64-userdebug # 生成verity key（首次） make generate_verity_key # 对system.ext4生成哈希树并签名 system/tools/make_ext4fs -s -T $(date +%s) -S build/target/product/security/mac_permissions.xml \ -C out/target/product/device/root/default.prop \ -l 4294967296 -a 4096 -L system system_new.img /home/user/system-modified # 此命令自动嵌入verity元数据手动实现需veritysetup工具，但Android官方不支持，强烈建议用AOSP原生make_ext4fs。参数-l 4294967296必须等于原始镜像Logical size，否则recovery校验失败。
3.3 打包：从目录到可刷机镜像的终极校验
步骤1：生成ext4镜像（make_ext4fs是唯一可靠方案）
# 使用AOSP原生工具（路径：out/host/linux-x86/bin/make_ext4fs） out/host/linux-x86/bin/make_ext4fs \ -s \ # 启用sparse格式 -T $(date +%s) \ # 时间戳（影响构建指纹） -S build/target/product/security/mac_permissions.xml \ # SELinux策略 -C out/target/product/device/root/default.prop \ # 构建属性 -l 4294967296 \ # 逻辑大小（必须精确！） -a system \ # 挂载点名称（影响fstab解析） -L system \ # 卷标（影响mount识别） system_new.img \ # 输出文件 /home/user/system-modified # 输入目录-s参数生成sparse镜像；-T时间戳影响OTA增量包生成；-S和-C确保SELinux和属性正确注入。-l值若偏差哪怕1字节，刷机时recovery会报verify failed。
步骤2：校验镜像完整性
# 检查sparse头 simg2img -h system_new.img # 检查ext4结构 sudo losetup -fP system_new.img # 创建loop设备 sudo e2fsck -f /dev/loop0p1 # 检查分区 sudo losetup -d /dev/loop0 # 检查文件数量一致性 # 原镜像解包后文件数 vs 新镜像解包后文件数 diff <(find /home/user/system-original -type f | wc -l) <(find /home/user/system-modified -type f | wc -l)步骤3：刷机前最终验证（真机测试）
# 推送至设备（需adb root） adb root adb remount adb push system_new.img /sdcard/ # 在设备端校验（需root shell） adb shell "cd /sdcard && sha256sum system_new.img" # 与PC端sha256对比 sha256sum system_new.img # 若一致，进入fastboot刷入 adb reboot bootloader fastboot flash system system_new.img fastboot reboot实操心得：刷机后首次启动必现
Starting Android...动画超时（约2分钟），因system分区首次挂载需重建dex缓存。若3分钟后黑屏，立即adb logcat -b all > boot.log抓日志，重点查avc denied和init: Failed to mount。
4. 权限管理深度实战：三个真实案例拆解
4.1 案例1：为银行App预置root权限通道（合规前提下）
某政务终端需预装银行App，并允许其调用底层硬件加密模块（/dev/tpm0）。直接给su权限违反安全规范，正确做法是创建最小特权通道。
问题分析：
/dev/tpm0SELinux标签为u:object_r:tpm_device:s0- BankApp运行在
u:r:platform_app:s0域 - 默认策略禁止
platform_app访问tpm_device
解决方案：
- 在
device/xxx/sepolicy/vendor/private/tpm.te中添加：# 允许bankapp域访问tpm allow bankapp tpm_device:chr_file { open read write ioctl }; # 创建bankapp域（继承platform_app） type bankapp, domain; typeattribute bankapp mlstrustedsubject; permissive bankapp; - 修改BankApp的
AndroidManifest.xml，声明android:sharedUserId="android.uid.system"，使其运行在system UID - 在
/system/etc/selinux/plat_sepolicy.cil中添加：(type bankapp) (allow bankapp tpm_device (chr_file (open read write ioctl)))
打包后验证：
adb shell "ls -Z /dev/tpm0" # u:object_r:tpm_device:s0 adb shell "ps -Z | grep bankapp" # u:r:bankapp:s0 adb logcat | grep avc # 无denied日志4.2 案例2：修复因SELinux标签丢失导致的SystemUI崩溃
现象：修改/system/priv-app/SystemUI/SystemUI.apk后，状态栏消失，logcat报java.lang.SecurityException: Permission denial。
根因追溯：
- 解包时用了
cp -r而非rsync -aHAX，丢失security.selinuxxattr SystemUI.apk标签应为u:object_r:apk_file:s0，现为u:object_r:default_type:s0- PackageManager拒绝加载default_type的APK
修复步骤：
- 进入解包目录：
cd /home/user/system-modified - 重置标签：
sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 system/priv-app/SystemUI/SystemUI.apk sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 system/priv-app/SystemUI/oat/arm64/SystemUI.odex - 修复目录标签：
sudo setfattr -n security.selinux -v u:object_r:apk_dir_file:s0 system/priv-app/SystemUI - 重新打包并刷机
注意：
apk_dir_file是目录类型，apk_file是文件类型，二者不可混用。odex文件必须单独设置标签。
4.3 案例3：Android 12+ erofs镜像的权限注入
某高通平台设备使用erofs，system.img无法用simg2img解包。需在构建阶段注入权限。
可行路径：
- 在AOSP
build/core/Makefile中定位erofs生成逻辑 - 修改
$(EROFSTOOLS)/mkfs.erofs调用参数：$(EROFSTOOLS)/mkfs.erofs \ -z lz4 \ -T $(TIMESTAMP) \ --uuid $(UUID) \ --compression-level 12 \ --xattrs-user \ $(TARGET_OUT)/system_new.erofs \ $(TARGET_OUT)/system--xattrs-user确保保留所有扩展属性 - 在
system/core/include/private/android_filesystem_config.h中为CustomTool添加UID/GID映射：{ 00755, AID_ROOT, AID_SHELL, "system/bin/custom_tool" }, - 编译生成
system_new.erofs，替换原镜像
验证命令：
# 在设备上检查 adb shell "ls -Z /system/bin/custom_tool" # u:object_r:shell_exec:s0 adb shell "getprop ro.build.type" # 必须为"user"或"userdebug"5. 常见问题与排查技巧实录：那些文档里不会写的坑
5.1 问题速查表：高频故障与精准定位
| 现象 | 可能原因 | 排查命令 | 解决方案 |
|---|---|---|---|
fastboot flash system xxx.img后设备无限重启 | dm-verity校验失败 | adb logcat -b kernel | grep verity | 重新打包，确保-l参数与原始镜像逻辑大小一致 |
adb shell进入后ls /system为空 | sparse解包失败或挂载选项错误 | file system.img确认格式；mount | grep system检查挂载点 | 用AOSP simg2img；挂载加-o nouuid,ro |
修改/system/bin/sh后adb shell报Permission denied | Unix权限错误或SELinux标签丢失 | ls -lZ /system/bin/sh | chmod 755+setfattr -n security.selinux -v u:object_r:shell_exec:s0 |
| 预置App安装后立即崩溃 | SELinux策略缺失或APK标签错误 | adb logcat -b avc | grep denied | 根据avc日志添加allow规则，重置APK标签为apk_file |
make_ext4fs报Failed to allocate block | 输入目录过大超出-l指定大小 | du -sh /home/user/system-modified | 增大-l参数值，或清理/system/app/*/oat缓存 |
5.2 独家避坑技巧：十年踩坑总结
技巧1：永远用adb logcat -b avc代替dmesg查SELinux问题dmesg只显示内核级AVC，而Android的avc日志在logcat的avc缓冲区中。adb logcat -b avc能捕获所有denial事件，包括Zygote、system_server等Java层进程的访问拒绝。-b all会淹没关键信息，必须指定-b avc。
技巧2：setfattr批量操作的高效写法
手动为每个文件设标签效率极低。用find结合xargs：
# 为所有APK设标签 find /home/user/system-modified -name "*.apk" -exec sudo setfattr -n security.selinux -v u:object_r:apk_file:s0 {} \; # 为所有so库设标签 find /home/user/system-modified -name "*.so" -exec sudo setfattr -n security.selinux -v u:object_r:system_file:s0 {} \;技巧3：备份原始镜像的SHA256是救命稻草
每次操作前执行：
sha256sum system.img > system.img.sha256若打包失败，可用dd if=/dev/zero of=system.img bs=1M count=4096快速生成占位镜像，再用sha256sum -c system.img.sha256验证原始镜像完整性，避免误删。
技巧4：e2fsck修复后必须resize2fs调整大小e2fsck -f -y可能改变文件系统内部结构，导致逻辑大小与物理大小不匹配。修复后执行：
sudo resize2fs -f system.ext4-f强制调整，确保superblock中记录的块数与实际一致。
技巧5：Android 14的system_other分区陷阱
Android 14引入system_other分区存放/system_ext等扩展内容。若你的修改涉及/system_ext/priv-app，必须同步处理system_other.img，否则PackageManager找不到组件。解包命令变为：
simg2img system_other.img system_other.ext4 sudo mount -t ext4 -o rw,nouuid system_other.ext4 /mnt/system-other5.3 真实故障复盘：一次因umask导致的权限灾难
去年为某车企定制ROM，预置导航App后反复崩溃。日志显示open("/system/app/NavApp/lib/arm64/libnav.so") failed: Permission denied。检查发现libnav.so权限为-rw-r--r--（644），而/system/app/NavApp/目录为drwxr-xr-x（755）。按理说644足够读取。
深入排查：
adb shell "ls -Z /system/app/NavApp/lib/arm64/libnav.so" # 输出：u:object_r:system_file:s0 adb shell "ls -Z /system/app/NavApp/" # 输出：u:object_r:apk_dir_file:s0问题在于：libnav.so应属于apk_file类型，而非system_file。但为何标签错了？追溯构建过程，发现make_ext4fs命令漏了-S参数，未注入SELinux策略，导致所有文件默认为default_type，后被restorecon误设为system_file。
教训：make_ext4fs的-S参数不是可选，而是必需。没有它，整个SELinux体系崩塌。现在我的打包脚本强制校验：
if ! grep -q "security.selinux" system_new.img; then echo "ERROR: SELinux labels missing! Abort." exit 1 fi6. 工具链与环境配置：一套经受千次刷机考验的方案
6.1 推荐环境：Ubuntu 22.04 LTS + AOSP 13源码树
为什么不是Windows或macOS？
- Windows Subsystem for Linux（WSL）对loop设备支持不完善，
mount -o loop常失败 - macOS的HFS+文件系统不支持Linux扩展属性（xattr），
setfattr无效 - Ubuntu 22.04内核5.15+原生支持erofs，且
e2fsprogs版本（1.46.5）完美兼容Android 13 ext4
必备工具清单（全部apt安装）：
sudo apt update sudo apt install -y \ android-tools-adb \ android-tools-fastboot \ e2fsprogs \ libsepol-dev \ libselinux1-dev \ python3-pip \ git \ curl \ unzip \ zip # 安装erofs-utils（GitHub源） git clone https://github.com/hjl-tools/erofs-utils.git cd erofs-utils && make && sudo make install6.2 AOSP工具链编译指南（避免版本错配）
关键原则：工具链版本必须与目标Android版本一致
- Android 11：用
android-11.0.0_r49分支编译 - Android 13：用
android-13.0.0_r23分支
编译步骤：
repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r23 repo sync -c -j8 --no-clone-bundle source build/envsetup.sh lunch aosp_arm64-userdebug # 编译host工具（只需此步，无需全编译） m -j8 simg2img make_ext4fs # 工具位于 out/host/linux-x86/bin/6.3 自动化脚本模板：安全打包的最后防线
以下脚本整合了所有关键校验，每天在我团队CI中运行：
#!/bin/bash # safe-pack-system.sh set -e # 任何命令失败即退出 SYSTEM_DIR="/home/user/system-modified" ORIGINAL_IMG="system.img" NEW_IMG="system_new.img" echo "=== Step 1: Validate original image ===" [ -f "$ORIGINAL_IMG" ] || { echo "Original image missing"; exit 1; } LOGICAL_SIZE=$(simg2img -h "$ORIGINAL_IMG" 2>&1 | grep "Logical size" | awk '{print $3}' | tr -d 'bytes()') echo "Logical size: $LOGICAL_SIZE" echo "=== Step 2: Generate ext4 ===" out/host/linux-x86/bin/make_ext4
