需要强调一件事，在代码意义上，AppOps自从在Jelly Bean MR2出现后从来就没有被移除，而且，移除它几乎是不可能的。达成AppOps功能所需要的大量函数(检测谁触发某条规则，报告给AppOps管理处/执行当前的AppOps策略等)耦合在Android的各个方面，它们才是本体。

我觉得在媒体上普遍出现“移除”字眼的原因：

• 站在媒体希望增加点击量的角度，你喜欢用“移除”还是“关闭入口”？而且它可以有理由“移除入口导致的普遍无法使用相当于禁用”。
  
  
• 站在eff(电子前哨基金会)的角度，用户能否拥有自己设备的控制权可能是个道德问题，于是“关闭一个未完成，但有助于加强用户权力功能的入口”自然大逆不道。http://zh.wikipedia.org/wiki/电子前哨基金会

实际上，到目前为止Google确实不希望最终用户使用AppOps，它认为AppOps应该是个测试用的工具：
https://plus.google.com/+DannyHolyoake/posts/FkfBxA5i3iG

但我也不打算把它和“Google是最大的广告商”，“或是Google在Android加入AppOps的本意不是为了推出一个隐私保护工具”联想在一起：

• AppOps不能阻止设备追踪(通过IMEI，MAC，Android ID等信息制作设备唯一识别符号)，所以它不会损害广告商的利益，而且我们也知道在排除内地的Android主战场，应用程序以及广告/追踪SDK将被迫使用AdID作为唯一的设备识别符。
  
  
• Kitkat的AppOps变强了，4.3时代的数个bug改正了。

用过AppOps的人会注意到，它还达不到iOS6+的privacy菜单那样完备：

默认地，全局禁止使用所有相关的敏感操作，并在应用程序第一次使用时强制征求操作者意见。

我觉得在众多可能阻止AppOps转正的理由中，它是最重要的。

------ 以下是技术细节 ------

目前已知的进入4.4.2的AppOps的方法：

• 利用Xposed [Xposed][MOD][1.5] AppOpsXposed，我用这个方法，便于卸载，且随时可以迁移到Xprivacy
  
  
• 用baksmali反编译Settings app(Settings.apk)，改两处地方（对应下文源代码patch，使其无效化）[ How-to ] Enable App Ops again in 4.4.2 / KOT49H
  
  
• 自行修改Android源代码并编译(我试了一下，最费时间的反倒是搭建开发环境和下载源代码)

这些方法都需要改动/system分区，意味着解锁bootloader

Google一直在关闭AppOps的入口，试图隐藏它：

1.  4.3刚发布时，Settings App本身已经包含了AppOps的控制窗口，也就是一个叫做AppOpsSummary的Activity，Settings的界面本身不提供进入它的途径，但也没有别的限制。这个时候很进入AppOpsSummary，只需要随便找一个阿猫阿狗发个Intent就行。

2.  接下来呢，有一天Google做了手脚，在Settings app的Manifest中，把AppOpsSummary Activity标注为"enabled=false"，第一种方法失效。

3.  然后，有人(可能是XDA-developers论坛的谁)发现了这种办法：

启动Settings中的一个Activity(不需要是AppOpsSummary)，然后用它来展示构造整个AppOps界面的Fragment

教你如何打开android4.3和4.4中隐藏的AppOps

4. 直到AOSP Android 4.4.2的一个patch，让第二个方法失效。使得目前无法不解锁bootloader(从而改动/system分区)而进入AppOps。

该patch的源代码可以在这里查看：
https://android.googlesource.com/platform/packages/apps/Settings/+/37f06a4%5E%21/#F0