@ivmm 具体什么地方

只能说你对不稳定的耐受度比较高

@ivmm ubuntu 16.04 gnome 放大 200%，效果挺好的，唯一不支持的软件是 easystroke

@kitesays magisk 不是不影响 ota 的吗？

@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 项目。”可能在代码实现上是这样，但从我的实践来看这两种权限系统的设定值还是相互独立的。

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