本文来自微信公众号： 少数派 ，作者：克莱德，原文标题：《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大会。我们到时候见！