App 再也不能乱读你的通讯录，Android 17 这些升级值得关注

Android 17 在 Beta 测试阶段就给人一种「无从下手」的感觉：或许是因为 Google 现在每年都会给每个大版本推送两次更新，而每次正式版之前的测试周期被压缩到只有 2-3 个月，即便让 Gemini 来写代码，应该都不太可能端出太多让人眼前一亮的新东西。

Android 17 更新时间线

上周 Beta 4 版本的发布，意味着 Android 17 目前已经进入了 Platform Stability 阶段，所以在下半年的测试开启前我们应该都看不到什么新东西了。

那 Android 17 在过去两个多月时间里都加了哪些新功能呢？交互这边我们或许能（在 Pixel 设备上先）看见的：联系人选择器、本地网络权限、分离式语音助理音量、大屏优化、接力 API，看不见的底层那边则有MessageQueue无锁化、基于设备总 RAM 的应用内存限制、usesClearTraffic弃用、限制隐式 URI 授予、旋转后恢复默认输入法可见性……

这篇文章我们就来展开聊聊，就当是给 Android 17 的首次正式版做个「前瞻」了。

▍碰一碰互传

Tap to Share 并不是什么已经正式确认的 Android 17 功能，所以我们上面并没有提到它。

Android Authority 最早在 3 月底的 One UI 9（基于 Android 17）泄漏固件中发现了这个功能，9to5Google 则在后续拿到了 Pixel 设备这边的功能截图和交互动画。

One UI 和 Pixel OS 中的碰一碰互传功能

iOS 用户看到 Tap to Share 的功能示意图，可能会想起 iOS 17 上线的名片投送（NameDrop）功能，而稍有年纪的 Android 用户则会第一时间想起 Android Beam——Google 在 2011 年发布的、基于蓝牙传输协议的跨设备分享方案。Android Beam 借助 NFC 功能和「碰一碰」这个交互，精简了蓝牙传输分享这个流程中最为繁琐的搜索配对流程。

尽管交互方式颇具前瞻性，Android Beam 里子依然是蓝牙传输，在十多年前的 Android 手机市场，这种设计简直是把能叠的 buff 都叠满了。一方面 NFC 在非旗舰 Android 机型上并非标配，另一方面蓝牙传输的速度基本意味着与大文件分享、传输无缘。所以后续的故事也说得通：三星在 Android Beam 的基础之上开发了基于 Wi-Fi 传输协议的 S Beam，Google 则进一步在「亲儿子」三星理念的影响下推出了 Nearby Share（现在改名叫 Quick Share）。Android Beam 就像一个技术预览，在 Android 系统的角落里闲置了八年后，在 Android 10 中被彻底隐藏，并且在 2023 年的 Android 14 正式版中从 Android 代码中完全移除。

交互动效

考虑到今年 Quick Share 已经成熟到可以兼容 AirDrop 了，Google 再借 Android Beam 的理念帮它「打包」一个上层交互的想法也算是合情合理，甚至有点 Android Beam 精神传承的味道 —— 至少在看到动画效果之前我是这么想的。

▍联系人选择器

尽管在国产应用这边的采用率有限，但 Android 系统近几年在「照片选择器」这个功能上的投入还是值得肯定的：从最初作为 Android 13 正式版的新功能上线，到后续作为 Google 服务的组件完成对老机型的向下兼容，照片选择器作为一项「借鉴 iOS」的隐私设计，在铺开的过程中算是结合到了 Android 生态机型多、版本碎片率高的客观现实。

Android 17 的联系人选择器或许也会成为类似的功能。Google 在这里借鉴了 Apple 在 2024 年的 iOS 18 中推出的 Contact Access 授权模式，在 Android 17 上为联系人选择这一操作准备了一套更为隐私友好的标准化界面，用户通过这个系统提供的标准化界面来选择联系人披露范围。

联系人选择器的三种选择模式

