@honeycomb 还有一些问题：
1.这个 Build.SERIAL 是跟硬件有关的值吗？它具体是什么元件的什么值呢？存于何处呢？
2.也就是说目前 Android id ， Build.SERIAL ，连接着的 wifi 的 ssid 还有 已经安装的应用列表 都不受到 Android.permission 和 AppOps 两者的保护了？还有 /proc, 在 7.0 之前都不需要任何权限即可读取，那么从这泄漏的信息也不止是 mac 地址吧？我所知道的还有一些进程信息，可能还有别的。
3."正在运行的程序等信息(新版的)默认就阻止了" 这是从哪个 android 版本开始呢？还有“检索正在运行的应用”这个权限是不是已经没有用了？

@honeycomb
并不是想用 AppOps 保护，而是看着这个 commit 做出的改动挺简单的，就是在 selinux 里加两条，所以想着能否移植到 6.0 和 7.0 的系统去。
但是如果真是用 Build.getSerial()代替了 Build.SERIAL 的话，好像并不是这么简单的修改可以实现的，可能这个接口改动在以前就实现了，现在只不过添加了 selinux 规则使得它生效而已。但是我也不会用这个安卓源码管理系统，不知道怎么去找这之前实现了这个接口改动的 commit ，也就没法进一步探究了。。。

@zqcolor 降级麻烦吗？需要清空数据吗？

@salary123 可能是这些网站跟腾讯有 交易 吧

这个 robot 验证是可以直接点击通过的吗？我每次都要选择图片点击才行，很烦人

@honeycomb 这个安卓源码管理系统我不太看得懂啊。我想问下，这个 commit 有希望进 7.1 的正式版吗？
另外，它说“ The Build.SERIAL value is set to 'undefined' for apps targeting high enough SDK and for legacy app the value is still available ” , “ high enough SDK ” 是指 SDK 25 （ android 7.1 ）吗？有没有办法让 Build.SERIAL 对目标 SDK 较低的应用也失效呢？

@wohenyingyu02 然而能够无所不用其极关闭应用后台的安卓用户只是极少数而已，大部分还是对此没有办法的。

@zhoubug kodi 虽然有可以看国内视频网站的插件，可是好像没有搜索功能啊

@honeycomb
https://android.googlesource.com/platform/system/sepolicy/+/3286fca7db279b9e5d69da408301fc48b52b4c4b 这里有个禁止应用读取 Build.SERIAL 的 commit

@honeycomb
Instant App 是依赖于谷歌框架的，这个谷歌是有能力掌控的，所以可以对权限限制严些；本地应用不依赖于 google play ，所以 google 没能力管。

@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 上的权限管理不容乐观啊。