用了半年 Dhizuku，從多工具衝突到單一中介的真實體驗

Dhizuku 是什麼

Dhizuku 是一款運行在 Android 上的「中介」應用，它的定位很簡單：一個應用占住 DeviceOwner 身份，其他所有需要這個身份的工具都經由它來申請權限。這個設計解決了安卓系統層面一個長久以來讓玩機黨頭痛的硬規則——設備所有者（DeviceOwner）全機只能有一個，第二個應用嘗試設定必定失敗。

依賴 DeviceOwner 的工具不少：Hail 用來凍結與隱藏應用、Amarok 做無 root 隱藏、OwnDroid 管設備策略與限制、甚至 Aurora Store 在部分受限設備上也要用到它。沒有中介時，這些工具互相排擠，你只能選一個裝。Dhizuku 把這個唯一身份先占住，變成一塊共享資源，其他工具通過它的 API 來請求授權——同一個身份被多工具和平共處，衝突自然消失。對不願意 root、又想在不開 Bootloader 的前提下獲得高級管理能力的玩機黨來說，Dhizuku官網 整理的這份指南是目前最實用的方案之一。

安裝

Dhizuku 的安裝包只有 2.54M，在 Android APK 裡算非常精緻。但它的安裝並不是「下載完點開」這麼簡單——中介應用的核心價值在於激活成為 DeviceOwner，這一步才是真正的門檻。

安裝的前置條件取決於你的設備狀態：如果是全新出廠或已恢復原廠設定的設備，安裝後可以直接走 DPC 方式一鍵激活；如果設備上已經有帳號或多使用者，就需要透過 ADB 命令 dpm set-device-owner 來完成——這裡要特別注意，ADB 激活時設備必須是「乾淨」狀態，不能有任何登入帳號，否則會報 device owner is already set 或條件不滿足的錯誤。部分國產系統（ColorOS、OriginOS）對激活路徑有額外限制，需要查看 Dhizuku下载 的詳細指南。

激活完成後，應用會顯示「已激活」狀態卡，此時所有依賴 DeviceOwner 的工具就能透過 Dhizuku 來請求授權了。之後覆蓋升級新版本不會丟失激活狀態——只要保持同一渠道的簽名一致，直接覆蓋安裝即可，這點官方文檔講得很清楚，我也實際驗證過從 2.8 升到 2.10 的過程完全平穩。

當初為什麼選它

我是被一個很現實的問題逼過來的——Hail 和 OwnDroid 同時想用，結果裝了 OwnDroid 之後 Hail 就報「DeviceOwner 已被佔用」。之前在網上看到過有人說可以把兩個功能拆開用，但凍結應用和設備策略管理這兩件事對我來說是日常刚需，拆來拆去實在麻煩。

Dhizuku 的設計思路讓我一眼就看懂：它不做 Hail、不做 OwnDroid，只做中介。激活一次，之後所有工具都來這裡申請權限。這個定位讓我很放心——中介本身不碰任何管理邏輯，只是把權限分發出去，出了問題也好排查。

哪點越用越順手

最明顯的變化是權限請求的彈窗機制。剛激活的時候，每次裝一個需要 Dhizuku 的工具，都會彈一個授權確認框，點一次之後那個工具就永久生效，再也不會打擾。這個設計一開始沒覺得特別，用了半年之後回頭看，才發現它比我之前想像的要省心得多——手機上至少有五六個工具依賴 Dhizuku，但我幾乎記不起上一次看到授權彈窗是什麼時候。

第二個順手的地方是升級從來沒出過問題。從 2.8 到 2.10，每次覆蓋安裝都是打開商店點更新，完事之後 Hail 凍結一個應用作為驗證，全程不到一分鐘。之前用其他 DeviceOwner 工具的時候，升級經常伴隨著激活狀態丟失、授權重來之類的麻煩，Dhizuku 這點異常穩定。

