SuperSU 進化史——從 Root 標準到被取代的十年旅程

SuperSU 是什麼

SuperSU 是一款 Android 平台的超級用戶權限管理工具——說白了，它就是 Root 之後那個彈窗問你「允許還是拒絕」的 App。但別小看這個彈窗，它的底層跑著一個叫做 su 二進位的守門人，負責攔截每一個請求系統最高權限的應用程式，並按照你設定的規則放行或擋下。

SuperSU 本質上是 Chainfire（知名 Android 開發者）在 Superuser 專案停更後接手維護的後繼者。最早 Superuser 奠定了 Android Root 權限管理的基本模式，SuperSU 在其基礎上大幅擴充，最終成為 Android 2.3 到 9.0 時代最主流的 Root 方案之一。它的核心賣點是：穩定、功能齊全、與主流自訂 ROM 的相容性好。即使你把它轉成系統應用、刷入 Recovery 補丁、或者手動更新 su 二進位，SuperSU 都能保持正常運作。

安裝

SuperSU 的安裝方式直接取決於你目前手機的狀態——是否已經 Root，這是最關鍵的分界點。

如果你還沒有 Root，推薦走 TWRP Recovery 刷入 ZIP 包的路徑。ZIP 包約 6–8 MB，裡面包裝了完整的 su 二進位 + SuperSU下載 App 本體，一次搞定兩件事。流程是：解鎖 Bootloader → 刷入 TWRP Recovery → 進 TWRP 點 Install 選 ZIP → 滑動確認 → 重開機。首次啟動後 SuperSU 會自動偵測 su 二進位狀態，如果提示「需要更新」，選 Continue → Normal 模式即可完成配置。

如果你已經通過其他方式獲得了 Root（例如舊版 ROM 自帶 Root、或者之前刷過其他方案），則可以直接安裝 APK 版本——約 4–6 MB，只安裝 SuperSU 的 Android App 圖形介面，su 二進位沿用系統裡已有的那份。

常見的坑有幾個：ZIP 包版本與 Android 大版本不匹配（例如 Android 9 的 ZIP 不能刷到 Android 10+）會導致啟動卡 Logo 或 Bootloop；部分自訂 ROM 的 SELinux 策略會攔截普通應用位置的 su，這時候需要把 SuperSU 轉成 /system app 才能正常運作；刷入成功但 SuperSU App 打不開時，要手動進 Recovery 檢查 /system/bin/su 或 /system/xbin/su 是否真的存在。

早期版本：從 Superuser 繼承的起點

SuperSU 的起源可以追溯到 Chainfire 在 2013 年左右接手 Superuser 專案。Superuser 是 Android 最早的 Root 權限管理器，但原作者 Chris Short 宣布停更後，社群陷入混亂——有人各種 fork、有人自己改編譯版，權限管理這件事第一次失去了統一的標準。

SuperSU v1.x 系列就是在這個背景下誕生的。Chainfire 做的第一件事不是加新功能，而是把已經亂掉的權限管理邏輯重新穩定下來。v1.0 到 v1.97 之間的更新幾乎全是相容性修復：支援更多裝置的 su 二進位路徑、修正某些 ROM 上授權彈窗閃退的問題、優化與 Superuser 舊配置的遷移邏輯。對當時的使用者來說，SuperSU 最大的賣點不是功能，而是終於有一個靠譜的、有人維護的權限管理器了。

這個階段的版本迭代節奏是快速的——平均兩週一個小版本。Chainfire 在部落格裡寫過，那段時間他主要靠使用者回報的 Bug 清單推進，沒有什麼宏大的功能規劃。這是典型的「補丁驅動」階段：哪裡壞了補哪裡，先讓它穩定跑起來再說。

v2.x 時代：功能擴張與標準地位確立

真正讓 SuperSU 成為行業標竿的是 v2.x 系列，從 v2.0 開始到最後的 v2.82（2017.05.27 發布），前後歷時約四年。這四年裡 SuperSU 從「穩定的替代品」變成了「Android Root 的事實標準」。

v2.0 引入了兩個關鍵功能：多使用者支援和完整的日誌系統。Android 4.2 開始支援多使用者切換，但之前沒有任何權限管理器好好處理過第二個使用者的 Root 請求——SuperSU v2.0 第一個解決了這個問題。日誌系統則讓使用者能回頭看到「哪個 App 什麼時候請求了 Root、被允許還是拒絕」，這對排查問題至關重要。

