做 Android 开发越久越会发现权限体系不是我们平时看到的“允许/拒绝”那么简单。系统设置里的开关只管一部分真正在背后记录每一次调用、控制每一次访问的是一个叫 AppOps 的系统服务。我第一次认真研究它是想做一个权限使用记录工具想搞明白某个应用到底在什么时候偷偷开了摄像头、读了位置结果一打开这个知识缺口就补不完了。这篇文章就是一次围绕 AppOps 学习过程的完整拆解。AppOps 本质上是一套位于“应用权限之上”的管控层它决定了一个应用在拿到权限之后能否真正执行摄像头、录音、定位、读取联系人等敏感操作同时也会记录这些操作发生的时间和频次。系统设置里的“权限使用情况”页面、权限管理器的后台限制底层都是 AppOps 在支撑。这篇文章适合三类人第一类是刚接触 Android Framework、想搞懂权限体系的开发者第二类是正在做隐私合规检测或权限审计工具的人第三类是打算在系统定制、MDM 设备管控方向深入的同学。通读下来你会发现AppOps 不只是几个 API 的拼装它把 Android 的权限模型、Binder 通信、系统服务设计、UID 隔离串成了一条完整的链路值得花时间啃。1. 先说结论AppOps 到底在管什么1.1 一个“权限之上的权限”如果只用一句话概括AppOps 就是 Android 权限体系里的“执行闸门”。正常场景下应用申请权限时要经过权限弹窗用户同意后系统就返回授权。但授权之后应用是否真的可以调用摄像头、录音、读取定位系统还需要一个更细粒度的开关来兜底。AppOpsManager 就是干这个事的。比如你在系统设置里把一个应用的“位置信息”权限切到拒绝表面上看是权限被收回实际上底层往往是 AppOps 里对应位置操作的 op 被设置为 ignore。系统在应用调用LocationManager时会先通过 AppOps 校验这个 op 是否被允许如果被 ignore就直接返回空数据或者抛异常。这就解释了为什么很多应用在权限被拒绝后依然能“正常打开”但拿不到数据。因为权限层面的拒绝最终会落到 AppOps 的操作拦截上。1.2 AppOps 的演进路线AppOps 并不是一步到位的。我在看 AOSP 源码时梳理了一下它的演进Android 4.3 / 4.4 时期AppOps 概念被引入系统内部开始用 op 记录敏感调用但开发者能调用的接口非常有限。Android 7.0 之后AppOpsManager 里的checkOp、noteOp、startOp、setMode这些方法逐渐开放第三方工具开始能做权限使用情况检测。Android 9 / 10 前后系统对权限管理做了大量收紧包可见性、隐藏 API 限制都开始影响 AppOps 的周边功能。Android 10 及以后系统进一步限制后台访问位置等敏感操作很多由 AppOps 直接转为 ignore。Android 12L 引入了MODE_FOREGROUND用于描述“仅前台允许”的状态让管控粒度更细致。在学习的时候不要拿某一版 API 文档去套所有设备。国产 ROM 对 AppOps 的改动更是五花八门后面我会专门说这个坑。1.3 为什么值得单独学习 AppOpsManager很多人觉得系统设置里的“权限使用情况”就是全部了其实那只是 AppOps 记录结果的可视化。真正有价值的是你掌握 AppOps 之后能做什么知道一个应用是否真的调用了某个敏感操作以及上次调用时间。理解系统如何决定“后台执行权限”的开关。在自动化测试里准确控制权限状态。在企业设备管控里主动禁用某些应用的敏感能力。AppOps 直接决定了系统服务的访问入口它比 ActivityManager、PackageManager 更适合做“行为守门员”。学懂了它再回头看待权限申请流程你会发现自己能看到之前看不到的细节。2. 核心细节解析AppOps 的权限模型与 API2.1 从 permission 到 op 的映射机制AppOps 里最核心的概念就是 op也就是一次敏感操作。系统把“读取联系人”“打开摄像头”“发送短信”这些行为抽象成几十个 op每个 op 都有固定的 id 和名称。应用申请一个运行时权限之后系统会把权限转换成对应的 op。比如权限名对应的 opACCESS_FINE_LOCATION精确定位相关 opACCESS_COARSE_LOCATION粗略定位相关 opCAMERA摄像头相关 opRECORD_AUDIO录音相关 opREAD_CONTACTS读取联系人相关 opREAD_PHONE_STATE读取设备信息相关 opREAD_EXTERNAL_STORAGE读取外部存储相关 op这些映射关系在 AOSP 的AppOpsManager.java和permission_flags.xml里都能找到源码实现。你不需要全部背下来但必须建立“权限和 op 是一一映射”的意识否则遇到“明明权限开着却被系统拦截”的情况会一头雾水。2.2 AppOpsManager 的三个核心维度看 AppOps 相关的 API你会发现方法的入参总是围绕三个维度uidLinux 层面应用的身份标识。系统在安装应用时会给每个应用分配一个 uid它决定了应用能访问哪些系统资源。packageName包名。AppOps 校验时通常要同时传入 uid 和包名因为同一个 uid 可能对应多个包尤其是使用 sharedUserId 的场景。op要检查或修改的操作 ID。很多初学框架的人会忽略 uid 维度。实际深挖之后你会发现AppOpsService 内部保存的状态通常以 uid 作为 key包名只是校验用的辅助信息。2.3 四种操作模式allowed、ignored、errored、defaultAppOps 对每个 op 都会保存一个 mode常见的有四类模式含义MODE_ALLOWED允许执行系统正常放行MODE_IGNORED忽略系统直接拒绝操作但不一定会崩MODE_ERRORED错误系统返回 SecurityException应用通常感知最明显MODE_DEFAULT默认继承系统对普通应用的默认策略从实际表现来看ignored 模式比 errored 更“柔和”。很多做过位置权限绕过检查的同学都会发现系统在后台限制位置时应用拿到的回调结果往往是空值而不是异常这其实就是 AppOps 的 ignored 模式在起作用。2.4 如何拿到 AppOpsManager 实例与关键方法在应用代码里获取 AppOpsManager 非常简单val appOps getSystemService(AppOpsManager::class.java)常用方法包括checkOp(op, uid, packageName)只查不记录无论是否发生过调用只判断当前是否允许。noteOp(op, uid, packageName)记录一次操作并检查是否允许。startOp / finishOp适合持续型操作比如摄像头预览、录音操作开始时 start结束后 finish。setMode(op, uid, packageName, mode)设置某个应用、某个 op 的模式。getPackagesForOps(opIds)获取一批 op 的授权记录。queryOps(mode, flags)按模式条件筛选出所有 op 记录Android 10 之后的新 API。unsnoozeOps(op, uid, packageName)把系统临时禁止的 op 状态清掉。方法名字多但核心路数就一个传入 op、uid、包名系统返回这个操作的状态或者改变这个操作的状态。3. 实操过程与核心环节实现3.1 第一步写一个“权限审计器”查看系统里现存的 op 记录我建议你第一步不要急着改任何状态先做一个只读工具把系统里某个应用当前的 op 状态拉出来。这样能直观看到 AppOps 到底保存了什么数据。这里有一个关键前提普通应用到 Android 10 之后getPackagesForOps这类接口能查到的东西非常有限。想要完整实验最省事的途径是使用 AOSP 模拟器并且以 root 权限执行调试。自己编译系统把调试 App 做成系统签名的白名单应用。在 adb shell 里用系统预置的cmd appops命令做验证。如果你只用普通真机调试大概率会发现查不到别的应用的 op 数据这不是代码写错了是系统权限本来就收紧。在可执行的调试环境里一段最简单的只读代码长这样val appOps getSystemService(AppOpsManager::class.java) // 这里的权限检查需要系统签名或特权应用权限 val packageOps appOps.getPackagesForOps( intArrayOf( AppOpsManager.OPSTR_CAMERA, AppOpsManager.OPSTR_RECORD_AUDIO, AppOpsManager.OPSTR_FINE_LOCATION ) ) for (pkgOps in packageOps) { Log.d(AppOpsDemo, package: ${pkgOps.packageName}) for (entry in pkgOps.ops) { Log.d( AppOpsDemo, op${entry.op}, mode${entry.mode}, time${entry.time}, duration${entry.duration} ) } }OpEntry里的time表示最近一次访问时间duration表示最近一次持续操作时长。对做隐私审计来说这两个字段的价值非常高。3.2 第二步动态改变某个 op 的结果如果只是查询你对 AppOps 的理解还停留在表面。我建议在一个可控的测试应用上做一次 setMode 实验。比如你想验证“读取联系人”被 ignore 后应用的表现可以在 adb 环境执行adb shell cmd appops set com.example.test READ_CONTACTS ignore之后打开应用尝试读取联系人你会发现联系人列表可能返回空或者抛出 SecurityException这个异常往往和操作的具体实现有关。在 Java/Kotlin 层面如果是特权应用调用方式类似appOps.setMode( AppOpsManager.OPSTR_READ_CONTACTS, uid, packageName, AppOpsManager.MODE_IGNORED )这里要特别提醒setMode需要系统权限普通应用直接调用会抛出 SecurityException。学习阶段我不建议你在自己没有掌控权的设备上强行反射绕过这既违反系统设计也容易滑向灰色用法。正确的姿势是在自己的 AOSP 模拟器上或者在专门做系统开发的测试机上验证。有一个细节值得记录直接改 AppOps 的 mode 并不会同步修改运行时权限的授权状态。你会发现系统设置里的“联系人权限”可能还是“允许”但应用读取时已经拿不到数据这是 AppOps 层和权限层不完全对齐的经典案例。真正的系统应用在做权限管理时必须同时处理权限状态和 op 状态确保 UI 反馈一致。3.3 第三步监听权限使用通知AppOps 不只是被动记录系统服务在 op 状态变化和访问发生时还会发送通知。早期可以通过AppOpsManager.OnOpChangedListener监听回调注册方式如下val appOps getSystemService(AppOpsManager::class.java) appOps.startWatchingMode( AppOpsManager.OPSTR_CAMERA, packageName, object : AppOpsManager.OnOpChangedListener { override fun onOpChanged(op: String, packageName: String) { Log.d(AppOpsDemo, op $op changed with $packageName) } } )这个方法仍然受系统权限约束但用来做自己应用的调试很合适。实际场景中很多“隐私保险箱”类应用并不是通过 AppOps 监听拿到所有数据的而是结合 Accessibility、UsageStats 等不同通道做行为推断。AppOps 能提供的信号是最底层的有了它判断才会更接近真相。3.4 第四步用 dumpsys 排查 AppOps 数据我最推荐的调试方式其实是 adb 配合 dumpsys。它不需要写代码能快速看到系统内部状态adb shell dumpsys appops这条命令会输出当前设备上所有 uid 的 op 状态、模式、最近访问时间等信息。输出内容又长又杂建议配合 grep 使用adb shell dumpsys appops | grep -A 20 com.example.test还可以先查某个 uid 的概况adb shell dumpsys appops com.example.test在 AOSP 里cmd appops也提供了相关子命令可以先敲adb shell cmd appops help不同 ROM 的 help 输出可能不一样以实际环境为准。日常排查时我通常先执行dumpsys appops找到目标包名再对照系统设置里的“权限使用记录”页面验证结果。如果两边数据不一致基本可以断定是 ROM 对 AppOps 做了修改。4. 常见问题与排查技巧实录4.1 直接调用 AppOpsManager 接口抛 SecurityException这是初学者最容易撞上的问题。很多人照着老文章里的代码写在自己的普通应用里调用setMode、getPackagesForOps运行时直接崩溃。原因很简单AppOps 的系统权限约束非常强。AOSP 框架源码里noteOp、setMode等方法上方都加了RequiresPermission或者调用前有系统身份判断。普通第三方应用不可能拿到这份权限。这不是 Bug是安全设计。如果你只是学习可以在 AOSP 版本对应源码里看AppOpsManager.java的setMode实现会发现内部最终要调用mAppOpsService.setMode而mAppOpsService拿到了Binder.getCallingUid()做校验。4.2 Android 11 之后查不到其他应用的信息很多做权限审计工具的人在 Android 11 上发现PackageManager.getInstalledPackages()返回的结果变少了。这是因为包可见性机制生效。如果工具确实需要在合规前提下查询已安装应用要在 Manifest 里声明queries intent action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent /queries或者申请QUERY_ALL_PACKAGES权限。要注意这个权限本身在部分应用市场审核里是需要申报理由的滥用会导致上架风险。AppOps 学习里最容易忽略的就是“你根本看不到目标应用”所以必须先处理好包可见性再谈 op 数据。4.3 改完模式后系统又自动恢复有些同学会发现在自己的系统应用里把某个 op 改成 ignore过了一段时间它又变回 allowed。这里牵扯到几个可能原因系统在运行时权限状态变化时会同步重置 AppOps 状态。用户重新安装了应用或者清除了应用数据会导致 AppOps 记录被清空。某些 ROM 在应用自启动或省电策略里做了额外干预导致 setMode 被覆盖。碰到这种情况先确认是不是所有设备都复现还是只在特定 ROM 上出现。如果是后者大概率是厂商在 Framework 层改了默认权限管理逻辑。开发阶段不要假设系统完全听你的。4.4 国产 ROM 对 AppOps 的改动差异AppOps 在 AOSP 里是标准实现但国内厂商普遍会做深度定制。比如有的手机会在后台自动拒绝应用被杀后重开的敏感权限有的会把 AppOps 的 ignore 状态直接反映到设置页面用户视角上就是“权限被关闭了”。这种差异不是文档能写完整的只能通过实测总结。我的习惯是拿到新设备先跑一遍dumpsys appops看看默认状态有哪些奇怪的 op 被 set 成 ignore。这些“出厂默认值”里藏着很多厂商的策略也是排查问题的重要线索。4.5 隐藏 API 与反射学习的边界很多深想挖 AppOps 细节的人会去反射ServiceManager.getService(appops)拿到IAppOpsService再调用内部方法。这是学习系统服务结构的有效方式但要注意隐藏 API 限制在 Android 9 之后越来越严格反射不一定每次都能成功。对于学习场景我建议你直接在源码里读IAppOpsService.aidl和AppOpsService.java理解 Binder 那一层的接口设计比在运行时反射绕过限制更安全、更有长期价值。如果你只是想快速验证可以在自己的测试机上配合 root 权限执行命令但不要用这些手段去干扰其他应用。5. AppOps 的实际应用场景与延伸学习建议5.1 权限使用监控与隐私合规检测工具AppOps 最常见的应用场景就是做隐私合规检测。系统设置里的“隐私”页面用的就是 AppOps 数据具体包括哪些应用开过摄像头。哪些应用在后台读取过位置。哪些应用最近访问过麦克风。某次操作的持续时长。如果你想自研一套类似的工具核心思路就是周期性读取AppOpsManager的查询结果并记录信息增量。这个方向既能加深对 AppOps 的理解又能直接落地到合规审计主观价值很高。5.2 自动化测试中控制权限状态做 UI 自动化也要频繁处理权限弹窗。过去很多人选择在测试代码里绕过弹窗或者用 UiAutomator 点击“允许”按钮。如果测试设备是 AOSP 环境直接用cmd appops set预置权限状态更省事adb shell cmd appops set com.example.test CAMERA allow这样在测试启动前就为应用准备好了权限环境避免弹窗干扰脚本执行。想要测“拒绝权限”的场景把 allow 改成 ignore 即可。老的adb shell pm grant只能控制运行时权限但更深一层的 op 控制还是得靠 AppOps 这一套。5.3 系统定制与 MDM 设备管控在企业设备管理、MDM 方案里AppOps 经常被用来做“能力禁用”。比如某台工作设备不希望任何应用打开相机管理员可以通过系统策略把相关 op 强制设为 ignore。这里的实现往往不再由应用层直接调用setMode而是通过DevicePolicyManager的权限策略、AppOpsManager内部的状态同步来联动。Framework 工程师需要看懂从 API 层到 AppOpsService 的数据流才能安全地做策略下发。5.4 从 AppOps 开始解锁整条 Android Framework 学习路径学 AppOps 的收获不只是几个 API它会把很多框架知识点串起来BinderAppOpsManager 最终要调用 system_server 里的服务。进程与 uid每个应用的身份隔离影响 op 状态存储。权限模型Runtime Permission 和 AppOps 的映射关系。系统服务生命周期AppOpsService 的启动、持久化、重置逻辑。安全设计为什么不让第三方应用随便改其他应用的 op。如果你发现自己在看系统设置页的时候开始思考“这个开关底层是哪个 op”“状态是怎么持久化的”说明你已经摸到 Framework 学习的门道了。最后再分享一个小技巧我后来在做项目时发现很多诡异问题其实是“权限和 op 不同步”导致的。当你下一次遇到“设置里权限明明开着但功能就是不可用”的情况先别急着怀疑业务代码用 adb 执行一下dumpsys appops | grep 目标包名看看对应的 op 状态。这个动作两秒做完能替你省下大半天查日志的时间。AppOps 是一个非常值得反复咀嚼的系统服务。它对权限的管控粒度、对访问行为的记录能力、以及和系统其它模块的联动方式理解得越深你对 Android 的全局掌控感就越强。把源码下载下来直接从AppOpsService.java读起比背 API 列表有用得多。