如果仅从新功能和新样式的角度去看 Android Q 的第一个 Beta 版本，很多人应该都会得出「Android Q 算不上是个大版本更新」这个结论。但事实却并非如此——如果说 Android Oreo 的最大更新点是 通知系统、Android Pie 的最大更新点是 Home 键手势，那么将 Android Q 与此前的 Android 版本区分开来的最大改动，应该就是隐私了。

权限收紧，全面封堵流氓行为

在 Android 操作系统中，隐私和权限是密切挂钩的。

正因为如此，Google 自 Android 6.0 Marshmallow 开始就引入了运行时权限（runtime permissions）特性，允许用户在应用运行过程中根据实际需求授予特定权限。例如当应用第一次运行并尝试获取位联系人权限时，我们会看到这样一个弹窗。

运行时权限申请弹窗

引入运行时权限的本意是让应用的权限申请流程更加清晰透明，给予用户更多的主动权。但长久以来这个授权机制在实施效果上却并不理想：一方面，一般用户并没有像预期那样获得权限管理这件事情上的主动权，很多应用开发商由此摸索出了不给权限便拒绝正常工作这种流氓思路；另一方面，对那些面向低版本 Android 系统开发的老旧应用来说，它们则可以完全规避掉这个机制。

对权限管理机制的进一步细化和完善，显然成为了 Google 要解决的一大问题。Android Q 针对权限管理机制做出了如下更新：

首先，正如很多人都注意到的那样，位置权限的授予方式在 Android Q Beta 1 版本中变得更加灵活。除了允许和拒绝，Android Q 还为位置权限加入了额外的「仅在使用该应用期间允许」选项，对于那些不需要在后台获取位置信息的应用而言，这种权限授予方式不仅可以减少应用后台期间的电量消耗，还能在一定程度上避免不必要的个人隐私信息泄露。

位置权限可以仅在使用应用期间授予

其次，即便是上面提到的那些面向低版本 Android 系统开发、属于运行时权限机制「管辖」范围以外的老旧应用，它们的权限请求也无法像以往那样在安装后便被设置为「默认允许」了。在 Android Q 上安装这样一款「老应用」后，系统会在该应用初次运行时直接以全屏界面提示应用将要获取的权限并提供手动开关，我们可以根据实际需求酌情授予。

通过降低 SDK 版本来绕过权限申请的做法不再可行

再次，一个名为「隐私权」的设置项在 Android Q 中也成为了一个独立的一级设置项。这个设置项目下不仅整合了应用权限管理、锁屏通知展示方式、Google 自动填充服务和 Google 位置信息记录等常见隐私设定，还首次在 Android 系统层面向用户提供了「广告 ID 和个性化」开关，允许用户选择停用广告个性化功能。

隐私权与广告 ID 设置

最后，大量不规范的应用行为将在 Android Q 中得到限制：

弹出窗口将被完全封杀，Google 不再允许应用直接从后台启动一个 activity 窗口来对用户当前的窗口和任务进行干扰，在 Beta 1 的实际体验中，Magisk 的 root 权限授予窗口和 1Password 的密码自动填写窗口在系统数次提示后都再也不会弹出。

后台弹出窗口将被封禁提示

后台应用无法读取剪贴板内容，在 Android Q 中，只有被设置为默认输入法或正在前台运行的应用才能读取剪贴板数据，换句话说，当前依赖后台运行的大多数第三方剪贴板管理应用都将面临「失业」——事实上，我们此前推荐过的 Cliper 已经在 Android Q 第一个 Beta 版本放出的同时宣布将于今年 5 月关闭剪贴板内容同步服务。

Clipper 的声明 | 图：AndroidPolice

悬浮窗权限也将定时自动撤销，很多 Android 应用都可以借助悬浮窗特性来实现一些便利功能（如 FooView、Share 等），但这个特性同时也为恶意应用盗取用户隐私提供绝密手段。为此，Android Q 也会在应用进程被杀、应用重启或设备重启后自动撤销先前用户授予的悬浮窗权限。如果你像我一样使用 Share 刷微博，就会发现几乎每次启动 Share 后点开微博视频都需要重新授予 Share 悬浮窗权限。

Share 的视频悬浮窗权限也会被定期重重置

另外值得一提的是，IMEI、MEID 等不可重置的设备标识信息在 Android Q 中也不再通过电话权限向第三方应用开放，同时，连接 Wi-Fi 后的 MAC 地址也将自动随机化处理。

Android 9 中需要手动开启的 MAC 地址随机化选项

