前言
在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這個庫是必須的。