App Ops 在不同 Android 版本上的行为差异总览

核心结论

App Ops 能修改的 appops 权限范围完全取决于你的 Android 系统版本。 版本越高，App Ops 能控制的权限越多，行为也越复杂。别问"为什么 App Ops 里找不到某某权限"——先看你的系统版本支持不支持。

各版本关键差异

Android 6 - Android 9

特点：appops 行为相对简单，uid mode 和 package mode 概念已存在但 App Ops 早期版本没正确处理。

系统拒绝权限时写入 uid mode = ignore（仅对 target 23 以下的应用）
系统允许权限时写入 uid mode = allow
尚未设置时 uid mode 默认 = allow
App Ops v5.0.0 之前只改 package mode，对 target 23 以下应用的权限设置会失效（因为系统已写入 uid mode = ignore 优先级更高）

Android 10

关键变化：引入 foreground 状态（仅在使用期间允许），系统面板出现三档权限选择。

系统新增"仅在使用期间允许"选项，写入 uid mode = foreground
系统拒绝权限时写入 uid mode = ignore（变化：之前只对 target 23 以下）
uid mode 优先级高于 package mode 的问题开始暴露：一旦用户在系统设置里把权限改为拒绝或仅在使用期间允许，系统就写入 uid mode，App Ops 无论怎么改 package mode 都被覆盖

Android 11

关键变化：系统引入"每次都询问"选项，并会在特定时机自动重置 appops。

系统新增"每次都询问"选项
系统自动重置：在安装应用后等特定时机，系统会把全部应用的 appops 重设为与运行时权限一致的状态
App Ops v5.0.0 的重大重写就是为了正确跟随这个新行为——但仍然意味着"运行时权限 allow + appops ignore"的组合很容易被系统重置为"运行时权限 ignore"

Android 12+

关键变化：权限模型进一步细化。

引入精确/粗略位置分离（ACCESS_COARSE_LOCATION vs ACCESS_FINE_LOCATION）
Android 13 引入 POST_NOTIFICATIONS 运行时权限
Android 13 拆分媒体权限（READ_MEDIA_IMAGES / AUDIO / VIDEO）
Android 14 对 POST_NOTIFICATIONS 增加更细的前台服务通知控制

系统会重置 appops 的场景

Android 11+ 下以下场景会触发系统 appops 重置：

应用安装后：系统把新安装应用的 appops 重置为默认值
运行时权限状态变化后：如果你在系统设置里改了运行时权限，系统可能重设对应的 appops
厂商定制 ROM：部分厂商（如 MIUI）在系统更新、清理等操作后会重置 appops

这就是为什么 App Ops 里改好的权限过一段时间自己变回去了——不是 App Ops 的 bug，是 Android 系统设计使然。

版本升级带来的问题

从低版本 Android 升级到高版本时：

系统的权限设置会被保留（包括系统面板里设的 uid mode）
这意味着 Android 10 发布后，大量从 Android 9 升级的设备上，App Ops 的 package mode 设置被系统写入的 uid mode 覆盖而无法生效
这个问题在 Android 10 发布近一年后才逐渐暴露出来

App Ops v5.0.0 为什么必须重写

旧版本 App Ops 只改 package mode，完全没考虑 uid mode 和 permission flags。v5.0.0 起同时管理三者，才能正确跟随 Android 系统的实际行为。这也是为什么 v5.0.0 同时移除了纯 root 模式——因为 root 只有 uid 0 的 shell，没有修改 permission flags 的能力。

查系统支持的 appops 范围

App Ops 应用内：设置 → 行为 → 全部权限，可查看当前系统支持的所有 appops。如果某权限你想控制但找不到，说明系统不支持，App Ops 也无能为力。