App Ops 修改的是 appops 还是系统运行时权限

两层独立的系统

Android 的"权限控制"实际上由两个独立的系统构成：

1. 运行时权限（Runtime Permission）：用户在系统弹窗里授予的"相机""麦克风""定位"等权限，由 PackageManager 管理，系统设置面板可以修改
2. appops（Application Operations）：Android 内部的应用操作行为层，由 AppOpsService 管理，系统设置面板不开放修改入口

App Ops 操作的是第二层——appops 设置。它不直接操作运行时权限，虽然在某些工作模式下会间接影响运行时权限的标志位。

为什么 App Ops 界面里叫"权限"

为了降低使用门槛，App Ops 在界面和帮助文档中统一把 appops 操作称为"权限"。但需要记住这只是一个简化说法。

App Ops 应用自身也明确声明：

App Ops 实际修改的是"应用操作"而非"权限"，但为了降低难度将其称为"权限"。App Ops 应用不可以直接操作"权限"，请不要误解。

两层系统如何协同

当应用尝试执行某个操作时，系统会同时检查：

1. 该操作对应的运行时权限是否已授予（PackageManager 查询）
2. 该操作对应的 appops 设置是否为允许（AppOpsService 查询）

两层都通过，应用才能真正执行操作。任一环节不通过，应用要么收到错误（运行时权限被拒），要么收到空白数据（appops 被设为忽略）。

为什么搞懂这一点很重要

这直接决定了 App Ops 权限设置在你的设备上是否生效：

• Android 11+：系统会在特定时机（如应用安装后）自动把 appops 设置重置为与运行时权限一致的状态。如果你在 App Ops 里设了"运行时权限允许，但 appops 忽略"，系统可能一键把它改回去
• 只有 uid mode 设为 ignore 同时运行时权限设为 allowed 才能正确保持系统不主动重置
• 这也是 App Ops v5.0.0 重写逻辑的根本原因——早期版本只改 package mode，完全没考虑 uid mode 和 permission flags

详见 Android 版本差异 和 权限自动恢复问题。