作为一个借鉴 iOS 平台而来的特性，Android 17 的联系人选择器也有一些相比 iOS 更加细致的设计：在 iOS 中，联系人访问权限的披露粒度是联系人条目，即我们可以选择开放给应用的最小信息单元是某个联系人条目；而 Android 17 这边虽然看上去功能类似但披露粒度更细，应用需要在 intent 里首先按照具体的联系人信息字段（比如电话号码、邮箱、生日）声明自己要访问的联系人信息类别，用户通过联系人选择器选择联系人披露范围后，应用才能拿到这些联系人信息中的对应字段。

iOS 中的联系人选择器

不过「非强制性」这一点依然是 Android 17 联系人选择器功能目前看来最大的未知因素，正如照片选择器至今依然没有完全替代媒体文件访问权限一样，Android 17 的联系人选择器也并非READ_CONTACTS联系人访问权限的直接替代。Google 目前只是做了一个系统层面的标准界面，适配了 Android 17 的应用可以选择采用这套隐私友好的联系人信息获取流程，未适配 Android 17 的应用如果原本在用Intent.ACTION_PICK，在新系统中也可以自动获得新界面 —— 但联系人访问权限还在，不想管 Android 平台原生特性的应用依然可以不管。

考虑到 Google 后续的确有通过拆分媒体访问权限、降低系统版本要求等手段来推动照片选择器的适配，这里不妨就留个希望，希望联系人选择器同样也是入口先行，我们应该能很快在下半年的更新中看到 Google 对联系人读取权限动刀吧。毕竟联系人访问权限也是一个不小的隐私泄露源头。

▍本地网络权限

和联系人选择器类似，Android 17 同样也引入了本地网络权限。

首先必须明确一点：大家在 iOS 系统中看见的、大部分应用发起的本地网络权限申请，本质上依然是想借助局域网发现能力做局域网设备探测、用户画像和用户指纹识别，最终是要用来给你做个性化广告追踪和推荐的。我们的主张和当初文章中的一样：就大部分应用而言，它们都不需要给本地网络权限。

iOS 中的本地网络权限

关联阅读：iOS 14 新增的本地网络权限，要开给第三方 App 吗？

Google 在 Android 17 中正式将本地网络权限纳入了NEARBY_DEVICES权限组当中，并且所有面向 Android 17 及以上系统版本开发的新应用，默认情况下都会被屏蔽本地网络访问行为，包括 TCP 连接、UDP 单播、多播、广播等，甚至无法解析 .local 这样的本地域名。这里 Google 同样建议有特定需求的开发者选择更为隐私友好的中转方案，例如借助 Android 系统级 Cast SDK 中的输出切换器来完成投屏，而如果是智能家居控制、IoT 管理这类需要持续、广泛访问局域网的需求，再借助本地网络权限向用户请求授权。

我们也在这里第一次抛出本文的「数学题」：按照 Google Play 商店对应用目标 SDK 等级的要求，2027 年 8 月 31 日之后，Google Play 商店中的应用都必须请求本地网络访问权限。

▍大屏优化

说「大屏优化」其实有点宽泛，但以 Android 17 为目标平台进行适配的新应用，在 Android 17 上都将变成完全可由用户随意「拿捏」的形状：屏幕方向、尺寸调整和宽高比限制，将不再适用于最小宽度大于 600dp 的显示屏，应用在大屏上运行时，默认会填满整个显示窗口，无论宽高比或用户的首选屏幕方向如何。

这也给那些写死应用方向、强迫用户旋转内屏使用、用「放大」替代「大屏适配」工作的做法下了整改通知：这里第二次抛出上面那道「数学题」，2027 年 8 月 31 日之后，Google Play 商店中仅适配移动端小屏交互的应用将不复存在。