還有一個小細節：通知欄的常駐通知可以降級為靜默。中介應用需要一個前台服務來保持存活，但那條通知礙眼。在 Android 13 以上的系統裡，可以進入通知渠道設定，把前台服務通知的重要性調到最低，它就乖乖待在通知欄角落不打擾，同時服務也不會被系統回收——這個小設定是我用了三個月之後才發現的，發現之後體驗直接升級。

哪點越用越煩

說到煩的地方，後台服務被殺是唯一讓我真的動過念頭想換的問題。

我的設備是小米 14，MIUI 的後台管理比原生 Android 激進得多。剛激活 Dhizuku 的時候，我沒在意自啟動和電池優化這兩個設定——畢竟之前用過的大部分應用不需要特意調這些。結果第三天早上打開 Hail，直接報「Dhizuku 服務不可用」。當時以為是激活狀態丟了，嚇了一跳，打開 Dhizuku 一看服務確實沒活過來，重啟之後才恢復。

後來按照文檔一步步調：開啟自啟動、電池優化設為「不限制」、把應用鎖在最近任務裡——四項都做了。但 MIUI 在某些系統更新之後會偷偷把這些設定重置回去，我就得重新走一遍。這種「我知道該怎麼修、但系統會不定時幫我復位」的感覺很惱火。

還有一個小問題是授權請求的回調響應速度。大部分時候彈窗是即時出現的，但偶爾（尤其是設備剛從待機狀態喚醒的時候）會延遲一兩秒。這個不影響功能，但用 Hail 快速連續凍結多個應用的時候，體驗會有一點斷裂感。

哪個功能成了每天離不開的

嚴格來說，Dhizuku 本身沒有「功能」——它就是一塊中介。但它讓 Hail 和 OwnDroid 的組合變成了我每天離不開的東西。

早上開機之後，Hail 自動凍結七八個我平時不用但又不想卸載的應用；OwnDroid 透過 Dhizuku 維護著幾條設備策略，比如禁止某些應用自啟動、限制後台行為。這兩個操作加起來不到 10 秒，完成之後手機的記憶體佔用和耗電量明顯降下來。

沒有 Dhizuku 之前，這兩件事我得二選一。現在兩個都能跑，而且中介本身幾乎不耗電——它就是一個等著接請求的後台服務，沒請求的時候什麼都不做。

哪個碰都沒再碰

Amarok。安裝的時候 Dhizuku 也給了它授權，但用了一次就沒再開過——Hail 已經能做到隱藏應用，Amarok 的功能對我來說重疊了。授權就留在那裡沒動，反正不影響什麼，也不佔資源。

觀感修正

剛開始裝 Dhizuku 的時候，我把它當成一個「權限中介工具」——解決問題的手段，本身沒什麼價值。半年用下來，這個判斷被完全推翻了。

Dhizuku 最聰明的地方不在於技術實現（雖然 Binder 轉發這一套做得確實乾淨），而在於它刻意不做任何管理邏輯。它就是一個純粹的權限分發層，Hail 做 Hail 的事、OwnDroid 做 OwnDroid 的事、Dhizuku 什麼都不做，只把 DeviceOwner 的權限包裝成 API 請求回應出去。這種「什麼都不做」的設計反而讓它變得極其穩定——升級不影響狀態、不影響授權記錄、不影響任何依賴它的工具。

我之前低估了這種「純中介」定位的價值，以為它就是一個繞過 DeviceOwner 唯一性限制的權宜之計。現在看來，這才是正確的架構——系統層給了一個唯一身份，應用層就圍繞這個身份做分發，而不是互相搶。

去留結論

不會卸載。Hail 和 OwnDroid 的組合對我來說已經是剛性需求，Dhizuku 是讓這兩個工具能同時跑的唯一可靠方案。

什麼信號出現就該換？如果某天 MIUI 在系統更新之後徹底鎖死了 DeviceOwner 激活路徑，或者 Dhizuku 的維護者宣布停止更新——只有這兩種情況。除此之外，我想不出有什麼理由要換它。半年下來它沒讓我失望過，除了 MIUI 的後台管理偶爾鬧點脾氣，其他時候安靜得像不存在一樣。

一個工具能做到這份上，已經夠好了。

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