沙箱来袭，还你一个整洁的存储空间

大多数应用都需要在我们的手机里储存信息，而这种储存行为本应是有序的：Android 系统一直以来都提供了 /data 和 sdcard/Android/data 两个目录来进行应用数据文件存放，无论应用开发商选择将应用数据放在何处，都不至于让你的内部存储空间像上图所示那样混乱不堪。

这种不按照规范随意存储信息在公共目录甚至内部存储空间根目录的行为不仅影响美观、降低文件管理效率，无形中也为「全家桶」应用之间的「协作」提供了便利。举个例子，我们在 A 应用中因为需要上传用户头像而授予了它内部存储空间的读写权限，但 A 应用在获得授权后，还悄悄将它收集到的设备隐私信息（如 IMEI）明文储存在了内部存储空间根目录。

这样一来，其他应用即便被拒绝授予敏感信息的访问权限，也能通过内部存储空间中的这个文件实现隐私信息的「共享」。

混乱的内部存储空间

Google 在此前的 Android 版本中一直在探索存储功能的改进方向，包括引入对 SD 卡的访问限制和限定目录访问权限控制等，但内部存储空间「脏、乱、差」的现象一直都没有得到根本性地改善，对用户而言隐私风险也依然存在。

而这次在 Android Q 中，Google 引入了一个更加强力的新机制来应对上述问题——应用域和媒体域存储（App-scoped and media-scoped storage）。

尽管这个新机制有着非常长的名字，但它的原理其实和我们大家耳熟能详的「沙箱」概念类似：既然无法避免应用向公共目录随意读写文件，那不如索性将它们各自放进一个与世隔绝的沙箱里，既能对应用间数据和用户隐私数据进行有效隔离，又能保证内部存储空间干净整洁。

首份 Android Q Beta 1 兼容性测试报告节选

「沙箱」机制无疑会对当下大部分存储行为不端的国产应用造成不小的冲击，更直白地说，这其中大部分应用在 Android Q 下不仅无法在内部存储空间内随意创建文件，如果不跟进适配新的存储行为机制，它们甚至连相册文件都无法正常读取。

关联阅读：兼容率达78%！首份Android Q版本兼容性评测报告出炉

不过目前 Android Q Beta 1 中的应用数据「沙箱化」默认为关闭状态，如果你想手动测试效果，可以按照以下步骤打开：

1. 手机端开启 USB 调试并连接电脑
2. 电脑端打开命令行窗口或终端，执行 adb shell sm set-isolated-storage on

随后手机会重启，重启后在命令行或终端中执行 adb shell getprop sys.isolated_storage_snapshot，若返回 true 则为开启成功。

ADB 开启「沙箱」模式

需要注意的是，考虑到应用兼容性问题，「沙箱化」机制仅适于用于面向 Android Q 开发的应用或开启「沙箱」后重新安装的应用。如果开启「沙箱」前应用已经使用过内部存储空间（比如保留数据 OTA 至 Android Q Beta 1），则需要卸载该应用重新安装才能使「沙箱」机制机制生效。

开启前后内部存储空间的效果对比可参考下图：

赏心悦目不是吗

最后，虽然这个新机制对那些一直以来都按照开发规范设计的应用而言几乎没有任何影响，但大部分应用、包括文件管理器应用在开启了「沙箱」机制后都将遇到问题，至于如何应对这些新机制带来的问题，在尊重用户隐私数据的前提下合理利用内部存储空间，不妨参考 @烧饼 不久前分享在 Matrix 社区的文章。

关联阅读：Android Q 存储行为大变化，对用户和应用的影响都有哪些 – 少数派

Google 更强硬，但我们还需要更多

通过上面的介绍可以看出，未来在 Android Q 的测试版或正式版本中，当下荼毒国内安卓生态的诸多「毒瘤」应用和「毒瘤」行为都将得到限制，与此同时，我们此前多次推荐过的诸如存储重定向这样的应用也将因此面临「失业」。

从用户的角度出发，这类 hack 向、有一定折腾成本和兼容性风险的应用逐渐失去作用是件好事，而当我们回过头来重新审视那些在 Android Q 推出后依然不会「失业」的应用就会发现，即便 Google 如此强硬，我们仍有一个最为根本的问题亟待解决，即不给权限不让用的问题。

换句话说，除了文中所提到的改进，Android 还需要更强力的流氓应用对策（比如允许用户像 AppOps 那样给个空权限）。关于这一点，希望我们能在 Android Q 接下来的测试版本中看到更多。