appops 使用避坑指南：五個我踩過才知道的設定陷阱
appops 是什麼
appops 是一款專門對抗 Android 系統權限管理不足的工具——它能讓你比系統設定更細地控制每個 App 的每項權限。系統設定面板只有「允許/拒絕」兩個按鈕，但 appops 給你四種狀態可選：除了允許和拒絕，還有「忽略」和「僅在使用期間允許」。這意味著面對那種「不給定位就不讓用」的流氓應用，你可以把定位權限設為忽略——應用以為自己拿到了權限照樣運行，但實際上只拿到空數據，根本摸不到你的真實位置。
appops 的開發者是 Xingchen & Rikka，兩位在 Android 開源社區頗有名氣的作者，他們之前做過 Shizuku、Storage Isolation 等工具，所以 appops 不是什麼小作坊作品，而是紮紮實實利用了 Android 系統隱藏的 appops API 來運作的。目前最新版本 9.0.7，安裝包只有 9.86M，免 Root 也能用 ADb 激活 Shizuku 模式，門檻已經降得很低。
安裝
appops 的安裝本身不複雜，但激活方式直接決定了你能用哪些功能，這一點第一次裝的時候很容易隨便選一個就結果後面功能用不了。
首先，從 appops下載 拿到安裝包後直接點擊安裝，Android 會提示「未知來源」，放行即可——這是所有第三方 APK 都會遇到的，沒什麼特別。安裝完打開 appops，它會引導你選擇激活方式：有 Shizuku 模式、ADB 模式、Root 模式和 DPM 託管模式四種。第一次接觸的話我強烈建議先試 ADB 激活 Shizuku，因為 Root 不是每台設備都有，而 ADB 激活的 Shizuku 能覆蓋 90% 的常用功能，包括跨使用者讀取和設置 appops。
ADB 激活的具體操作是：打開手機開發者選項裡的「USB 除錯」，用數據線連電腦，在手機上彈框點允許，然後在電腦端跑一條 adb 命令就能完成。激活過程 appops 會一步一步引導，不用自己寫代碼。
需要注意的是，有些功能只有 Root 激活才能用，比如剪貼板監視（即時彈 Toast 提示哪個 App 在讀剪貼板）。ADB 激活的 Shizuku 雖然能用 READ_CLIPBOARD appops 來忽略剪貼板讀取，但監視功能確實用不了，這個要在激活前就有心理預期，別激活完發現剪貼板監視灰著就以為軟體壞了。
坑一：把「拒絕」當成「忽略」的替代，結果 App 直接崩
這是我踩的第一個坑，也是最常見的。appops 給了四種權限狀態，但我剛開始看都沒看說明，以為拒絕就是最狠的方式，把不想給權限的 App 一律設成拒絕——結果好幾個應用打開就閃退，或者彈一個「權限被拒絕，無法使用」的對話框然後卡死。
後來才搞清楚，拒絕（底層 mode = force-stop）是系統層面明確告訴應用「這項權限你沒有」，絕大多數應用檢測到這個返回值後會停止運行或反覆彈窗。而忽略（mode = ignore）就陰陽得很——系統返回空數據，但權限狀態顯示為允許，應用以為自己拿到了數據，只是數據剛好為空而已。
解法很簡單：除了你確定完全不想讓某個 App 擁有這個能力（比如永不讓某個 App 碰相機），其他情況一律優先考慮忽略。那種「不給權限就不讓用」的流氓應用，正是忽略模式的殺手級應用場景。我現在的策略是：確實需要才能正常運行 → 允許；不想給但不給也不退出 → 忽略；不想給且即使退出也無所謂 → 拒絕。
坑二：主使用者改了權限，分身應用裡沒反應，以為設定沒生效
之前用工作資料夾裝了個微信分身，想在主使用者裡通過 appops 把微信的定位權限設為忽略，結果進去工作資料夾打開微信，定位依然正常——當時以為 Shizuku 跨使用者功能壞了，折騰了好半天。
其實這根本不是 bug，是 Android 多使用者架構的設計如此。每個使用者（包括主使用者、工作資料夾、子賬號、分身應用）有獨立的 Linux uid 範圍，appops 設定也是各自獨立存儲的。主使用者裡 appops 的設定只影響主使用者的應用，工作資料夾裡的同一個應用有完全獨立的一套 appops 設定——你得進去工作資料夾的 appops 裡單獨改，或者在主使用者的 appops 裡通過 Shizuku 的跨使用者功能找到工作資料夾裡的那個應用再改一次。
解法：要改分身應用或工作資料夾裡的應用權限，要麼在對應使用者裡也裝一個 appops 獨立管理（更直觀），要麼確保主使用者的 appops 能看到其他使用者的應用列表，點進去那個應用單獨改。兩套設定互不幹擾是設計不是 bug，知道這一點就不會困惑了。
坑三：把存儲權限設為忽略後，應用無法保存文件
存儲權限是另一個容易踩的坑。我之前把一個購物 App 的 READ_EXTERNAL_STORAGE 設為忽略，目的是不讓它掃描 DCIM 和 Download 目錄——結果發現這個 App 的圖片快取也寫不進去了，商品圖片全是空白。
原因是 appops 的存儲權限忽略模式，會讓應用對外部存儲的所有讀寫操作都返回空或失敗，不只是掃描公共目錄這一件事。Android 的存儲權限本身在不同版本上行為差異就很大（Android 10 以前基本全開，10 開始 Scoped Storage，11+ 進一步收緊），appops 在這之上再加一層忽略，等於直接阻斷了應用對外部存儲的所有訪問。
解法：存儲權限不要一刀切地設為忽略。社交、娛樂類 App 可以設忽略（它們沒理由碰你的公共目錄），但拍照/錄影 App、下載器、文件管理器這些確實需要寫入存儲的應用，要麼設允許，要麼設「僅在使用期間允許」——只有當你主動打開它的時候才給它存儲權限，後台跑的時候自動收走。
坑四：以為 Shizuku 激活後萬事大吉，結果剪貼板監視用不了
appops 的剪貼板保護功能分兩層：一層是對 READ_CLIPBOARD appops 設忽略（讓應用讀到空剪貼板），這一層 ADB 激活的 Shizuku 就能用；但另一層是剪貼板監視——每當有應用讀寫剪貼板時彈 Toast 提示你哪個 App 在讀——這一層只有 Root 激活的 Shizuku 才能開啟。
我當時 ADB 激活完就去找剪貼板監視的開關，發現灰著點不動，以為自己哪步操作錯了，重新激活了好幾次還是一樣。後來才知道這是硬體限制——ADB 激活的 Shizuku 沒有足夠的系統級權限來註冊剪貼板監聽服務，只有 Root 權限才能做到。
解法：如果只有 ADB 激活的 Shizuku，就專注用 READ_CLIPBOARD 的忽略模式來保護隱私，效果其實一樣好——購物 App、社交 App、遊戲這些默認都設忽略，只給輸入法、瀏覽器、筆記 App 這幾個確實需要貼上功能的設允許。至於想先「偵察」哪些 App 在偷讀剪貼板再動手的話，得 Root 才行。
坑五：系統權限面板的設定和 appops 衝突，兩邊改了互相覆蓋
Android 10 之後系統權限面板加了「僅在使用期間允許」和「始終允許」的選項，但 appops 裡也有一個「僅在使用期間允許」的狀態——我曾經在系統面板裡把某個 App 的位置權限設為「僅在使用期間允許」，然後在 appops 裡又設了「忽略」，結果發現行為很混亂。
實際上系統權限面板的設定和 appops 底層的 mode 是兩層獨立的控制：系統面板控制的是 runtime permission 的 grant/deny，appops 控制的是系統隱藏的 appops 操作行為。系統面板設了「拒絕」但 appops 設了「忽略」，應用看到的是權限被拒絕；反過來系統面板設了「允許」但 appops 設了「忽略」，應用以為有權限但拿到空數據。兩個層級同時改很容易產生預料之外的組合效果。
解法：既然裝了 appops，就把權限管控這件事統一交給 appops，不要在系統設定面板裡再改同一個權限。appops 的四種狀態覆蓋了系統面板的所有選項，而且更細緻。系統面板只留給那些 appops 沒辦法控制的系統級設定（比如通知權限），其他一律在 appops 裡搞定。
防坑清單
最後整理一份速查清單，下次設定 appops 之前對照一下：
- 權限狀態選擇：除非確定要讓 App 退出，否則永遠先考慮「忽略」而不是「拒絕」
- 多使用者隔離：主使用者改了不等於分身也生效，各使用者的 appops 設定完全獨立
- 存儲權限：別一刀切設忽略，拍照/下載/文件管理器這類應用要區別對待
- 剪貼板監視：ADB 激活用不了監視功能，只用忽略模式保護也夠了
- 不要雙層管控：裝了 appops 就不要在系統面板裡改同一項權限，兩邊改容易衝突
總結來說，appops 是個強大的工具，但強大的代價是概念多、設定組合複雜。我踩過這些坑之後，現在的設定流程已經很順了：先看每個 App 的權限請求清單，按「確實需要 → 允許、不想給但不想讓它崩 → 忽略、完全不想給 → 拒絕」的策略逐个過一遍，存儲和位置這兩項敏感權限再額外檢查有沒有設錯。知道這些坑之後，這軟體其實相當省心。
本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。
