1. 從一次真實(shí)的存儲(chǔ)異常說起/storage/emulated/0/Android/data/這個(gè)路徑做 Android 開發(fā)或者玩機(jī)的人應(yīng)該都不陌生。它幾乎是每個(gè) App 存放緩存、下載文件、臨時(shí)數(shù)據(jù)的默認(rèn)位置。但就是這個(gè)看起來平平無奇的目錄最近讓我在一臺設(shè)備上折騰了整整兩天。事情的起因很簡單某天測試同事反饋App 里下載的文件在文件管理器里找不到了預(yù)覽也打不開日志里反復(fù)刷出unable to chmod /storage/emulated/0/Android/data/com.xjs.ehviewer: Operation not permitted這樣的報(bào)錯(cuò)。更詭異的是用adb shell ls -lZ去看這些目錄的 SELinux 上下文全部顯示為unlabeled而不是正常的u:object_r:fuse:s0或者u:object_r:media_rw_data_file:s0。這就是典型的Android Ext4 文件系統(tǒng)層面的問題而且往往不是單一原因造成的。它可能牽扯到SELinux 策略、FUSE 掛載、VFS 層權(quán)限校驗(yàn)、sync 刷盤時(shí)機(jī)甚至是底層 Ext4 的 inode 狀態(tài)異常。這篇文章我就把這次排查的完整過程、用到的工具、踩過的坑以及一套可復(fù)用的排查方法論整理出來。不管你是做 App 開發(fā)、系統(tǒng)定制還是單純喜歡折騰 Android 存儲(chǔ)應(yīng)該都能從中找到能直接抄作業(yè)的東西。先明確一下這篇文章適合誰看如果你只是普通用戶遇到文件找不到重啟一下就好那沒必要往下讀但如果你是Android 開發(fā)、ROM 定制、系統(tǒng)測試、或者需要深度定位存儲(chǔ)問題的工程師那這篇內(nèi)容會(huì)幫你省下大量瞎試的時(shí)間。我會(huì)從 Ext4 的基礎(chǔ)結(jié)構(gòu)講起一路講到 SELinux 上下文修復(fù)和 FUSE 掛載排查中間穿插大量實(shí)際命令和參數(shù)解釋。2. 先搞懂 Android 存儲(chǔ)的分層結(jié)構(gòu)2.1 Ext4 在 Android 里到底扮演什么角色很多人一提到 Android 文件系統(tǒng)就想到 Ext4但實(shí)際上從 Android 10 開始用戶可見的/sdcard或/storage/emulated/0已經(jīng)不是真正的 Ext4 分區(qū)了。真正的 Ext4 分區(qū)通常是/data分區(qū)它承載了所有 App 的私有數(shù)據(jù)、系統(tǒng)數(shù)據(jù)以及媒體存儲(chǔ)的底層實(shí)體。而/storage/emulated/0是通過FUSEFilesystem in Userspace或者更新的FUSE passthrough機(jī)制把/data/media/0這個(gè)真實(shí)目錄模擬出來的一個(gè)視圖。這個(gè)區(qū)別非常關(guān)鍵。當(dāng)你看到/storage/emulated/0/Android/data/com.xxx/files/里的文件出問題時(shí)可能出問題的層次有三個(gè)最底層/data/media/0/Android/data/...這個(gè)真實(shí)的 Ext4 目錄inode、塊分配、日志是否正常。中間層FUSE 守護(hù)進(jìn)程是否正確掛載、權(quán)限映射是否正確。最上層SELinux 上下文和 VFS 權(quán)限檢查是否放行。我這次遇到的問題最終定位是中間層和上層的組合問題FUSE 掛載點(diǎn)在某些異常斷電后沒有正確重建導(dǎo)致上層看到的目錄 SELinux 標(biāo)簽變成unlabeled而unlabeled在 enforcing 模式下幾乎會(huì)被所有域拒絕訪問于是chmod報(bào)Operation not permittedApp 自然也就讀不到文件。2.2 為什么unlabeled是個(gè)危險(xiǎn)信號SELinux 在 Android 上默認(rèn)是enforcing模式。每個(gè)文件、目錄、socket 都有一個(gè)安全上下文security context格式類似u:object_r:media_rw_data_file:s0。當(dāng)系統(tǒng)給一個(gè)文件打標(biāo)簽時(shí)如果找不到匹配的規(guī)則就會(huì) fallback 到unlabeled。unlabeled意味著什么意味著沒有任何域被明確允許訪問它。普通 App 域untrusted_app訪問unlabeled文件會(huì)被avc: denied攔截系統(tǒng)域訪問也可能被攔。所以你看到unlabeled基本可以斷定這個(gè)文件或目錄的標(biāo)簽丟失了需要重新 restorecon。但要注意不是所有unlabeled都能靠 restorecon 解決。如果底層 Ext4 的 inode 已經(jīng)損壞或者 FUSE 掛載點(diǎn)本身有問題restorecon 會(huì)報(bào)Permission denied或者干脆沒效果。這時(shí)候就得往更底層查。2.3 VFS、sync 與數(shù)據(jù)一致性的關(guān)系再往深一層Android 的存儲(chǔ)寫入最終都要經(jīng)過VFSVirtual File System層。VFS 負(fù)責(zé)把write()、fsync()、sync()這些系統(tǒng)調(diào)用翻譯成具體文件系統(tǒng)Ext4、F2FS 等的操作。這里有個(gè)容易被忽略的點(diǎn)sync命令和fsync系統(tǒng)調(diào)用不是一回事。sync是把整個(gè)系統(tǒng)的臟頁刷到磁盤而fsync只刷某個(gè)文件描述符對應(yīng)的數(shù)據(jù)。Android 在異常斷電或者強(qiáng)制重啟時(shí)如果 FUSE 層還有未刷盤的數(shù)據(jù)就可能出現(xiàn)目錄項(xiàng)存在但 inode 未完全落盤的情況表現(xiàn)出來就是文件在但打不開、標(biāo)簽丟失。我這次排查時(shí)用adb shell sync手動(dòng)刷盤后部分文件的unlabeled狀態(tài)確實(shí)恢復(fù)了但另一部分依然異常。這說明問題不只是刷盤時(shí)機(jī)還有更深層的掛載狀態(tài)問題。3. 排查工具鏈與核心命令詳解3.1 用 adb 和 shell 命令定位問題層級排查這類問題第一步永遠(yuǎn)是確認(rèn)問題出在哪一層。我常用的命令組合如下# 查看掛載情況確認(rèn) FUSE 是否正常 adb shell mount | grep -E fuse|emulated|media # 查看目錄的 SELinux 上下文 adb shell ls -lZ /storage/emulated/0/Android/data/ # 查看真實(shí) Ext4 路徑的上下文 adb shell ls -lZ /data/media/0/Android/data/ # 查看文件系統(tǒng)類型和掛載參數(shù) adb shell cat /proc/mounts | grep -E data|media # 檢查 dmesg 里有沒有 Ext4 或 FUSE 相關(guān)報(bào)錯(cuò) adb shell dmesg | grep -iE ext4|fuse|selinux|avc這幾條命令下來基本能判斷問題是出在 FUSE 掛載、SELinux 標(biāo)簽還是 Ext4 本身。我這次的情況是/storage/emulated/0/...顯示unlabeled但/data/media/0/...顯示正常標(biāo)簽。這就說明底層 Ext4 是好的問題在 FUSE 映射層。3.2 restorecon 的正確用法與限制確認(rèn)是標(biāo)簽問題后常規(guī)操作是restoreconadb shell restorecon -R -v /data/media/0/Android/data/com.xxx但這里有幾個(gè)坑必須對真實(shí)路徑操作對/storage/emulated/0/...執(zhí)行 restorecon 往往無效因?yàn)?FUSE 層不響應(yīng) SELinux 標(biāo)簽設(shè)置。-R遞歸可能很慢如果目錄很大建議先定位到具體子目錄。如果報(bào)Operation not permitted說明當(dāng)前 shell 沒有權(quán)限需要 root 或者adb root。我實(shí)測下來對/data/media/0執(zhí)行 restorecon 后再重新掛載 FUSE或者重啟media相關(guān)服務(wù)/storage/emulated/0下的標(biāo)簽就恢復(fù)正常了。3.3 用 debugfs 檢查 Ext4 inode 狀態(tài)如果 restorecon 也救不回來那就得懷疑 Ext4 本身了。這時(shí)候可以用debugfs工具需要 rootadb shell su debugfs -R stat /Android/data/com.xxx/files /dev/block/by-name/userdatadebugfs能直接讀 Ext4 的 inode 信息包括鏈接數(shù)、塊指針、時(shí)間戳。如果看到Inode checksum error或者Block bitmap differences那基本可以確定是文件系統(tǒng)損壞需要用e2fsck修復(fù)。注意e2fsck必須在卸載分區(qū)的情況下運(yùn)行Android 上通常只能在 recovery 模式下操作。直接對掛載中的/data跑 e2fsck 是極度危險(xiǎn)的可能造成更大范圍的數(shù)據(jù)損壞。3.4 常用排查命令速查表排查目標(biāo)命令關(guān)鍵輸出FUSE 掛載狀態(tài)mount | grep fuse是否有/storage/emulated掛載點(diǎn)SELinux 標(biāo)簽ls -lZ path是否unlabeled真實(shí)路徑標(biāo)簽ls -lZ /data/media/0/...對比 FUSE 層差異內(nèi)核報(bào)錯(cuò)dmesg | grep -i ext4inode/block 錯(cuò)誤AVC 拒絕dmesg | grep avc哪個(gè)域被拒絕inode 狀態(tài)debugfs -R stat path鏈接數(shù)、校驗(yàn)和刷盤sync強(qiáng)制臟頁落盤這張表我建議直接存下來下次遇到類似問題按順序過一遍能省很多時(shí)間。4. 完整排查流程與實(shí)操記錄4.1 第一步確認(rèn)現(xiàn)象并收集現(xiàn)場信息拿到問題設(shè)備后我做的第一件事不是急著修而是完整記錄現(xiàn)場。因?yàn)橐坏┠汩_始 restorecon 或者重啟原始狀態(tài)就沒了后面再想復(fù)現(xiàn)就難了。我記錄的信息包括mount完整輸出特別是/storage和/data相關(guān)行。ls -lZ對問題目錄和其父目錄的輸出。dmesg最近 500 行重點(diǎn)看avc、ext4、fuse。logcat里 App 報(bào)錯(cuò)前后的日志。設(shè)備是否經(jīng)歷過異常斷電、強(qiáng)制重啟、OTA 升級。這一步看起來繁瑣但90% 的排查效率提升都來自現(xiàn)場信息的完整性。我見過太多人一上來就 restorecon結(jié)果問題暫時(shí)好了過兩天又復(fù)發(fā)因?yàn)楦蚋緵]找到。4.2 第二步分層驗(yàn)證縮小問題范圍收集完信息后按下面的順序逐層驗(yàn)證Ext4 層/data/media/0/...能否正常讀寫標(biāo)簽是否正常如果這層就有問題直接走 e2fsck 流程。FUSE 層/storage/emulated/0/...和真實(shí)路徑是否一致如果不一致嘗試重新掛載 FUSE。SELinux 層dmesg | grep avc有沒有拒絕記錄如果有是哪個(gè)域訪問哪個(gè)標(biāo)簽被拒App 層App 用的路徑是/storage/emulated/0還是content://URI如果是后者還要查 FileProvider 配置。我這次的情況是Ext4 層正常FUSE 層標(biāo)簽丟失SELinux 層大量avc denied。所以問題鎖定在 FUSE 掛載狀態(tài)異常。4.3 第三步修復(fù) FUSE 掛載與 SELinux 標(biāo)簽修復(fù)分兩步走。第一步是重建 FUSE 掛載adb shell su # 停止 media 相關(guān)服務(wù) stop media # 重新觸發(fā)掛載不同 Android 版本命令略有差異 start media # 或者直接重啟 sdcard 服務(wù) setprop ctl.restart sdcard第二步是恢復(fù) SELinux 標(biāo)簽adb shell su restorecon -R -v /data/media/0/Android/data/com.xxx # 驗(yàn)證 ls -lZ /data/media/0/Android/data/com.xxx ls -lZ /storage/emulated/0/Android/data/com.xxx如果兩步都成功/storage/emulated/0下的標(biāo)簽應(yīng)該和真實(shí)路徑一致了。我實(shí)測下來重啟media服務(wù)后FUSE 會(huì)重新讀取底層標(biāo)簽之前unlabeled的目錄自動(dòng)恢復(fù)成media_rw_data_file。4.4 第四步驗(yàn)證與回歸測試修復(fù)后不能只看標(biāo)簽還要做實(shí)際讀寫驗(yàn)證# 用 App 的 uid 模擬訪問 adb shell su app_uid -c touch /storage/emulated/0/Android/data/com.xxx/files/test.txt adb shell su app_uid -c ls -l /storage/emulated/0/Android/data/com.xxx/files/如果 App 能正常創(chuàng)建和讀取文件說明權(quán)限鏈路通了。然后再跑一遍 App 的下載和預(yù)覽功能確認(rèn)業(yè)務(wù)層面也恢復(fù)。這里有個(gè)經(jīng)驗(yàn)修復(fù)后一定要做一次異常斷電模擬。因?yàn)槿绻蚴撬⒈P時(shí)機(jī)問題不模擬斷電你根本不知道會(huì)不會(huì)復(fù)發(fā)。我一般用adb shell sync后直接強(qiáng)制重啟看標(biāo)簽是否還能保持。5. 常見問題與避坑指南5.1 為什么 restorecon 有時(shí)候沒效果這是被問得最多的問題。restorecon 沒效果通常有三個(gè)原因?qū)?FUSE 路徑操作/storage/emulated/0是 FUSE 視圖restorecon 對它無效必須對/data/media/0操作。file_contexts 缺失規(guī)則如果設(shè)備的file_contexts里沒有對應(yīng)路徑的規(guī)則restorecon 會(huì)跳過或者打成unlabeled。這種情況需要檢查/system/etc/selinux/下的策略文件。底層 inode 損壞Ext4 inode 壞了restorecon 讀不到屬性自然也無法設(shè)置標(biāo)簽。5.2Operation not permitted的幾種可能chmod或restorecon報(bào)Operation not permitted不一定是權(quán)限不夠還可能是SELinux enforcing 攔截看avc denied。文件系統(tǒng)掛載為ro只讀。FUSE 層不支持 chmod 操作FUSE 默認(rèn)可能忽略權(quán)限變更。文件被 immutable 屬性鎖定lsattr查看。我這次就是 SELinux 攔截 FUSE 不支持 chmod 的組合。解決方式是先恢復(fù)標(biāo)簽再讓 App 通過正確的 API 訪問而不是直接 chmod。5.3 異常斷電后數(shù)據(jù)丟失的預(yù)防如果你經(jīng)常遇到異常斷電后文件損壞可以從這幾個(gè)方面預(yù)防App 寫入關(guān)鍵數(shù)據(jù)后主動(dòng)調(diào)用fsync()而不是依賴系統(tǒng)sync。使用AtomicFile或者先寫臨時(shí)文件再 rename 的方式避免半寫狀態(tài)。系統(tǒng)層面確保 FUSE 掛載在開機(jī)時(shí)正確重建可以在init.rc里加掛載檢查。5.4 常見問題速查表現(xiàn)象可能原因解決方向目錄顯示unlabeled標(biāo)簽丟失/FUSE 異常restorecon 重啟 mediachmod報(bào) not permittedSELinux/FUSE/ro查 avc、查掛載參數(shù)文件存在但打不開inode 未落盤sync 檢查 Ext4App 讀不到下載文件路徑或 URI 錯(cuò)誤查 FileProvider 配置重啟后問題復(fù)發(fā)根因未解決查刷盤時(shí)機(jī)和掛載邏輯restorecon 無效路徑錯(cuò)誤/規(guī)則缺失對真實(shí)路徑操作查策略5.5 幾個(gè)我踩過的坑第一個(gè)坑直接對/storage/emulated/0跑 e2fsck。這是絕對錯(cuò)誤的FUSE 路徑根本不是塊設(shè)備e2fsck 會(huì)直接報(bào)錯(cuò)嚴(yán)重時(shí)可能影響掛載狀態(tài)。正確做法是對/dev/block/by-name/userdata操作而且必須在卸載狀態(tài)下。第二個(gè)坑忽略dmesg里的 avc 日志。很多人只看 logcat但 SELinux 拒絕是記在內(nèi)核日志里的logcat里往往只有一句籠統(tǒng)的Permission denied。養(yǎng)成dmesg | grep avc的習(xí)慣能省很多猜測。第三個(gè)坑restorecon 后不驗(yàn)證真實(shí)路徑。有時(shí)候 FUSE 層有緩存你看到/storage/emulated/0標(biāo)簽恢復(fù)了但真實(shí)路徑還是舊的。一定要兩邊都ls -lZ對比。6. 從根因出發(fā)的長期優(yōu)化建議6.1 針對 App 開發(fā)者的存儲(chǔ)實(shí)踐如果你是在開發(fā) App能做的優(yōu)化其實(shí)很多。首先不要硬編碼/storage/emulated/0路徑用Context.getExternalFilesDir()或者M(jìn)ediaStoreAPI這樣系統(tǒng)會(huì)幫你處理路徑和權(quán)限差異。其次寫入后主動(dòng) fsync尤其是配置文件、數(shù)據(jù)庫這類關(guān)鍵數(shù)據(jù)。第三處理unlabeled異常在讀取文件前先檢查可讀性失敗時(shí)給出友好提示而不是直接崩潰。6.2 針對系統(tǒng)定制的 SELinux 策略調(diào)整如果你在做 ROM 定制遇到頻繁的unlabeled問題可以檢查file_contexts是否覆蓋了所有自定義路徑。新增目錄時(shí)記得同步更新策略文件否則新目錄第一次創(chuàng)建時(shí)就會(huì)打成unlabeled。另外restorecon的觸發(fā)時(shí)機(jī)也很重要建議在init階段對關(guān)鍵目錄做一次全量恢復(fù)。6.3 監(jiān)控與預(yù)警機(jī)制對于量產(chǎn)設(shè)備可以加一個(gè)開機(jī)自檢腳本檢查關(guān)鍵目錄的 SELinux 標(biāo)簽發(fā)現(xiàn)unlabeled就自動(dòng) restorecon 并上報(bào)日志。這樣能把問題消滅在用戶感知之前。我見過一些廠商就是這么做的效果不錯(cuò)。6.4 我個(gè)人的經(jīng)驗(yàn)總結(jié)折騰完這一輪我最大的體會(huì)是Android 存儲(chǔ)問題從來不是單點(diǎn)問題。一個(gè)unlabeled背后可能是 FUSE 掛載、SELinux 策略、Ext4 刷盤三個(gè)層面的連鎖反應(yīng)。排查時(shí)一定要有分層思維從底層往上逐層驗(yàn)證而不是一上來就試各種偏方。另外現(xiàn)場信息比任何經(jīng)驗(yàn)都值錢。我這次能快速定位靠的就是第一時(shí)間完整記錄了 mount、ls -lZ、dmesg 三件套。如果當(dāng)時(shí)手快先 restorecon 了后面根本沒法分析根因。最后分享一個(gè)小技巧如果你經(jīng)常需要排查這類問題可以寫一個(gè) shell 腳本把上面那些命令打包成一鍵收集輸出到一個(gè)文本文件里。下次遇到問題先跑腳本再分析效率能提升好幾倍。這個(gè)腳本我用了兩年多幾乎每次都能幫我快速縮小范圍。