App Ops 为什么移除了纯 Root 模式

Root 模式曾经存在过

App Ops v5.0.0 之前，确实存在一个"纯 Root 模式"——直接用 su shell 执行系统命令来修改 appops 设置。在 Android 9 及更早版本上，这种方式大致能工作。

但 Android 10 引入了 permission flags 概念，Root 模式的局限暴露无遗，最终被移除。

纯 Root 到底能做什么

很多人对 Root 的能力有误解。实际上 Root 提供的只是：

• 一个 uid 为 0 的 shell 进程
• 可以执行 su 命令切换到 root shell

但在 Android 的沙箱架构下，想要调用 Java 层 API（如修改 permission flags），仅靠 shell 命令是不够的。唯一的办法是通过 app_process 运行 dex 文件，这本质上就是重新实现一遍 Shizuku 做的事情——完全没有意义。

Root 模式缺失的关键能力

App Ops v5.0.0 重写逻辑时发现，想要正确跟随系统行为，必须同时具备：

只有 Shizuku 模式同时具备全部三种能力。Root 模式缺两个，意味着：

• 无法在 Android 11 上正确处理"每次都询问"权限状态
• 无法在系统自动重置 appops 后重新应用正确的 permission flags
• 很多情况下修改看起来"成功"但实际不生效

Shizuku 模式不是 Root 的替代品而是升级

需要澄清一个常见误解：Shizuku 模式 + Root 激活 仍然是存在的，而且是最省心的方案。移除的是纯 Root shell 模式——那种只靠 su 跑命令的方式。

Shizuku 模式本质上是：

• 如果有 Root → Shizuku 自启动服务，App Ops 通过 Binder 调用 Shizuku
• 如果没有 Root → Shizuku 靠 ADB 激活服务，App Ops 通过 Binder 调用 Shizuku

两种激活方式底层用的都是 Shizuku 提供的 Java API，能力完全一样。区别只在于"Shizuku 服务怎么跑起来"。

移除 Root 模式后的好处

对用户来说只有正面影响：

• 行为更正确：Shizuku 模式完整跟随 Android 系统的实际行为
• 功能更统一：不再存在不同模式下功能参差不齐的情况
• 无 Root 也能用：ADB 激活方式覆盖绝大多数用户

如果你曾经在用 Root 模式

App Ops 升级到 v5.0.0+ 后，Root 模式选项会消失。你需要切换到 Shizuku 模式：

• 有 Root → Shizuku + Root 激活（开机自启最省心）
• 无 Root → Shizuku + ADB 激活（每次重启后需要重新激活服务，但权限设置本身不会丢）