具透｜Android 17 正式版：大屏体验，先看 Google？主作者关注克莱德少数派成员The curator｜缺一抹奇幻色彩。克莱德关注克莱德少数派成员The curator｜缺一抹奇幻色彩。联合作者关注克莱德少数派成员The curator｜缺一抹奇幻色彩。克莱德关注克莱德少数派成员The curator｜缺一抹奇幻色彩。04/20 16:27前天 16:23更新：Android 17 正式版更新Android 17 正式版已经在本月中旬与大家见面了，或者说与国内那一小撮仍在使用 Google Pixel 的用户见面了。作为选择 Pixel 系列机型的主要原因之一，来自 Android 系统的大版本更新一方面得以让我们窥见 Google 在自家 Pixel 机型上对「Android 系统体验」的理想愿景，另一方面作为 Android 生态的主要维护者，Google 对 Android 底层的部分改动其实也足以为相隔万里、但依然破碎的国内生态，带来一些微妙的影响。那 Android 17 正式版究竟怎么样呢？面向大屏的效率交互和其它更新内容相比，Android 17 对大屏设备的交互优化显得最为成熟、立体，部分改动在我看来甚至可以归为 QoL（生活质量）级别。首先，Android 17 对活动窗口（Activity）的重建机制进行了调整。以往当设备的某些配置发生变化时系统默认会销毁并重新创建前台活跃的活动窗口，消耗资源事小、导致用户当前操作上下文被打断就非常败好感了，比如填写内容的过程中因为连接实体键盘导致页面刷新，已经填写的内容和表单位置丢失，设置好的定时深色模式开启，正在浏览的电商应用一个主题刷新便带你从商品详情页回到了主界面等。Android 17 对于这类其实不需要完全重绘界面的设备状态变化，包括键盘状态、触屏模式、色彩模式等，默认不会再通过重启活动窗口的方式来更新状态，从而实现平滑过渡。对经常需要转换使用形态的 Android 大屏设备而言这个改动其实也比较实用。其次，Android 17 针对分屏添加了一键调整分屏应用比例的快捷按键。分屏时点击两个应用之间的分隔符，即可通过出现的按钮在 5:5、6:4、和 9:1 三种模式间快速切换，比手动拖动调节效率更高一点，从无障碍优化层面来讲也更加合理。国产安卓用户肯定见怪不怪了吧针对多任务，Android 17 带来了一项名为「应用气泡（Bubbles）」的特性。在启动器中长按应用图标，即可以「气泡」的方式打开应用。这些应用会以悬浮窗分组的方式显示在屏幕上的气泡区域内，点击即可在悬浮窗中显示，并且支持通过顶部的气泡图标在多个应用「气泡」间来回切换。「应用气泡」交互方式在大屏设备上，这套「气泡」交互会固定为屏幕底部一侧的「气泡栏（Bubbles Bar）」，在极端情境下，Android 设备的大屏内现在甚至可以挤下分屏、悬浮小窗和一组悬浮的气泡应用，进一步提升多任务处理的任务处理上限——但也很难不让我怀疑内存捉襟见肘的 Android 平台究竟还能不能跟得上这套交互。相比之下，「气泡」在小屏上的交互方式只能说是差强人意。一方面，它与 Google 从Android 11开始就有的「对话气泡」功能几乎完全一致，只是适用范围从「对话消息」这个特定的通知类别变成了所有应用——这一点其实从当前版本依然采用「对话气泡」这个中文翻译也能得到应证。同时，虽然「气泡」本身允许我们拖动、停靠在屏幕中的任何位置（并且动画也赏心悦目），但展开状态会占据大部分的屏幕显示空间，这意味着通过「气泡」的方式与应用交互时，后方的应用内容其实约等于是不可见的。这很难不让人思考一个问题：除了切换方式从导航横条的滑动变成了气泡分组的点击切换，「气泡」交互在小屏上似乎与原本的多任务系统没什么本质上的区别。注意 GIF 抽帧到了 24FPS 所以看上去不那么丝滑「气泡」功能目前也无法通过上面提到的、长按启动器图标之外的方式触发，这一点从国内定制系统体验的角度来看可以说是 Google 确实缺少一些想象力了。如果「气泡」能够直接在全面屏多任务手势的基础上增加触发方式（比如从底部小横条一直上滑到屏幕左上或右上角），那「应用气泡」功能在我这里的使用频率可能会成倍提升。现在的它实在是有点死板。以 Android 17 为目标平台进行适配的新应用，在 Android 17 上都将变成完全可由用户随意「拿捏」的形状。屏幕方向、尺寸调整和宽高比限制，将不再适用于最小宽度大于 600dp 的显示屏，应用在大屏上运行时，默认会填满整个显示窗口，无论宽高比或用户的首选屏幕方向如何。这也给那些写死应用方向、强迫用户旋转内屏使用、用「放大」替代「大屏适配」工作的做法下了整改通知：这里第二次抛出上面那道「数学题」，2027 年 8 月 31 日之后，Google Play 商店中仅适配移动端小屏交互的应用将不复存在。结合这些年折叠屏设备宛如抽奖般的实际体验，可以说 2027 年这个时间窗口其实相当温和，并且说到底 Google 也只是拿掉了一条「捷径」——真有头铁的开发者，依然可以不做什么自适应布局，任由应用在大屏设备上缩放、变形，轻则设备使用形态转换（比如外屏到内屏）时应用重载当前界面丢失，重则应用内相机方向混乱，图像、文本完全不具备可读性……相比之下，Android 17 为桌面模式下的「画中画」小窗提供了交互能力，实用性显然会更胜一筹。不过现在「画中画」小窗、窗口模式、分屏、应用气泡……Google 似乎又已经在大屏多任务交互上堆叠了不少窗口机制，并且已经有了略显混乱的趋势，希望 Google 能在铺平基础体验之后好好梳理一下这些窗口机制的层级和关系吧。但话说回来，今年如果 Apple 按预期推出折叠屏设备，多多少少能帮到咱 Android 大屏应用适配一把吧（笑）。最后，Android 17 也为折叠屏设备带来了一种 1:1 分屏的游戏显示布局。开发者可以利用一侧显示自定义的控制按键，用另一侧显示游戏内容，爱好任天堂 DS 游戏机的朋友肯定眼馋，但不支持折叠角度悬停的折叠屏设备可就无缘咯。安全与隐私保护联系人选择器尽管在国产应用这边的采用率有限，但 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 商店中的应用都必须请求本地网络访问权限。验证码短信保护你一定有过这样的体验：在某个 app 中使用短信验证码登录，当验证码短信通知响起（甚至完全不会响起）的同时，这个 app 已经自动填入收到的验证码并完成了登录。这里用到的可能是 SMS Retriever API、SMS User Consent API 和 WebOTP API，上面提到的这种为数不多的、无需用户或系统干预的「短信验证码自动提取」和「验证码自动回填」体验，都至少依赖其中一种或多种 API。在此前的 Android 系统中，针对使用 SMS Retriever API 的应用 Google 设置了一个三小时后的延迟机制，即采用这种验证方式的验证码短信对大部应用而言都只能在三小时后才会变成可见状态。而在 Android 17 中，这个延后机制被扩展到了 WebOTP API 短信并且适用于所有应用，如果应用本身面向 Android 17 及以上系统版本开发，则所有短信、无论是否采用上述 API，都会应用这套三小时的延迟机制。Google 希望通过这个机制来解决 OTP 短信验证码劫持问题，但说到底个人认为短信验证码就是一种在安全性方面不及通行密钥的认证手段，还是早点扔了的好。跨设备体验各种形态的设备越来越多，系统级接力 API（Handoff）其实也早该端出来了：跨设备「接力」在 Apple、华为鸿蒙生态中已布局多年，但大量的 Android 厂商依然需要一个平台层面的支持来打破屏障。在返回手势那篇文章中我们提到，Android 应用中大部分看得见、摸得着的交互，都是由活动（activity）来承载的。Android 17 的接力 API 也用到了这一基础架构，开发者只需要给想要接力的活动窗口打上特定标注，另一设备上的任务栏或启动器中就会出现接续操作的提示。当前视频播放到了几分几秒、文档滚动到了哪一行、或者是购物车里勾选了哪几样商品，都能通过这个数据包传递到另一设备上、调用同一应用的对应活动窗口打开，并且 Goo