@androidyue
将权限分成权限组这样的设计是有理由的。以下是我的想法：
应用本来就不该获取 imei ，谷歌把 imei 放到“拨打电话”这样的权限组里，并且用户只能整组地拒绝或允许，这样用户就更有底气选择拒绝了。
如果权限控制是以权限而非权限组为单元的话，那些国外应用也有可能“不给读取手机身份就不让用”，而国外用户也会无可奈何地给了读取手机身份的权限。而在以权限组为一个单元的情况下，“拨打电话”这样一个权限组还是比较重要的，即使是小白用户和不注重隐私的用户也会意识到。这样即使不用这个应用会对工作生活造成较大不便，也会有更多的人拒绝此应用，从而促使应用放弃读取 imei 的行为。
当然在国内环境下， bat 等互联网公司的产品的垄断性、不可替代性更强，用户的隐私意识也更差，这样即使是“拨打电话”这样一个权限组，也有很多公司敢“不给权限就不让用”。

可惜没有类似 you-get 这样的软件

@honeycomb “某个 API 事实上涉及到了某个 OP ，但没有插桩”是一种怎样的情况？什么是“事实上涉及到”？为什么这种情况下只能拦截 java 代码，无法拦截原生库？

@honeycomb
我看了安卓关于 runtime permission 的文档，还有其他一些介绍文章，再进行了一些实践，这是我的理解：
runtime permission 需要请求的权限（也就是危险权限）包含于 Android.permission 的权限，而且是以权限组的形式请求的；
AppOps 的权限和 Android.permission 权限互相之间没有包含关系；
runtime permission 需要请求的权限是 AppOps 和 Android.permission 交集的子集；
这三种权限的设定值是相互独立的，在权限检查时是“与”的关系。也就是说，一个应用想获取 imei ，必须在 mainfest 里有读取手机身份的权限，而且获得了 runtime permission 的电话权限，并且 app ops 里的“读取手机状态和身份”权限也允许了。
你说“ Runtime Permission 直接依赖于 AppOps ，所以单个 Runtime Permission 对应一个或多个 OP 项目。”可能在代码实现上是这样，但从我的实践来看这两种权限系统的设定值还是相互独立的。

是的。要知道有名的互联网公司里被爆出有监听、监视用户嫌疑的就只有支付宝一家了。

楼上几位，楼主这明显是要在线播放器而不是本地播放器啊。
同求。

果然还是苹果限制得死， android 上简直防不胜防，即使用上 xprivacy 也没法保证能封堵住所有能获取唯一标识符的途径

@gudong 比如三星自带就有，触宝也有。我用触宝

@honeycomb
再请教一下：
1.如果是旧版应用，则“ Silently fail ”？那旧版应用都获得不了权限了？这与实际使用体验不符吧。
2.xprivacy 对.so 很无力，在很多情况下无法限制其行为，那 AppOps 有这个问题吗？
3.AppOps 能限制应用获取信息到何种程度呢？其程度与 xprivacy 相差大吗？ 比如本机 wifi 模块 mac 、、 android id 等能唯一确定设备的信息，连接的 wifi ssid 等能用于定位的信息， AppOps 能全部封堵住应用对这些信息的获取吗？ 还有已经安装的应用列表、正在运行的程序等信息， AppOps 能限制吗？
xprivacy 稳定版已经两年多没更新了，期间好像一直没出现如 xprivacy 那样强大的权限管理工具，感觉 android 上的权限管理不容乐观啊。

@gudong 很多输入法有剪贴板管理功能，不需要额外的剪贴板辅助应用；只临时中转的话一般不需要分类，粘贴到笔记软件里再分类好了，它们的分类管理功能强大得多

算不上痛点吧，安卓的剪贴板又不是像 windows 一样只能存放一个内容，再复制进去一个前一个就被覆盖掉的。 android 剪贴板可以存好多内容，所以多次复制，再粘贴到笔记软件里就行了。

敢说没有给 google 任何个人信息的网民 都是过于自大了。

@Lentin 总感觉 tor 是个大蜜罐

@Jaspr
@AsherG
@28661
@Sharuru
@honeycomb
我看到 app ops 的权限管理和应用本身的权限列表还是不完全一致，这其中有什么规律呢？比如应用权限列表里有“检索正在运行的应用”这一项，而 appops 里没有，是不是就没有办法禁止该应用检索正在运行的应用了呢？

@honeycomb 我的使用习惯是，不用时关闭数据连接。我不需要所有的后台推送消息（包括 qq 微信）。而我周边的小白用户，他们有些一直开着数据连接，但所需要的推送也只有 qq 和微信（他们装的应用远不止这些，但是需要推送的就这两个）。当然还有很多应用会推送一些他们不需要的无用信息。
还有一些比较会玩安卓的网友，他们也基本只需要 qq 和微信的推送（有些还会有支付宝），而且他们会用 my android tools 禁用其大部分服务，这样就很省电了。
所以说：
1.大部分人需要推送的应用真的很少；
2.即使是需要推送的应用，维持基本的推送功能所需要的电量也不是很多，耗电主要还是由于应用在后台做一些对用户无益的事。
因此没有必要为了省电而让所有推送通过 google 的服务器。
最好的方法当然还是规范化推送，建立一个本地的统一的推送框架，用户可以手动禁止应用除推送以外的后台服务。因为已经标准化了，所以不用再用 my android tools 这种靠猜测、尝试来禁用服务，也不会误杀。应用在后台只有最基本的推送消息功能，也不怎么耗电。
可以类比于 Imap Idle 协议（ http://blog.sina.com.cn/s/blog_5d2184eb0100py1t.html ），本地推送框架就好像一个邮件客户端，应用需要推送功能就好像添加了一个支持 imap idle 的邮箱帐号一样，应用本身后台被禁止，无法再做多余的事。
但是目前不存在这样一个框架，所以还是让需要推送的应用长驻通知栏为好。应用也应约束自己 ，不要开那么多对用户无益的服务。至于你提到的国内银行的云闪付卡密钥的推送，要么是它做了多余的事情，要么是为了更高的安全性需要这么复杂的功能因此需要耗这么多电。如果是为了安全性，那 GCM 也无法替代它吧。

@honeycomb 可能我们看重的不同吧，我不怎么看重功耗

@honeycomb 嗯嗯，所以我认为它如果能推送用户需要的内容的话（极少应用才需要），就有必要常驻通知栏。 GCM 也是我不喜的，应用向我推送内容，凭什么要通过 google 的服务器呢？我的原则是“尽量减少中间人”。

@honeycomb 真能推送用户需要的内容的话，长驻通知栏不就行了？用户需要你的推送通知，自然不会杀你的进程

我还是很少遇到这种网站