本文来自微信公众号： 少数派 ，作者：克莱德，原文标题：《Android 17 正式版体验：分屏一键切换、应用悬浮气泡，大屏生产力拉满》
6月18日，Google面向Pixel机型推送了Android 17正式版和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中的本地网络权限
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也用到了这一基础架构，开发者只需要给想要接力的活动窗口打上特定标注，另一设备上的任务栏或启动器中就会出现接续操作的提示。
当前视频播放到了几分几秒、文档滚动到了哪一行、或者是购物车里勾选了哪几样商品，都能通过这个数据包传递到另一设备上、调用同一应用的对应活动窗口打开，并且Google也考虑到了一些比较特殊的使用情况，比如两端如果都装了同一App，接收端可以直接通过Deep Link启动实现快速恢复，如果接收端没装App系统则会拉起浏览器，打开开发者在HandoffActivityData里设好的URL，实现「无缝降级」；另外还有仅传递URL链接的URL Handoff，适合跨设备书签同步、新闻阅读等场景。
应用信息设置中也已经有了「任务连续性」选项
对国内用户来说，接力API其实也有一个变数：Google这套设备间活动流转的机制显然是基于Google服务和Google账号搭建的，对Google Play相关服务的依赖目前也不明朗。考虑到部分搭载了Google服务的国产机型在实际体验方面均有缩水（比如Quick Share），只能祈祷接力API对Google服务的依赖低一点、或者国产Android厂商能做一些本地化适配吧。
▍其它细节与Pixel功能更新
除了上述内容，Android 17正式版和同步上线的Pixel功能更新中，值得一提的新特性还有：
除了上述内容，Android 17值得一提的新特性还有：
实时更新类通知新增了语义着色API，开发者可以在实时更新通知中用绿、橙、红、蓝四种预置颜色来设置符合使用情境的色彩样式
针对助理应用引入了专用的助理音量音频流，助理声音通过USAGE_ASSISTANT播放，音量调节和其他类别的音频分离并支持单独控制
可以单独控制智能助理的语音音量了
引入了基于设备总RAM的应用内存限制，极端内存泄漏等情况下的系统稳定性表现应该会更好，并且影响范围更可控
音频框架会对后台音频互动强制执行限制，以确保这些更改是由用户有意发起的（比如媒体播放），其他「非法」音频请求会以静默方式失败，坊间流传的「音频播放保活」小妙招可能会失效，各种奇奇怪怪的音乐播放被打断的情况应该会更少
你可以在开启录屏时同步启用手机的前置摄像头，轻松做出社交平台上流行的那种「reactions」式的小视频，无需繁琐的后期合成、绿幕抠像
下次的具透干脆用这个功能做？
最后，和iOS 27一样，Android 17也强调了家长控制功能的作用，系统设置内置的家长控制页面现在包含了每日屏幕时间使用限额、应用使用限额、夜间使用时间、商店过滤和网站内容过滤等工具，但这个功能与多用户配置功能冲突，开启工作账户或者「私密空间」的前提下是无法正常使用家长控制功能的。
除了语音翻译、Magic Cue等原先为新机型独占的功能开始向旧机型下放，Gemini也在本次Android 17更新的同时引入了音乐创作和基于Gemini Omni模型的视频生成功能——但Google将需要额外Google AI订阅的特性放进Pixel功能更新来宣传，只能说早些年宣传七年更新的时候我还有点怀疑，但现在事情就渐渐明朗了。
最后，此前我们在前瞻时提到的Tap to Share果然不是什么已经正式确认的Android 17功能，在本次的正式版当中它也的确没有上线。
One UI和Pixel OS中的碰一碰互传功能
考虑到Quick Share已经成熟到可以兼容AirDrop了，Google再借Android Beam的理念帮它「打包」一个上层交互的想法也算是合情合理，甚至有点Android Beam精神传承的味道——至少在看到动画效果之前我是这么想的。
原文链接：https://sspai.com/post/108899?utm_source=wechat&utm_medium=social