解压system.img
前言
在Android系统开发中，有时候通过log和报错无法定位到问题时，会通过其他辅助手段。
如我碰到一个问题：客户出的软件存在问题(android.os.cts.StrictModeTest#testCleartextNetwork)，我们的各个版本都没有问题，通过log等都找不到原因。
最后，通过替换分区，定位到问题在system区。然后解压两个软件的system.img，push替换差异文件，定位到问题在/system/bin/iptables-restore这个文件。然后要来两边工程的/external/iptables进行比较，发现的确存在差异，整个替换后问题解决。
可能客户建仓库操作不当导致的，因为这个目录下很多文件名一样的 仅大小写不同，在window下是不能操作的。
这里记录下解压system.img过程。
这篇算不得完整的文章，部分问题也没得到解决，这里记录过程和问题(下面红色部分)，便于完善。
解压system.img
这里仅记录碰到过的情况，后续碰到新的情况在这里继续更新。(操作命令都在linux下)
确定system.img的文件类型
file system.img
一般有这3种类型：
- 输出为Linux rev 1.0 [ext2/ext4] filesystem data，即raw文件。
- 输出为data，即ext文件。
- 输出为VMS Alpha executable，yaffs2文件，这个暂未碰到 这里不做记录。
注：raw(Raw image)包含很多全零的无效填充区，所以比较大，可以直接挂载。ext(英文sparse image)是raw的稀疏描述，不包含全零的无效填充区，因此比较小。
解压raw类型 system.img
raw可以直接挂载。
AndroidQ是这种格式：
xxx#xxx file system.img
system.img: Linux rev 1.0 ext2 filesystem data, UUID=4729639d-b5f2-5cc1-a120-9ac5f788683c (extents) (large files) (huge files)
xxx#xxx mkdir system
xxx#xxx mount system.img system
注意这里是ext2，ext4没有问题，在下面也会看到。
这里就有个问题：我们自己的Q的项目编出的system.img可以直接挂载成功，但google释放的gsi(signed_signed-aosp_arm-img)中的system.img直接挂载失败(file看到的内容是一致的)，尝试类似解压initrd.img方法也不行。
解压ext类型 system.img
Android O/Andorid P都是这种类型：
xxxx@xxxx:# file system.img
system.img: data
xxx#xxx ./simg2img system.img system.ext4.img
xxx#xxx file system.ext4.img
system.ext4.img: Linux rev 1.0 ext4 filesystem data, UUID=6f8511d5-cc14-5467-8fc3-fea8427a7d8f, volume name "system" (extents) (64bit) (large files) (huge files)
xxx#xxx mount system.ext4.img system/
通过simg2img脚本，转成raw格式即可。
simg2img脚本在工程的out/host/linux-x86/bin/下，out/host/linux-x86/lib64/libc++.so这个库是必须的。
