App 会不会收集那些不愿意给权限的用户，然后在其他方面区别对待？

那就上个插件随机返回

不是直接拒绝服务吗

@cjpjxjx iOS 上的 App 多数不会这样，但也见过不给通讯录权限不让用的

所以一直希望 Android 添加虚拟权限的选项。
比如阻止获取 IMEI，应用就拿到一个随机的，和应用相关的 IMEI。
比如阻止获取短信，应用就拿到一个空的收件箱。
比如阻止获取通讯录，应用就拿到一个空的通讯录。
比如阻止获取照相 /录像权限，应用获取的摄像头就是一个静态视频提示。

还是高德直接，不给电话权限 app 就进不去

@laozhoubuluo 如果是 target Q 的话，IMEI 是拿不到的，不过 play 上的应用到 target Q 估计还得两年，目前还是得 root 后用 app ops 来阻止

@laozhoubuluo

就 IMEI 来说，从 Android Q 开始谁都拿不到 IMEI 了（排除系统 priv 目录，以及少数个例，如拥有 sim 卡密钥签名的运营商软件，profile manager 应用），拿到电话权限也看不到 IMEI。

至于一般意义上的返回随机数，dianne hackborn （这人是 Android 组的老员工，Android 的权限机制是她管的，最近在 reddit 的一次 ask me about everything 活动）的意思是，开发者最终总是能察觉到返回了的是随机内容 /空内容，所以它们不愿意做这件事。

类似的，他们不愿意把 appops 暴露出来给一般用户使用也因为 appops 晦涩难懂。

目前的 workaround 基本上可以覆盖绝大多数的场景了，appops 对付强要权限的，magisk+storage redirect 对付强要 storage 权限的。这样的话除了美团这种以外都能治。

@azh7138m
@honeycomb

IMEI 之前没了解到，这次了解了，感谢各位告知。

另外我一直想说，target api （以下简称 ta ）的向后兼容是很失败的。
Google 角度：ta 不够高，因此我要按老版本逻辑提供服务，应用程序需要这个数据我就要求用户给，不给我就返回阻止，应用程序自己退出跟我没关系，反正是开发商写的 exit。
我的角度：ta 不够高，至少要把决策权完全交给我，由我来决策操作系统应该如何告诉应用程序，是按照老版本逻辑返回阻止，还是在读取时返回一个空的 /随机的内容，在写入时提示我是写到沙箱还是写到真正通讯录，而不是说因为 ta 过低，我就必须全盘托出。

magisk+storage redirect 是可以解决问题，但是解 bl、开 root 又是另一种风险源。

个人观点：
1. appops 可以稍微隐藏的深一点，因为 appops 确实晦涩难懂，但不删除，有正常入口应该是底线。
2. ta 是一个能保证老程序运行的机制，不是一个破坏系统保护规则的漏洞。当隐私保护 /技术演进和 ta 向前兼容有冲突时，应优先考虑隐私保护 /技术演进。用户不允许写 storage 就默认 redirect，用户不允许获取地理位置就永远返回用户设定的地理位置。否则应用厂商永远不会升级 ta，因为 ta 低永远不影响程序运行，而且还能获得更多用户隐私。

如果微软当年采用的是 ta 机制，我写个 DOS 程序覆写一下 0 地址，机器应该马上死机，但实际上提示的是应用程序不可写，要求用户退出程序（针对一般用户）或启动调试器调试程序（针对高级用户，系统的最终权限要给到用户）。

既然 Android 现阶段做不到 iOS 的 level （大胆放弃向前兼容，全力维护用户隐私），那也请至少做到 Windows 的 level （ OS 决定不了的事情交给用户）。而不是说目前的开发商来个低 ta，系统就把我卖了。而且这种行为如果继续纵容下去，那在 Android 版本碎片化之后，应用 ta 会越来越碎片化。

@azh7138m 有一小部分的 appops 以 special access 权限，开发者选项的方式暴露。

就 scoped storage 来说，Google 目前不允许通过 appops override 应用自己的设定。你会看到用 appops 读取的时候有两个 legacy_storage，而 appops 只能改掉其中一个，另一个因为 manifest 而出现的无法更改。

真是麻烦

@laozhoubuluo 只依靠 Google play 限制 ta 确实很不足，如果是在 iOS 上确实足够。