结合这些年折叠屏设备宛如抽奖般的实际体验，可以说 2027 年这个时间窗口其实相当温和，并且说到底 Google 也只是拿掉了一条「捷径」—— 真有头铁的开发者，依然可以不做什么自适应布局，任由应用在大屏设备上缩放、变形，轻则设备使用形态转换（比如外屏到内屏）时应用重载当前界面丢失，重则应用内相机方向混乱，图像、文本完全不具备可读性……

但话说回来，今年如果 Apple 按预期推出折叠屏设备，多多少少能帮到咱 Android 大屏应用适配一把吧（笑）。

▍接力 API

各种形态的设备越来越多，系统级接力 API（Handoff）其实也早该端出来了：跨设备「接力」在 Apple、华为鸿蒙生态中已布局多年，但大量的 Android 厂商依然需要一个平台层面的支持来打破屏障。

在返回手势那篇文章中我们提到，Android 应用中大部分看得见、摸得着的交互，都是由活动（activity）来承载的。Android 17 的接力 API 也用到了这一基础架构，开发者只需要给想要接力的活动窗口打上特定标注，另一设备上的任务栏或启动器中就会出现接续操作的提示。

应用信息设置中已经有了「任务连续性」选项

当前视频播放到了几分几秒、文档滚动到了哪一行、或者是购物车里勾选了哪几样商品，都能通过这个数据包传递到另一设备上、调用同一应用的对应活动窗口打开，并且 Google 也考虑到了一些比较特殊的使用情况，比如两端如果都装了同一 App，接收端可以直接通过 Deep Link 启动实现快速恢复，如果接收端没装 App 系统则会拉起浏览器，打开开发者在HandoffActivityData里设好的 URL，实现「无缝降级」；另外还有仅传递 URL 链接的 URL Handoff，适合跨设备书签同步、新闻阅读等场景。

目前 Pixel 启动器中的浏览器标签页恢复功能应该也是类似的实现

对国内用户来说，接力 API 其实也有一个变数：Google 这套设备间活动流转的机制显然是基于 Google 服务和 Google 账号搭建的，对 Google Play 相关服务的依赖目前也不明朗。考虑到部分搭载了 Google 服务的国产机型在实际体验方面均有缩水（比如 Quick Share），只能祈祷接力 API 对 Google 服务的依赖低一点、或者国产 Android 厂商能做一些本地化适配吧。

▍其他改动

正如开头所言，目前 Android 大版本更新的迭代速度加快，越来越多的新特性要么放在下半年，要么就干脆成为 Pixel 设备和三星设备独占，其他厂商还得再等上个一年半载。看得见、摸得着，让人眼前一亮的东西越来越少。

除了上述内容，Android 17 值得一提的新特性还有：

• 实时更新类通知新增了语义着色 API，开发者可以在实时更新通知中用绿、橙、红、蓝四种预置颜色来设置符合使用情境的色彩样式

• 针对助理应用引入了专用的助理音量音频流，助理声音通过USAGE_ASSISTANT播放，音量调节和其他类别的音频分离并支持单独控制

可以单独控制智能助理的语音音量了

• 引入了基于设备总 RAM 的应用内存限制，极端内存泄漏等情况下的系统稳定性表现应该会更好，并且影响范围更可控

• 音频框架会对后台音频互动强制执行限制，以确保这些更改是由用户有意发起的（比如媒体播放），其他「非法」音频请求会以静默方式失败，坊间流传的「音频播放保活」小妙招可能会失效，各种奇奇怪怪的音乐播放被打断的情况应该会更少

• 底层MessageQueue完成了无锁化重构，从线程消息请求的底层层面减少了 UI 自动化执行时的摩擦，感兴趣的朋友可移步具透 Plus。

以上便是 Android 17 正式版值得关注的主要更新，虽然大多数更新已是板上钉钉，但最终体验还是得等到 5 月的 Google I/O 大会。我们到时候见！

https://sspai.com/post/108899?utm_source=wechat&utm_medium=social

作者：克莱德