瘦身的下一步：不是再拔 app，而是壓縮唯讀分區
把用不到的預載 app 移除之後，工業 Android 還有沒有空間可以再省？有——而且方向不同。Android 的 system、system_ext、product 這些分區是唯讀的：開機後只會被讀、不會被寫。唯讀的東西，最適合用「壓縮唯讀檔案系統」來存。
這正是 erofs（Enhanced Read-Only File System）的用途。把這些分區從 ext4 換成 erofs，內容在 build 時就被壓好，裝置讀取時即時解壓。對唯讀分區來說，這幾乎是「免費的空間」。
可行性門檻比想像低
很多人以為換檔案系統要動 kernel、風險很高。實務上，多數現代 Android 裝置的 kernel 已經內建 erofs 支援（含解壓演算法）。只要確認 kernel 設定有開、build 工具鏈支援，就能在不重編 kernel 的前提下產出 erofs 映像。少了「改 kernel」這關，整件事的風險就低很多。
設定上也很單純：在板級設定把對應分區的檔案系統型態指定為 erofs、選一個壓縮器（壓縮率與解壓 CPU 的取捨），重建映像即可。可逆、可逐分區規劃、ext4 與 erofs 混用也沒問題——但要記得：部署時仍須確保該次映像組合中的分區與其驗證資料一致（下一節會展開）。
實測：唯讀分區再省約四成
在「已移除無用 app」的精簡基礎上，把三個唯讀系統分區轉成 erofs，整體再縮小約 40%。要強調的是這個四成是疊加的：app 移除先讓內容變少，erofs 再把剩下的內容壓縮一次。對儲存吃緊、或想留更多空間給資料與日誌的工業設備來說，這是很實在的回收；連帶整包映像更小，也有利於遠端更新。
代價只有「讀取時即時解壓」的 CPU 成本——以現代 SoC 與輕量壓縮演算法來說，這在實務上幾乎感覺不到。
真正的一課：檔案系統不能只換一半
這趟最值得記下的，不是省了多少，而是怎麼把它安全地部署上去。
現代 Android 走 Verified Boot（AVB）與 A/B 雙槽：開機時，系統會用一份「驗證中繼資料」去核對每個分區的內容是否與簽章一致。換檔案系統型態，等於把分區的內容與其驗證描述全部改變——這意味著分區本身、它的驗證中繼資料、開機映像，必須當成「一整套」一起更新。
如果只替換其中幾個分區、卻沒有同步更新對應的驗證中繼資料與開機映像，「內容與驗證對不上」，裝置就可能無法通過開機驗證、進而無法正常啟動。換句話說：fs 型態變更是一個「整包一致」的操作，不是只替換單一分區就能安全完成的變更。
正確的做法，是用一份「整套一致」的映像去部署——也就是工業設備出廠／現場全量燒寫本來就會走的路徑。在那個路徑下，分區、驗證中繼資料、開機映像一次到位、彼此一致，erofs 就能順利掛載、正常開機。
不是每個分區都一定能轉
還有一個務實提醒：同一台設備的不同分區，可能由不同版本的 build 工具鏈產生。較新的工具支援 erofs，較舊的可能還不支援。遇到這種情況，能轉的先轉、不能轉的維持 ext4（兩者混用沒問題），其餘留待工具鏈升級後再處理。把確定有效、風險可控的先落地，是比「一次到位」更穩的做法。
結論：省空間要實在，部署要一致
erofs 對工業 Android 是一個高 CP 值的空間優化：唯讀分區再省約四成、多半不必動 kernel、可逆可混用。但它也提醒我們一件容易被忽略的事——在 Verified Boot 的世界裡，改檔案系統型態是「整套映像」的工程，不是「刷個分區」的捷徑。把它當成整包一致部署來規劃，省下來的空間才拿得到、裝置也才開得起來。
這正是 App 底下那層平台工程的價值：知道哪裡能省、知道怎麼量、也知道怎麼把改動安全、一致地送上裝置。如果你的工業 Android 裝置正面臨系統映像過大、OTA 成本偏高，或需要評估唯讀分區瘦身策略，CoreEdge Lab 可以協助從分區配置、build 參數、AVB 驗證到部署流程一起檢查，找出安全可落地的優化空間。