一把私鑰先被交出去了：Android 系統應用，是一套被排好版的特權介面

回顧 2026 年 10 月 19 日，掘金作者 hai_android 發表了一篇不到兩分鐘可讀完的技術文，標題很直白：把 Android App 打包成系統應用。文章給出的一句話結論同樣直白：只有被平臺私鑰簽名的 APK，放到 /system/priv-app/ 目錄下，並在清單裡宣告 android:sharedUserId=“android.uid.system”，才能成為真正的系統應用，取得 READ_PRIVILEGED_PHONE_STATE、MOUNT_UNMOUNT_FILESYSTEMS 這類一般 App 連申請資格都沒有的特權權限。

這類文章通常被歸類為開發者筆記，但換個角度看，它其實攤開了一套被精心設計的介面：Android 把「誰配信任」這個問題，翻譯成了檔案、目錄與指令的排版。

先看那三個檔案。platform.x509.pem 是公鑰憑證，platform.pk8 是私鑰，signapk.jar 是簽名工具，三者都源自 AOSP 源碼樹裡的固定路徑，或者由設備廠商另外交付。文章特別提醒，廠商 ROM 的金鑰檔名可能是 releasekey 或 vendor_xxxx 開頭，必須與設備實際刷入的 ROM 匹配，否則簽名無效。這是整套機制最誠實的地方：它沒有語意、沒有審核流程，只有一把鑰匙對不對得上鎖。與 Google Play 上架那套以政策與審核為核心的信任模型相比，系統應用的信任是被壓縮進一對金鑰檔案裡的，認鑰匙，認的是刷進機身的那份 ROM。

再看流程的排版。作者的方法分三段：先用一般的 jks 金鑰產出僅含 v1 簽名的 release APK，接著用 signapk 重新以 platform 金鑰簽署，最後推進設備。其中有兩個設計上的細節值得停下來看。其一，signapk 預設只產 v1 簽名，這正好符合系統應用的要求，工具的預設值與系統的驗收條件在此對齊，省去開發者的判斷。其二，簽完之後不能再拿 jjs 工具二次簽名，否則會覆蓋掉 platform 簽名；也就是說，這條路的每一步都有先後順序，做錯一步，成果就整個報廢。這種「順序即規範」的特質，和 Shopify 用 checkpoint 設計過的遷移介面有幾分神似：工程問題最終都被排成一套必須逐步核對的清單。

最後是最容易被忽略、也最像介面設計的部分：APK 推進 /system/priv-app/ 之後的三行指令。chmod 644 調整存取權限，chown root:root 指定擁有者，restorecon 重建 SELinux 標籤。作者特別註明「這三步很多人漏」，漏了輕則無法生效，重則被 SELinux 擋在門外。換句話說，一個 App 要被系統承認為自己人，除了簽對鑰匙、放對目錄，還得把檔案的擁有者、權限位元與安全標籤都排回系統預期的樣子。目錄名稱也有講究，要用 applicationId 而非 package 名稱，命名欄位本身就承載了驗收規則。

這篇文章的存在，也說明了 Android 生態裡一個持續的真實需求：ROM 廠商、ODM/OEM 項目與行業定制終端，永遠需要一批預裝、且能取用特權權限的應用。這條路不走應用商店，不走權限彈窗，走的是金鑰與檔案系統。對終端使用者而言，它隱形；對打造設備的人而言，它是整個信任體系的地基。

值得留下一個觀點：Android 把最高等級的信任設計成一個沒有任何視覺元素的介面，只有檔名、路徑與指令。正因為它不可見，寫得清楚的文章才顯得有價值。這篇兩分鐘的筆記之所以被反覆轉載，靠的正是把一套隱形規則排成可以照著做的版面，這與好的介面設計做的是同一件事。