v2.11 是另一個轉折點。這個版本引入了一個全新的 su 掛載點 /su/bin/su 和配套的 supolicy 工具。為什麼要加這個？因為 Android 5.0 之後 SELinux 變嚴格了，直接往 /system/bin/ 寫 su 經常被策略攔截。Chainfire 的解法是：在啟動早期通過 init.d 腳本掛載一個自訂的 /su 目錄，把 su 放在那裡，繞過 SELinux 的限制。這一招在當時非常聰明，也讓 SuperSU 成功對抗了 Android 5.0–6.0 的 SELinux 收緊浪潮。

v2.50 之後的版本開始主打 Pro 功能：Auto-deny countdown（倒數自動拒絕）、Wake on prompt（待機時彈窗自動喚醒螢幕）、以及更細粒度的權限規則配置。SuperSU官網 對每項 Pro 功能都有獨立的設定頁，允許使用者針對特定 App 單獨覆蓋全域規則。這些功能把 SuperSU 從一個「只要能彈窗就行」的工具變成了一個可以精細調控的權限管理平台。但有意思的是，Chainfire 自己在 v2.60 的更新日誌裡寫道：「Pro 版的功能是為那些真的需要的人準備的，絕大多數用戶用免費版就夠了」——這說明他從來沒打算把 SuperSU 做成一個靠 Pro 版營利的產品，更多是社群驅動的開源專案姿態。

這個階段的迭代節奏明顯放慢了。從 v2.0 到 v2.82，平均每兩到三個月一個版本，而且越往後越大的更新越少、越小的修復越多。Chainfire 的精力開始分散到其他專案（例如 FlashFire），而 SuperSU 的功能也基本觸頂了——對一個權限管理器來說，彈窗、日誌、規則配置、多使用者、SELinux 繞過，能想到的都做了。

終結與遺產

v2.82 發布於 2017 年 5 月，是 SuperSU 最後一個正式版本。此後 Chainfire 宣布淡出 Android 開發圈，SuperSU 進入維護模式。社區曾經出現過幾個非官方的 fork 嘗試接手，但都沒有形成氣候——因為這時候 Magisk 已經開始崛起了。

Magisk 的核心優勢在於「systemless」——不改寫 /system 分區，而是在啟動時通過掛載覆蓋的方式注入 Root 環境。這個設計完美解決了 Android 7.0+ 越來越嚴格的分區完整性檢查（dm-verity），而 SuperSU 基於傳統的 /system/bin/su 寫入方式，在 Android 9.0 之後基本走不通了。2018 年之後，絕大多數自訂 ROM 和 Root 教程都從 SuperSU 切到了 Magisk，SuperSU 成了一個「只在舊設備上還能見到」的遺老。

有趣的是，Chainfire 本人對 Magisk 的態度非常開放——他在 Google+ 上公開表示 Magisk 的 systemless 設計是 Android Root 的正確方向，自己的 SuperSU 是「上一個時代的解法」。這種姿態在技術圈並不常見，多數開發者會本能地捍衛自己的專案，但 Chainfire 選擇了承認技術路線的更迭。

規律與預判

回顧 SuperSU 的十年迭代，我看到兩個明顯的規律。

第一，它一直是被動適應大環境的產物。v1.x 補 Superuser 留下的爛攤子、v2.0 追 Android 4.2 的多使用者、v2.11 應對 Android 5.0 的 SELinux 收緊、v2.50+ 加 Pro 功能留住付費用戶——每一個大版本更新的誘因都是外部環境變化，而不是 Chainfire 自己規劃的功能路線圖。這不是壞事，但說明 SuperSU 從來就不是一個有清晰產品願景的專案，它更像是一個「盡量把當前問題解決好」的務實工程。

第二，功能擴張到一定程度後，架構債會把你拖死。SuperSU 支援從 Android 2.3 到 9.0 將近十年的系統版本，底層同時處理 /system/bin/su、/system/xbin/su、/su/bin/su、/data/adb/su/ 四種不同的安裝路徑，還要兼容不同自訂 ROM 的 SELinux 策略差異。當 Magisk 用一個更乾淨的 systemless 架構出現時，SuperSU 這種「積木式」的設計根本無力競爭——它不是被功能擊敗的，是被歷史包袱壓垮的。

至於預判？SuperSU 已經走到了技術生命週期的盡頭。它不會再有新版本，非官方 fork 也很難有大作為——因為 Magisk 已經佔據了幾乎整個市場。但它的設計思路影響了後繼者：權限彈窗的交互邏輯、日誌與規則配置的分層、su 二進位與 App 的分離架構——Magisk 的權限管理器（Magisk Manager）在很多細節上都能看到 SuperSU 的影子。從這個角度說，SuperSU 沒有消失，它只是換了一種形式活著。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。