6月18日，Google为Pixel设备推送了Android 17正式版和Pixel功能更新，我们在之前「前瞻」分析的基础上，结合正式版内容重新优化了文章结构。
选择Pixel系列机型，其中一个核心原因就是能率先体验Android大版本更新，这不仅展现了Google对自家Android系统体验的理想构思，作为生态的核心维护者，Google对底层的调整也悄然影响着远在千里之外、但依然碎片化的国内生态。
那么，Android 17正式版究竟有哪些亮点呢？
▍提升大屏效率的交互设计
相比其他更新，Android 17在大屏设备上的交互优化显得更成熟而全面，有些改动甚至可以列为生活品质级别的提升。
首先，Android 17重新设计了活动窗口的重建机制。
过去，当设备配置发生变化时，系统默认会销毁并重建前台活动窗口，这不仅耗费资源，更令人烦恼的是会打断用户操作，比如填写表单时连接物理键盘导致页面刷新，或定时深色模式切换让电商应用从商品详情页弹回主界面。Android 17针对这类不需完全重绘界面的状态变动，如键盘状态、触屏模式、色彩模式等，默认不再通过重启活动窗口来响应，实现了平滑过渡。对形态多变的大屏Android设备来说，这项调整非常实用。
其次，Android 17为分屏添加了一键调整应用比例的快捷按钮。点击分屏中间的分隔符，就能用出现的按钮在5:5、6:4和9:1三种模式间快速切换，比手动拖拽更高效，从无障碍角度看也更具合理性。
国产安卓用户肯定觉得很熟悉吧
在多任务方面，Android 17引入了一项名为「应用气泡」的功能。从启动器长按应用图标，就能以气泡方式打开应用。这些应用以悬浮窗组出现在屏幕上的气泡区，点击即可显示悬浮窗口，并通过顶部气泡图标在多个应用间流畅切换。
「应用气泡」交互方式
在大屏设备上，这套气泡交互被固定为屏幕底部一侧的「气泡栏」。极限情况下，Android大屏能同时容纳分屏、悬浮小窗和一组气泡应用，进一步拓展多任务处理能力——但这也让人怀疑内存有限的Android平台能否流畅支持这套方案。
相比之下，气泡在小屏上的交互只能说勉强够用。
一方面，它与Google从Android 11开始的「对话气泡」功能几乎无异，只是适用范围从特定通知类别扩展到所有应用——当前版本仍用「对话气泡」作中文翻译也印证了这一点。
同时，虽然气泡可以拖动并停靠在屏幕任意位置，动画效果也赏心悦目，但展开后会占据大部分屏幕，导致后方应用内容几乎无法查看。这让人思考：除了切换方式从导航横条滑动变成气泡分组点击，气泡交互在小屏上似乎与原有任务系统并无本质区别。
注意GIF抽帧到24FPS所以看起来不够流畅
目前，「气泡」功能除了长按启动器图标外，无法以其他方式触发。从国内定制系统的角度看，Google确实缺乏一些创意。如果能在全面屏手势基础上增加触发方式，比如从底部小横条直接上滑到屏幕左上或右上角，那么「应用气泡」的使用频率可能会翻倍。而现在它显得有些呆板。
以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授权模式，为联系人选择操作准备了更隐私友好的标准化界面，用户通过这个系统界面来选择披露的联系人范围。
联系人选择器的三种选择模式
作为借鉴iOS的功能，Android 17的联系人选择器有一些更细致的设计：在iOS中，披露粒度是联系人条目，即最小信息单元是某个联系人条目；而Android 17虽然功能类似，但披露粒度更细，应用需在intent中先声明要访问的联系人信息字段（如电话号码、邮箱、生日），用户选择联系人后，应用只能获取对应的字段。
iOS中的联系人选择器
不过，「非强制性」依然是Android 17联系人选择器目前最大的未知数。就像照片选择器还未完全替代媒体文件访问权限一样，联系人选择器也不是READ_CONTACTS权限的直接替代。Google只是做了系统标准界面，适配了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日后，所有应用都必须请求本地网络访问权限。
验证码短信保护
你一定有过这种体验：在某个app中用短信验证码登录，当验证码短信通知响起时，app已自动填入并完成登录。
这背后可能用了SMS Retriever API、SMS User Consent API和WebOTP API，那种少见的、免用户或系统干预的「短信验证码自动提取」和「自动回填」体验，都依赖这些API。
在之前的Android系统中，Google对使用SMS Retriever API的应用设置了三小时延迟机制，即这类验证码短信对大部分应用都只能在三小时后变为可见。而在Android 17中，这个延迟机制扩展到WebOTP API短信并适用于所有应用，如果应用面向Android 17开发，所有短信无论是否采用上述API，都会应用这个三小时延迟。
Google希望用这个机制解决OTP短信验证码劫持问题，但个人认为短信验证码在安全性上不如通行密钥，最好还是早点抛弃。
▍跨设备体验优化
设备形态越来越多，系统级接力API也该登场了：跨设备「接力」在Apple、华为鸿蒙生态中已布局多年，但大量Android厂商仍需平台层面的支持来打破壁垒。
在返回手势那篇文章中我们提到，Android应用中大部分交互都由活动来承载。Android 17的接力API也利用了这一基础架构，开发者只需给想接力的活动窗口打上特定标注，另一设备的任务栏或启动器中就会显示接续操作的提示。
当前视频播放到几分几秒、文档滚动到哪一行、购物车里勾选了哪些商品，都能通过数据包传递到另一设备上、打开同一应用的对应活动窗口。Google还考虑了一些特殊情况：如果两端都装了同一App，接收端可以直接用Deep Link快速恢复；如果没装，系统会拉起浏览器，打开开发者设好的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将需要额外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
