1. system.img为何要改先搞清楚这张系统盘的脾气玩Android的时间稍微长一点基本都会遇到这个需求自带应用删不掉、想加个开机脚本、想把某几个系统应用替换成自己改过的版本、或者单纯想把谷歌全家桶从国行固件里拔掉。这些操作的最终落点几乎都是那个又爱又恨的system.img。很多新手第一次接触system.img容易把它当成普通的镜像文件以为像解压zip一样双击就能打开。结果在Windows上试了半天发现7-Zip打不开、WinRAR也不认识于是开始怀疑文件是不是坏了。这不是你的问题是system.img的封装方式跟普通压缩包压根不在一个维度。先说清楚system.img到底是什么。它是Android系统分区system分区的完整磁盘镜像挂载到设备后的路径是/system里面装着Android运行的核心东西系统框架framework、预装应用/system/app、/system/priv-app、原生库/system/lib、/system/lib64、可执行文件/system/bin、系统配置/system/etc以及build.prop这个系统属性文件。可以说手机开机能跑起来全靠这个分区。它的脾气在于这个镜像不是普通的文件打包格式而是一个包含了文件系统结构的块设备镜像。我们看到的system.img本质上是把整个system分区按块block逐字节复刻出来的文件。所以要在电脑上修改它核心思路不是解压文件而是把文件系统挂载起来改完再固化回去。这篇文章讲的操作面向的场景是你手里有一个system.img可能是从ROM包解出来的也可能是从手机里备份出来的想在Windows或Linux电脑上打开它、往里面塞东西或者删东西、然后重新打包成可用的镜像。这个流程在定制ROM、系统精简、功能移植、学习Android系统结构时都会反复用到属于玩机基本功里比较硬核的一项。2. 识别镜像格式raw、sparse与erofs的分辨方法拿到一个system.img第一件事不是着急找工具而是先判断它是什么格式。格式判断错了后面全部白干。这一步花不了30秒但能帮你避开接下来一小时的无效操作。2.1 三种最常见的system.img格式raw ext4镜像这是最规矩的格式。整个镜像就是一份完整的ext4文件系统镜像文件系统头部superblock在镜像文件的最开头偏移量是0。这种镜像最老实mount命令直接就能挂载不需要任何转换。Google官方的出厂镜像Factory Image里如果解出来是system.img很多就是raw ext4或者带sparse属性的raw ext4。sparse镜像Android为了减少固件体积和刷写时的传输量搞出了一种稀疏镜像格式。它的原理是文件系统中大量未使用的块不占实际存储空间用一个描述头sparse header配合chunk记录哪些区域有真实数据、哪些区域是空洞。好处是镜像文件体积小很多坏处是它不是一个标准的文件系统镜像没法直接挂载必须先用工具转换成raw格式。手机ROM里解出来的system.img大部分是这种sparse镜像。erofs镜像这个稍微新一点。erofsEnhanced Read-Only File System是Linux内核4.19起引入的只读文件系统专门为嵌入式场景设计。近几年的手机厂商尤其是国内厂商为了提升随机读取性能和节省存储空间越来越多地把system分区格式从ext4换成了erofs。erofs镜像在文件头有固定的magic number跟ext4很好区分。对erofs镜像的操作不能用ext4的工具链得用erofs-utils这套工具。2.2 一分钟判断格式的方法Linux下用file命令就够了Windows下可以用HxD这类十六进制编辑器看文件头。我整理了一个速查表文件头特征格式处理思路偏移0x438处有\x53\xEFext4raw直接挂载文件头有3A FF 26 ED且前几字节有SPARSE字样ASCIIsparse先转raw再处理文件头有\xE2\xE1\xF5\xE0erofs magicerofs用erofs-utils处理Windows下没有file命令的话用HxD打开文件看最前面16个字节就好。如果是sparse格式你能很直观地看到文件头有字符串SPARSE如果是ext4文件头的\x53\xEF这一对字节非常显眼erofs的magic则是一串不规则的字节E2 E1 F5 E0。2.3 为什么格式判断如此关键我见过不少人在这一步翻车。拿着一份erofs镜像按照网上的老教程用simg2img转稀疏又用debugfs去挂载结果报错报得莫名其妙。还有人把sparse镜像直接拖到Linux虚拟机里mount -o loop内核告诉他不认识这个文件系统。这些问题的根源只有一个格式没摸清就开始操作。提示rom包里的system.img如果要刷入设备厂商可能有额外的校验机制AVB、dm-verity等。这类校验在修改镜像后会触发导致设备无法开机或反复重启。这个问题在第5节专门讲这里先有个印象就行。3. Linux下解包与修改一条龙操作实录Linux是这个活儿的主战场。几乎所有处理system.img的工具都是Linux原生的操作链路最顺踩坑最少。如果你手里只有Windows电脑也别急着关页面——第4节会讲Windows的具体玩法。3.1 工具准备与安装需要的东西不多但都是关键角色simg2imgsparse转raw的工具Android官方源码里自带发行版软件源里可能叫android-tools-fsutils或类似名字。mount命令Linux自带的挂载工具需要root权限。debugfsext4文件系统调试神器e2fsprogs包的一部分。make_ext4fs或mkfs.ext4重新打包ext4镜像时用。erofs-utils处理erofs镜像的官方工具集包括fsck.erofs、dump.erofs、mkfs.erofs。Debian/Ubuntu系直接一条命令解决sudo apt install android-tools-fsutils e2fsprogs erofs-utils其他发行版类似Fedora系是dnf install android-tools erofs-utils。如果包里找不到simg2img可以直接用Android官方源码编但大多数场景下发行版仓库里的够用了。3.2 第一步sparse转raw如果是sparse格式先用file system.img看格式。如果确认是sparse执行转换simg2img system.img system_raw.img转换完成后可以用file system_raw.img确认一下这次应该能看到Linux rev 1.0 ext4 filesystem data之类的描述。转换的原理很简单simg2img会解析sparse header里的chunk信息把稀疏的数据块展开成连续的raw镜像。这个过程中文件体积会明显变大是正常现象。3.3 第二步挂载system.img挂载是读取和修改ext4镜像最直接的方式。先在本地建一个目录当作挂载点mkdir -p /mnt/system sudo mount -o loop system_raw.img /mnt/system看到这你可能想问为什么要加loop因为system.img是一个普通文件不是真正的块设备。loop参数会让内核通过loop设备把这文件模拟成一块磁盘然后才能按文件系统来挂载。这一步是理解整个流程的关键。挂载成功后/mnt/system下就是完整的Android系统目录树。你能看到app、priv-app、bin、etc、framework这些熟悉的目录。到这一步修改就成了普通的文件操作# 删除一个预装应用 sudo rm -rf /mnt/system/app/SomeBloatware # 往系统里塞一个自己的脚本 sudo cp my_script.sh /mnt/system/bin/ sudo chmod 755 /mnt/system/bin/my_script.sh如果只想查看、不想修改也可以只读挂载sudo mount -o loop,ro system_raw.img /mnt/system3.4 第三步取消挂载与检查改完后务必要正确卸载sudo umount /mnt/system为什么务必要因为你在挂载状态下对镜像做的任何修改实际上是写在内存里的页缓存中并没有真正落盘。只有umount才会把缓存里的脏页刷回到镜像文件。直接拔电源、直接删挂载目录、或者系统崩溃都会导致修改丢失甚至损坏镜像。umount之后建议跑一遍文件系统检查e2fsck -f system_raw.img这个检查会扫一遍ext4文件系统的完整性。如果上一轮操作中某个文件写到一半出了问题这里能发现并修复。检查完再进入打包环节。3.5 第四步重新打包成sparse按需如果你只想得到raw格式的system.img来直接fastboot刷写那到3.4就够了。但如果你想把它塞回一个zip格式的ROM包里保持体积优势就需要把raw转回sparse。工具是img2simgimg2simg system_raw.img system_new_sparse.img这一步是可选的取决于你的使用场景。fastboot刷写一般两种格式都认但Recovery卡刷包里的system镜像基本都要sparse格式。3.6 erofs镜像的特殊处理如果第2节判断格式是erofs整个流程要换成另一套工具。erofs的关键特征是只读你不能像ext4那样直接挂载然后写文件。官方提供的是fsck.erofs检测和dump.erofs查看但修改erofs镜像的常规做法是先解包成文件树改完文件树再用mkfs.erofs重新打包。# 解包需要erofs-utils部分发行版包名是erofs-utils fsck.erofs --extract/mnt/erofs_extract system.img # ...修改 /mnt/erofs_extract 下的文件... # 重新打包 mkfs.erofs -zlz4hc system_new.img /mnt/erofs_extract注意mkfs.erofs的压缩算法参数-z和原始镜像可能不一样。同样一份文件用不同压缩算法打包体积和读取性能会有差异。建议先用dump.erofs system.img看看原镜像用了什么算法尽量保持一致避免刷入后出现意外问题。经验我处理过的绝大多数国内厂商固件近几年已经从ext4切到了erofs。遇到新ROM包先按第2节的方法判断格式别默认它是ext4这是最省时间的习惯。4. Windows平台的三种路径从原生工具到WSLWindows下改system.img确实比Linux麻烦不少但也不是无路可走。我把实际验证过可行的路径整理成三条按推荐度排序你可以根据自己的需求选。4.1 路径一强烈推荐WSL把Windows变成Linux工作台如果你装了WSLWindows Subsystem for Linux那恭喜你Windows下的操作体验几乎和Linux完全一致。WSL不仅仅是在Windows里跑个Linux终端它是完整的Linux内核在微软的虚拟化平台上运行WSL2可以直接挂载loop设备。具体操作逻辑是在Windows文件系统里放好system.img然后在WSL里访问它。WSL会自动把Windows的盘挂载到/mnt/c、/mnt/d这样路径下。比如你把镜像放在D:\rom\system.img在WSL里访问路径就是cd /mnt/d/rom file system.img唯一的注意事项是性能。从WSL访问/mnt/d这类跨文件系统的路径I/O速度会比WSL内部文件系统慢不少。处理几个GB的system.img时转换sparse格式会等得久一点但完全在可接受范围内。如果频繁处理镜像可以把文件拷贝到WSL的home目录下操作速度会快很多cp /mnt/d/rom/system.img ~/WSL里安装工具链和Linux环境完全一样第3节的所有命令都能用。这是目前Windows平台处理镜像最省心的方案没有之一。提示WSL2默认支持loop设备吗我在WSL2上实测mount loop是可以用的但如果遇到权限问题试试在管理员权限的PowerShell里执行wsl --shutdown后重开WSL或者检查/etc/wsl.conf里[automount]的配置。4.2 路径二纯Windows原生工具适合只做简单操作如果你不想装WSL只想快速从system.img里提取几个文件试试ext2explore这个老牌工具。它是Windows下直接读取ext4文件系统的图形化工具支持raw ext4镜像的直接浏览和文件导出。打开后选File - Open指向system.img就能像资源管理器一样浏览系统目录了。但注意ext2explore只支持读取不支持写入。它解决的是我想看看system.img里有什么、把某个应用提取出来这类需求。如果你想删除应用、修改配置这个工具无能为力。另一个思路是用DiskGenius的打开镜像文件功能。它对新版ext4的支持比ext2explore好一些但同样主要面向文件提取场景写回能力有限。第三个工具是OSFMount。它能把raw ext4镜像挂载成一个Windows盘符。挂载后Windows的explorer能看到盘符但Windows本身不原生支持ext4文件系统所以OSFMount实际上只是把镜像关联到了驱动层真正读取还是需要搭配ext4驱动。整体来说这条路配置繁琐、兼容性一般不如WSL来得干净。4.3 路径三虚拟机兜底没别的办法时的选择如果WSL装不上、工具又不够用就上虚拟机。在VMware或VirtualBox里装一个Ubuntu Server不带图形界面纯命令行资源占用小然后把system.img通过共享文件夹或直接拖拽拷进虚拟机。后面的操作就完全变成Linux流程了。虚拟机的缺点很明显占内存、启动慢、共享文件夹的传输速度让人着急。但它的优势是环境干净、和物理机隔离不用担心搞坏Windows。如果你手头正好有一台常开的Linux虚拟机那这条路其实比装WSL还省事。4.4 Windows下格式判断没有file命令的替代方案Windows下没有Linux的file命令判断镜像格式有两个办法用HxD打开镜像看文件头十六进制sparse格式能看到ASCII的SPARSE字样ext4格式在偏移0x438处有\x53\xEF。用WSL里的file命令如果有WSL的话。提前判断格式能帮你决定后续用哪套工具链千万别跳过。5. 重新打包与刷写让改动真正落到手机上在电脑上改完system.img只是完成了前半程。后半程是把镜像弄回手机里并让它能正常开机。这一节讲打包时容易忽略的关键参数以及刷写后常见的开机死循环问题。5.1 重新打包时最关键的参数分区大小用make_ext4fs打包时最核心的参数是镜像的目标大小size。这个大小必须和你设备真实system分区大小匹配。如果打包出来的镜像比分区大刷写会失败如果比分区小太多文件系统可能用不满浪费空间某些设备还会因为分区表检查不通过而报错。怎么拿到真实的分区大小两个来源原镜像的大小raw格式的system.img体积就是原始分区的近似大小注意有些厂商的system.img并不是完整分区大小。设备上执行df -h /system或cat /proc/partitions看到的大小。打包命令示例make_ext4fs -s -l 3145728000 system_new.img /mnt/system-l参数的单位是字节也可以直接用-L指定大小加单位比如-l 3G。-s参数表示生成sparse格式如果不需要可以去掉。新版Android还引入了-T参数用来指定镜像的时间戳。这个时间戳会影响增量OTA的比对自己刷机的话影响不大但如果将来要做OTA包最好保持和原镜像一致。5.2 AVB校验与dm-verity改完系统无法开机的元凶现代Android设备基本都启用了AVBAndroid Verified Boot和dm-verity。简单说bootloader在启动时会校验system分区的哈希树如果镜像被改动而校验没同步更新设备会判定系统被篡改直接拒绝启动表现就是开机卡在logo、无限重启、或者直接进bootloader/Recovery并要求恢复出厂。这个问题有几种解法刷入禁用了AVB的boot/recovery。很多第三方Recovery如TWRP自带禁用dm-verity的选项刷完再刷修改过的system.img就行。用工具重签镜像。需要用到AVB工具链avbtool手动计算并写入新的哈希。这个操作复杂度较高适合对AVB机制有一定理解的玩家。刷入前先确认设备的bootloader是否解锁。未解锁的bootloader基本不允许刷任何非官方签名的镜像。我的建议是如果是刚接触system.img修改优先考虑关闭AVB或使用已禁用的第三方Recovery等技术熟练了再研究重签这条硬核路线。另外每次刷写前记得完整备份原镜像和分区数据这个习惯能救你很多次。5.3 修改后无法开机按这个顺序排查如果刷完新镜像手机卡在开机画面别慌。多数情况下不是设备坏了而是下面这几个原因之一文件系统大小不对打包时-l参数设的分区大小和实际分区不匹配。重新确认分区大小再打包。删除系统关键文件精简应用时手一抖把framework相关的东西删了。检查你删了什么必要的话把/system/framework目录下的核心jar包恢复回去。权限或属主错误新加进镜像的文件如果owner不是root或者权限不对比如可执行文件没加x权限开机时会因为权限问题崩溃。在Linux下用sudo chown root:root和sudo chmod修正。没关AVB/dm-verity改完镜像没处理签名校验被安全机制拦截了。selinux上下文不一致Android启用SELinux后系统文件都有特定的安全上下文标签security context。新加的文件如果没有正确的上下文会被SELinux拒绝访问。打包时用make_ext4fs -S file_contexts指定上下文文件这个文件可以从原镜像里提取路径一般是/system/etc/selinux/plat_file_contexts或设备上的/file_contexts。第5条是很多人忽略的坑。自行修改系统后开不了机十有七八和SELinux标签有关。打包命令里加上-S参数指到对应的file_contexts文件能解决一大批莫名其妙的开机问题。6. 实测高频报错与应对思路最后这部分汇总几个实操中反复出现的报错和我的排查思路。这些报错信息看起来各不相同但多数根源其实落在同一个地方——格式没分清或打包参数不对。报错一mount: wrong fs type, bad option, bad superblock看到这个第一反应是去看这个镜像到底是不是ext4。用file看一眼如果之前忘了转sparse这里就会报这个错。解决办法先simg2img转格式再挂载。还有一种情况是镜像本身损坏了先用simg2img转raw后用e2fsck -f修复。报错二e2fsck: Attempt to read block from filesystem resulted in short read这个多半是文件系统大小和镜像文件实际大小不一致。检查一下你是不是直接拿一个sparse镜像强行跑了e2fsck或者打包时-l参数写错了。解决办法确认镜像已经是raw格式并且文件大小和文件系统声明的大小一致。报错三make_ext4fs: No such file or directory这个很乌龙通常是工作目录或路径引号的问题。你有可能是从Windows共享目录直接操作的路径里有空格或中文。统一把镜像和文件树考到Linux本地目录下再执行路径里不要有中文和空格。报错四selinux: avc: denied ...这是SELinux拒绝访问的日志。修改过的文件缺少正确的上下文标签。在打包时补上-S file_contexts参数。如果不知道file_contexts文件在哪从原system.img挂载后的/system/etc/selinux/目录下找或者从设备上提取。报错五erofs挂载报错或mkfs.erofs版本过旧新设备用的erofs版本可能比发行版仓库里的新报错通常是superblock信息无法识别。解决办法是从erofs官方仓库编一份最新版的erofs-utils老版本不认新格式是常见问题。这些报错在搞过几次镜像修改后基本都能一眼定位。关键还是回到第2节说的那句话——先判断格式再选工具链。格式判断不出错后面九成的问题都不会发生。最后分享一个我自己的习惯无论改什么镜像动手之前先把原始文件做一份备份放在另一个目录、另一块硬盘、或者直接压缩存档。改坏了随时能回到起点重新来过这比任何技巧都重要。
1. system.img为何要改先搞清楚这张系统盘的脾气玩Android的时间稍微长一点基本都会遇到这个需求自带应用删不掉、想加个开机脚本、想把某几个系统应用替换成自己改过的版本、或者单纯想把谷歌全家桶从国行固件里拔掉。这些操作的最终落点几乎都是那个又爱又恨的system.img。很多新手第一次接触system.img容易把它当成普通的镜像文件以为像解压zip一样双击就能打开。结果在Windows上试了半天发现7-Zip打不开、WinRAR也不认识于是开始怀疑文件是不是坏了。这不是你的问题是system.img的封装方式跟普通压缩包压根不在一个维度。先说清楚system.img到底是什么。它是Android系统分区system分区的完整磁盘镜像挂载到设备后的路径是/system里面装着Android运行的核心东西系统框架framework、预装应用/system/app、/system/priv-app、原生库/system/lib、/system/lib64、可执行文件/system/bin、系统配置/system/etc以及build.prop这个系统属性文件。可以说手机开机能跑起来全靠这个分区。它的脾气在于这个镜像不是普通的文件打包格式而是一个包含了文件系统结构的块设备镜像。我们看到的system.img本质上是把整个system分区按块block逐字节复刻出来的文件。所以要在电脑上修改它核心思路不是解压文件而是把文件系统挂载起来改完再固化回去。这篇文章讲的操作面向的场景是你手里有一个system.img可能是从ROM包解出来的也可能是从手机里备份出来的想在Windows或Linux电脑上打开它、往里面塞东西或者删东西、然后重新打包成可用的镜像。这个流程在定制ROM、系统精简、功能移植、学习Android系统结构时都会反复用到属于玩机基本功里比较硬核的一项。2. 识别镜像格式raw、sparse与erofs的分辨方法拿到一个system.img第一件事不是着急找工具而是先判断它是什么格式。格式判断错了后面全部白干。这一步花不了30秒但能帮你避开接下来一小时的无效操作。2.1 三种最常见的system.img格式raw ext4镜像这是最规矩的格式。整个镜像就是一份完整的ext4文件系统镜像文件系统头部superblock在镜像文件的最开头偏移量是0。这种镜像最老实mount命令直接就能挂载不需要任何转换。Google官方的出厂镜像Factory Image里如果解出来是system.img很多就是raw ext4或者带sparse属性的raw ext4。sparse镜像Android为了减少固件体积和刷写时的传输量搞出了一种稀疏镜像格式。它的原理是文件系统中大量未使用的块不占实际存储空间用一个描述头sparse header配合chunk记录哪些区域有真实数据、哪些区域是空洞。好处是镜像文件体积小很多坏处是它不是一个标准的文件系统镜像没法直接挂载必须先用工具转换成raw格式。手机ROM里解出来的system.img大部分是这种sparse镜像。erofs镜像这个稍微新一点。erofsEnhanced Read-Only File System是Linux内核4.19起引入的只读文件系统专门为嵌入式场景设计。近几年的手机厂商尤其是国内厂商为了提升随机读取性能和节省存储空间越来越多地把system分区格式从ext4换成了erofs。erofs镜像在文件头有固定的magic number跟ext4很好区分。对erofs镜像的操作不能用ext4的工具链得用erofs-utils这套工具。2.2 一分钟判断格式的方法Linux下用file命令就够了Windows下可以用HxD这类十六进制编辑器看文件头。我整理了一个速查表文件头特征格式处理思路偏移0x438处有\x53\xEFext4raw直接挂载文件头有3A FF 26 ED且前几字节有SPARSE字样ASCIIsparse先转raw再处理文件头有\xE2\xE1\xF5\xE0erofs magicerofs用erofs-utils处理Windows下没有file命令的话用HxD打开文件看最前面16个字节就好。如果是sparse格式你能很直观地看到文件头有字符串SPARSE如果是ext4文件头的\x53\xEF这一对字节非常显眼erofs的magic则是一串不规则的字节E2 E1 F5 E0。2.3 为什么格式判断如此关键我见过不少人在这一步翻车。拿着一份erofs镜像按照网上的老教程用simg2img转稀疏又用debugfs去挂载结果报错报得莫名其妙。还有人把sparse镜像直接拖到Linux虚拟机里mount -o loop内核告诉他不认识这个文件系统。这些问题的根源只有一个格式没摸清就开始操作。提示rom包里的system.img如果要刷入设备厂商可能有额外的校验机制AVB、dm-verity等。这类校验在修改镜像后会触发导致设备无法开机或反复重启。这个问题在第5节专门讲这里先有个印象就行。3. Linux下解包与修改一条龙操作实录Linux是这个活儿的主战场。几乎所有处理system.img的工具都是Linux原生的操作链路最顺踩坑最少。如果你手里只有Windows电脑也别急着关页面——第4节会讲Windows的具体玩法。3.1 工具准备与安装需要的东西不多但都是关键角色simg2imgsparse转raw的工具Android官方源码里自带发行版软件源里可能叫android-tools-fsutils或类似名字。mount命令Linux自带的挂载工具需要root权限。debugfsext4文件系统调试神器e2fsprogs包的一部分。make_ext4fs或mkfs.ext4重新打包ext4镜像时用。erofs-utils处理erofs镜像的官方工具集包括fsck.erofs、dump.erofs、mkfs.erofs。Debian/Ubuntu系直接一条命令解决sudo apt install android-tools-fsutils e2fsprogs erofs-utils其他发行版类似Fedora系是dnf install android-tools erofs-utils。如果包里找不到simg2img可以直接用Android官方源码编但大多数场景下发行版仓库里的够用了。3.2 第一步sparse转raw如果是sparse格式先用file system.img看格式。如果确认是sparse执行转换simg2img system.img system_raw.img转换完成后可以用file system_raw.img确认一下这次应该能看到Linux rev 1.0 ext4 filesystem data之类的描述。转换的原理很简单simg2img会解析sparse header里的chunk信息把稀疏的数据块展开成连续的raw镜像。这个过程中文件体积会明显变大是正常现象。3.3 第二步挂载system.img挂载是读取和修改ext4镜像最直接的方式。先在本地建一个目录当作挂载点mkdir -p /mnt/system sudo mount -o loop system_raw.img /mnt/system看到这你可能想问为什么要加loop因为system.img是一个普通文件不是真正的块设备。loop参数会让内核通过loop设备把这文件模拟成一块磁盘然后才能按文件系统来挂载。这一步是理解整个流程的关键。挂载成功后/mnt/system下就是完整的Android系统目录树。你能看到app、priv-app、bin、etc、framework这些熟悉的目录。到这一步修改就成了普通的文件操作# 删除一个预装应用 sudo rm -rf /mnt/system/app/SomeBloatware # 往系统里塞一个自己的脚本 sudo cp my_script.sh /mnt/system/bin/ sudo chmod 755 /mnt/system/bin/my_script.sh如果只想查看、不想修改也可以只读挂载sudo mount -o loop,ro system_raw.img /mnt/system3.4 第三步取消挂载与检查改完后务必要正确卸载sudo umount /mnt/system为什么务必要因为你在挂载状态下对镜像做的任何修改实际上是写在内存里的页缓存中并没有真正落盘。只有umount才会把缓存里的脏页刷回到镜像文件。直接拔电源、直接删挂载目录、或者系统崩溃都会导致修改丢失甚至损坏镜像。umount之后建议跑一遍文件系统检查e2fsck -f system_raw.img这个检查会扫一遍ext4文件系统的完整性。如果上一轮操作中某个文件写到一半出了问题这里能发现并修复。检查完再进入打包环节。3.5 第四步重新打包成sparse按需如果你只想得到raw格式的system.img来直接fastboot刷写那到3.4就够了。但如果你想把它塞回一个zip格式的ROM包里保持体积优势就需要把raw转回sparse。工具是img2simgimg2simg system_raw.img system_new_sparse.img这一步是可选的取决于你的使用场景。fastboot刷写一般两种格式都认但Recovery卡刷包里的system镜像基本都要sparse格式。3.6 erofs镜像的特殊处理如果第2节判断格式是erofs整个流程要换成另一套工具。erofs的关键特征是只读你不能像ext4那样直接挂载然后写文件。官方提供的是fsck.erofs检测和dump.erofs查看但修改erofs镜像的常规做法是先解包成文件树改完文件树再用mkfs.erofs重新打包。# 解包需要erofs-utils部分发行版包名是erofs-utils fsck.erofs --extract/mnt/erofs_extract system.img # ...修改 /mnt/erofs_extract 下的文件... # 重新打包 mkfs.erofs -zlz4hc system_new.img /mnt/erofs_extract注意mkfs.erofs的压缩算法参数-z和原始镜像可能不一样。同样一份文件用不同压缩算法打包体积和读取性能会有差异。建议先用dump.erofs system.img看看原镜像用了什么算法尽量保持一致避免刷入后出现意外问题。经验我处理过的绝大多数国内厂商固件近几年已经从ext4切到了erofs。遇到新ROM包先按第2节的方法判断格式别默认它是ext4这是最省时间的习惯。4. Windows平台的三种路径从原生工具到WSLWindows下改system.img确实比Linux麻烦不少但也不是无路可走。我把实际验证过可行的路径整理成三条按推荐度排序你可以根据自己的需求选。4.1 路径一强烈推荐WSL把Windows变成Linux工作台如果你装了WSLWindows Subsystem for Linux那恭喜你Windows下的操作体验几乎和Linux完全一致。WSL不仅仅是在Windows里跑个Linux终端它是完整的Linux内核在微软的虚拟化平台上运行WSL2可以直接挂载loop设备。具体操作逻辑是在Windows文件系统里放好system.img然后在WSL里访问它。WSL会自动把Windows的盘挂载到/mnt/c、/mnt/d这样路径下。比如你把镜像放在D:\rom\system.img在WSL里访问路径就是cd /mnt/d/rom file system.img唯一的注意事项是性能。从WSL访问/mnt/d这类跨文件系统的路径I/O速度会比WSL内部文件系统慢不少。处理几个GB的system.img时转换sparse格式会等得久一点但完全在可接受范围内。如果频繁处理镜像可以把文件拷贝到WSL的home目录下操作速度会快很多cp /mnt/d/rom/system.img ~/WSL里安装工具链和Linux环境完全一样第3节的所有命令都能用。这是目前Windows平台处理镜像最省心的方案没有之一。提示WSL2默认支持loop设备吗我在WSL2上实测mount loop是可以用的但如果遇到权限问题试试在管理员权限的PowerShell里执行wsl --shutdown后重开WSL或者检查/etc/wsl.conf里[automount]的配置。4.2 路径二纯Windows原生工具适合只做简单操作如果你不想装WSL只想快速从system.img里提取几个文件试试ext2explore这个老牌工具。它是Windows下直接读取ext4文件系统的图形化工具支持raw ext4镜像的直接浏览和文件导出。打开后选File - Open指向system.img就能像资源管理器一样浏览系统目录了。但注意ext2explore只支持读取不支持写入。它解决的是我想看看system.img里有什么、把某个应用提取出来这类需求。如果你想删除应用、修改配置这个工具无能为力。另一个思路是用DiskGenius的打开镜像文件功能。它对新版ext4的支持比ext2explore好一些但同样主要面向文件提取场景写回能力有限。第三个工具是OSFMount。它能把raw ext4镜像挂载成一个Windows盘符。挂载后Windows的explorer能看到盘符但Windows本身不原生支持ext4文件系统所以OSFMount实际上只是把镜像关联到了驱动层真正读取还是需要搭配ext4驱动。整体来说这条路配置繁琐、兼容性一般不如WSL来得干净。4.3 路径三虚拟机兜底没别的办法时的选择如果WSL装不上、工具又不够用就上虚拟机。在VMware或VirtualBox里装一个Ubuntu Server不带图形界面纯命令行资源占用小然后把system.img通过共享文件夹或直接拖拽拷进虚拟机。后面的操作就完全变成Linux流程了。虚拟机的缺点很明显占内存、启动慢、共享文件夹的传输速度让人着急。但它的优势是环境干净、和物理机隔离不用担心搞坏Windows。如果你手头正好有一台常开的Linux虚拟机那这条路其实比装WSL还省事。4.4 Windows下格式判断没有file命令的替代方案Windows下没有Linux的file命令判断镜像格式有两个办法用HxD打开镜像看文件头十六进制sparse格式能看到ASCII的SPARSE字样ext4格式在偏移0x438处有\x53\xEF。用WSL里的file命令如果有WSL的话。提前判断格式能帮你决定后续用哪套工具链千万别跳过。5. 重新打包与刷写让改动真正落到手机上在电脑上改完system.img只是完成了前半程。后半程是把镜像弄回手机里并让它能正常开机。这一节讲打包时容易忽略的关键参数以及刷写后常见的开机死循环问题。5.1 重新打包时最关键的参数分区大小用make_ext4fs打包时最核心的参数是镜像的目标大小size。这个大小必须和你设备真实system分区大小匹配。如果打包出来的镜像比分区大刷写会失败如果比分区小太多文件系统可能用不满浪费空间某些设备还会因为分区表检查不通过而报错。怎么拿到真实的分区大小两个来源原镜像的大小raw格式的system.img体积就是原始分区的近似大小注意有些厂商的system.img并不是完整分区大小。设备上执行df -h /system或cat /proc/partitions看到的大小。打包命令示例make_ext4fs -s -l 3145728000 system_new.img /mnt/system-l参数的单位是字节也可以直接用-L指定大小加单位比如-l 3G。-s参数表示生成sparse格式如果不需要可以去掉。新版Android还引入了-T参数用来指定镜像的时间戳。这个时间戳会影响增量OTA的比对自己刷机的话影响不大但如果将来要做OTA包最好保持和原镜像一致。5.2 AVB校验与dm-verity改完系统无法开机的元凶现代Android设备基本都启用了AVBAndroid Verified Boot和dm-verity。简单说bootloader在启动时会校验system分区的哈希树如果镜像被改动而校验没同步更新设备会判定系统被篡改直接拒绝启动表现就是开机卡在logo、无限重启、或者直接进bootloader/Recovery并要求恢复出厂。这个问题有几种解法刷入禁用了AVB的boot/recovery。很多第三方Recovery如TWRP自带禁用dm-verity的选项刷完再刷修改过的system.img就行。用工具重签镜像。需要用到AVB工具链avbtool手动计算并写入新的哈希。这个操作复杂度较高适合对AVB机制有一定理解的玩家。刷入前先确认设备的bootloader是否解锁。未解锁的bootloader基本不允许刷任何非官方签名的镜像。我的建议是如果是刚接触system.img修改优先考虑关闭AVB或使用已禁用的第三方Recovery等技术熟练了再研究重签这条硬核路线。另外每次刷写前记得完整备份原镜像和分区数据这个习惯能救你很多次。5.3 修改后无法开机按这个顺序排查如果刷完新镜像手机卡在开机画面别慌。多数情况下不是设备坏了而是下面这几个原因之一文件系统大小不对打包时-l参数设的分区大小和实际分区不匹配。重新确认分区大小再打包。删除系统关键文件精简应用时手一抖把framework相关的东西删了。检查你删了什么必要的话把/system/framework目录下的核心jar包恢复回去。权限或属主错误新加进镜像的文件如果owner不是root或者权限不对比如可执行文件没加x权限开机时会因为权限问题崩溃。在Linux下用sudo chown root:root和sudo chmod修正。没关AVB/dm-verity改完镜像没处理签名校验被安全机制拦截了。selinux上下文不一致Android启用SELinux后系统文件都有特定的安全上下文标签security context。新加的文件如果没有正确的上下文会被SELinux拒绝访问。打包时用make_ext4fs -S file_contexts指定上下文文件这个文件可以从原镜像里提取路径一般是/system/etc/selinux/plat_file_contexts或设备上的/file_contexts。第5条是很多人忽略的坑。自行修改系统后开不了机十有七八和SELinux标签有关。打包命令里加上-S参数指到对应的file_contexts文件能解决一大批莫名其妙的开机问题。6. 实测高频报错与应对思路最后这部分汇总几个实操中反复出现的报错和我的排查思路。这些报错信息看起来各不相同但多数根源其实落在同一个地方——格式没分清或打包参数不对。报错一mount: wrong fs type, bad option, bad superblock看到这个第一反应是去看这个镜像到底是不是ext4。用file看一眼如果之前忘了转sparse这里就会报这个错。解决办法先simg2img转格式再挂载。还有一种情况是镜像本身损坏了先用simg2img转raw后用e2fsck -f修复。报错二e2fsck: Attempt to read block from filesystem resulted in short read这个多半是文件系统大小和镜像文件实际大小不一致。检查一下你是不是直接拿一个sparse镜像强行跑了e2fsck或者打包时-l参数写错了。解决办法确认镜像已经是raw格式并且文件大小和文件系统声明的大小一致。报错三make_ext4fs: No such file or directory这个很乌龙通常是工作目录或路径引号的问题。你有可能是从Windows共享目录直接操作的路径里有空格或中文。统一把镜像和文件树考到Linux本地目录下再执行路径里不要有中文和空格。报错四selinux: avc: denied ...这是SELinux拒绝访问的日志。修改过的文件缺少正确的上下文标签。在打包时补上-S file_contexts参数。如果不知道file_contexts文件在哪从原system.img挂载后的/system/etc/selinux/目录下找或者从设备上提取。报错五erofs挂载报错或mkfs.erofs版本过旧新设备用的erofs版本可能比发行版仓库里的新报错通常是superblock信息无法识别。解决办法是从erofs官方仓库编一份最新版的erofs-utils老版本不认新格式是常见问题。这些报错在搞过几次镜像修改后基本都能一眼定位。关键还是回到第2节说的那句话——先判断格式再选工具链。格式判断不出错后面九成的问题都不会发生。最后分享一个我自己的习惯无论改什么镜像动手之前先把原始文件做一份备份放在另一个目录、另一块硬盘、或者直接压缩存档。改坏了随时能回到起点重新来过这比任何技巧都重要。
