升级也要图个明白：8000 字详解 Android 13 正式版的 9 个新变化
如果你拥有一台 Google Pixel 设备，升级到最近推送的 Android 13 正式版之后，你可能会觉得似乎没什么变化。
但我并不完全赞同「Android 13 就是 Android 12 加强版」这种说法——一年一次、甚至一年两次版本更新的节奏之下，抱着「每年都有新鲜感」这样的期待来看 Android 系统更新是有些理想化的。加上 Google 这两年在 Android 新特性开发上重心越发向自家 Pixel 机型的体验倾斜，将一年一次的大版本更新看成是一年一次的修补与完善其实更加合理一点。
另外，因为有 CDD、CTS 认证以及 Google Play 商店政策的存在，定制系统的碎片化问题近几年已有所改善。最终推送到大家手中的 Android 13 在外观上可能各有差异，基础功能方面的体验却不会相差太远。
P.S. 不知道 CDD、CTS 等概念的朋友可以去读少数派之前的文章：
所以在今天这篇文章中，我们还是以正式版的体验为参考，梳理 Android 13 值得关注的亮点更新和重要变化。希望不久后手机厂商基于 Android 13 的定制系统正式推送到你手中的设备时，你能有个对比和参考。
发图这件事，与 iOS 相似又有些不同
不知道你有没有留意过，当一款 Android 应用想要读取设备上的图片和视频文件时，可以采用的其实有两种做法：
一种是像大部分国产应用那样首先授予完整的文件访问权限1，然后通过应用内置的、设计和功能都参差不齐的选取器进行选择。
这种方法很粗放。应用获取到文件访问权限后，不仅可以直接在内置的图片和视频选择器中列出设备中的媒体文件，也可以借此访问设备中的其他目录，早前困扰 Android 平台的存储空间问题也来源于此。尽管 Android 11 引入了很多人心心念念的分区存储机制来改善私有目录滥用的乱象，但部分国产应用很快又学会了将用户和设备标识文件伪装成图片，然后将 /Pictures 这类公有目录变成新的用户隐私数据交换中心的新方案。
针对需要访问文件权限的做法，Android 13 这次将媒体文件权限进一步细分。已经适配 Android 11的应用（目标 API 等级 33）在 Android 13 中能够获取到的文件读写权限被分成了音频2、视频3和图片4，在实际使用过程中，应用可以根据实际情况将这三种权限灵活组合起来。
P.S. 关于目标 API 等级的详细说明，请参见《下载应用这件事，Play 商店为什么比国内软件商店更好？》
同样以微信为例，如果你安装的是已经适配了 Android 11 的 Play 商店版本，在 Android 13 中，微信的文件访问权限申请以及文件访问权限会变成下面这样：
相比之下，SAF 则是 Google 最近几年更加推荐的做法。此前在大多数 Android 设备上，这种方法都以系统默认的「文件」应用为载体，app 无需调用任何文件访问权限就能达成文件选择的目标。比如下图中的 Google Keep：
SAF 就像一座架在设备文件和应用之间的桥梁，它可以以最小权限获取的方式，访问包含图片、视频、音频和文档在内的大部分公共目录文件。
而针对图片和视频调用，Android 13 向 iOS「取经」，在 SAF 的基础上打造了一套全新的照片选择器。照片选择器的保留了 SAF 对隐私权限友好的特质，但比起简陋的文件管理应用，它还支持搜索、可以按时间排序，开发者也可以用相关的 API 接口中进一步设定多选和文件数量限制。
虽然交互体验相近，但 Android 13 的照片选择器和 iOS 还是有差异的。
Android 13 的照片选择器就像是一个图片与视频专用版 SAF，因为 SAF 伴随分区存储机制而来，照片选择器也成为了为数不多的非 Android 13 独占的新特性。至少对非大陆地区的 Android 设备而言不是——今年 5 月，Google 已经通过 Google 系统更新5的模块化系统组件更新机制向 Android 11 及以上系统版本的设备推送了照片选择器。如果你没有用上，可能的原因不限于：
- 你的手机根本就不具备 Google 系统更新功能，国内厂商一般而言都去掉了这一功能
- 你的手机里还没有适配照片选择器的应用（我的手机里也没有，如果你有，欢迎在评论区分享）
至于 iOS 那边，照片选择器的设计其实要更加合理一些：iOS 将照片选择器设计成了应用在选取图片和视频时必须采用的规范化流程，而非 Android 这边本质上依然需要应用开发者凭自觉启用的 SAF；不仅如此，iOS 也允许用户根据实际情况选择它的可见范围，比如 QQ 我只想通过照片选择器给 3 张，但微信却可以给 5 张，在应用中做到了「千人千面」，决定权则真正放在了用户手中。
所以总体而言个人更喜欢 iOS 的设计，虽然目前它用起来更麻烦——最理想的解决方案嘛，当然是用 Apple 的方式来推 Google 的规范了。
关于 SAF，另外一个值得一提的改动是 Android 13 不再允许应用通过 SAF 访问 /Android 目录下的子目录了。这个改动多少与此前开发者发现的一个文件读写漏洞有关6，对用户而言最直观的影响是，此前在 Android 12 中依然可以通过授予 /Android 目录访问权限进而访问 /Android/data 或 /Android/obb 等目录的文件管理器，在 Android 13 中除了 root 就真的无计可施了。
前台服务管理器与 Android 的后台设计
对系统资源的管理直接影响到设备的续航和性能表现，因此前台服务与后台管理一直以来也是 Android 系统更新的重要课题之一。
从原理上来说，前台服务与后台管理这两件事是同一枚硬币的两面，Android 13 则为用户带来了对前台服务的检测和停用手段：在快速设置开关面板底部，我们可以看到一栏用于提示当前正在运行前台服务应用数量的新操作区域，在底部被其他提示占用时，这个提示则会变成一个包含数字的气泡按钮。
这就是前台服务管理器（FGS），点击展开 FGS 后即可看到当前正在活跃的应用，点击对应的「停止」按钮就能一键让应用停止运行，可谓是相当直接的系统管理工具了。
其次 Android 系统也会帮助用户对前台服务进行监督，具体的机制是，在以 24 小时为单位的时间长度内，如果某应用的前台服务运行超过 20 小时，系统就会向用户发出提醒。这时点击提醒也会跳转到上述前台服务任务管理器当中。
前台服务管理器在 Android 13 中的强调，最大的意义在于重申了 Google 对现代 Android「划掉多任务卡片」这一行为的定义：
早年玩机用户所熟知的黑域、绿色守护和部分厂商的「划卡强杀」设计，其实更接近最右侧的「强行停止」，现在进入应用管理的详情页也依旧能够看到这个按钮。被强行停止的应用会停止一切活动，一般来说不能再自行启动，只能用户或其它应用手动拉起才能恢复运行。
多任务界面是真真切切的「应用运行历史记录」。它不代表应用的实际运行状态，划走卡片只是取消了历史记录以及清除了最后交互过的「活动窗口」，应用并不会立刻从运行内存（RAM）中离开，通知、媒体播放行为等也能得到保留。
新的前台服务管理器则可以暂停前台服务并将应用从 RAM 中驱离。需要注意的是，此时应用只是停止了运行，并不会从多任务窗口中移除，这一考虑或许是为了方便用户快速恢复任务，同时减少系统资源消耗。
当然，关于 Android 前台服务的科普以及 Android 13 前台服务管理器的更多细节，我的同事此前写过一篇更详细的文章，感兴趣的朋友可以前往那边深入了解。
关联阅读：前台服务管理器：如何手动在 Android 13 上「杀死」一个应用
运行时权限，规范的不只是通知
聊了这么多照片选择器，接下来我们再看看另一个 Android 13 向 iOS 学习的主打特性：通知运行时权限。
虽然通知管理体验糟糕，但 iOS 的通知权限却早已是运行时授予的了：一般而言，应用会在首次运行时向弹出请求窗口向用户请求许可，然后由用户决定是拒绝还是许可。但在 Android 12 或更早的系统版本中，通知权限则是一个安装时默认授予权限，具体的行为也是可以由应用开发者自己来定义的。
所以尽管 iOS 在通知管理上几乎只做对了一件事，但 Android 和 iOS 后续留给用户的通知管理体验都挺糟糕的。
举例来说，Android 平台上的电池监控类应用一般会在通知中心保留一条常驻通知，并会不断弹出新的通知来更新其中的信息。这一切并不需要用户来许可，应用也可以选择「静默通知」来尽量避免对用户的打扰。
但类似的通知又要求应用开发者的高度自觉与克制：谁不想多弹通知争取一些用户的注意力？走进手机商场摆弄一下展示机，光只是预装应用的通知就已经能够堆成长长的「瀑布」。所以某些定制系统（比如此前的 ColorOS）甚至会在非内置白名单应用安装完毕后，直接「一刀切」默认关闭所有通知。
更重要的是，在上面提到的前台服务管理器一文中我们分享过一个观点：
只要应用保证通知正常显示，它的前台服务就能持续保持运行。
应用除了通过通知来吸引机主的注意力，还可以借它获取更多系统资源。在 Android 系统的设计中，前台服务主要有两大特点：即使用户停止与应用的交互，仍能继续运行；执行过程中必须显示通知。后者是很多「毒瘤」应用保活的常见手段，近年来随着定制系统「杀后台」问题突显，也为不少常规应用所用。
通知乱象背后所牵扯的问题可以说是由表至里的，正因为如此，Android 比 iOS 更需要通知运行时权限。
所以在 Android 13 中这个功能就来了，只不过具体的操作办法上和 iOS 的「强制二选一」有所不同：除了「允许」「不允许」两项之外，用户还可以划走权限申请对话框。简单来说，运行时权限虽然是一个 Android 13 的新特性，但适配了 Android 13 的应用（target API 33）仅仅是获得了自定义弹出权限申请对话框的时机这一优势，配合清晰直观的用途说明，想要合理推送通知的 app 不用过多担心用户不给许可。
但同时它对其他应用的限制也足够强力，拒绝了通知，也就直接消除了通知打扰以及假借通知进行后台保活的可能性。从用户角度出发，通知运行时权限可能是 Android 13 最简单、但也最有效的权限管理改进之一。
最后，运行时权限这边 Android 13 还参考 iOS 14 的做法将附近 Wi-Fi 设备的权限（NEARBY_WIFI_DEVICES）从附近设备（NEARBY_DEVICES）中剥离了出来。
这个运行时权限的实际作用也可以参考 iOS 的「本地网络权限」。如果你有配置 Wi-Fi 或连接智能家居设备的经历，应该不难理解我们可以通过「连接到同一 Wi-Fi」这个操作，来获取同一局域网内其他设备信息的做法。iOS 借本地网络权限避免了这种情况，从某种程度上说也斩断了恶意应用窥探用户隐私的一条路径。
关联阅读：iOS 14 新增的本地网络权限，要开给第三方 App 吗？
而在 Android 这边，由于此类信息过于敏感，早前获取同一 Wi-Fi 设备这一权限是放在精确地理位置（ACCESS_FINE_LOCATION）权限下的，属于最高优先级的隐私权限。所以在 Android 12 引入附近设备权限后，Andorid 13 进一步将这个权限从定位中分离出来，如果你需要连接同一局域网内的其他设备，比如打印机、投影仪/投屏工具、音乐流播音箱、智能家居设备等，都可以通过新的附近 Wi-Fi 设备权限来进行最小化获取。
附近 Wi-Fi 设备运行时权限是面向 tager API 33 的，换句话说，只有适配了 Android 13 的应用才能通过这一方式向用户申请授权。
另外，开发者文档中也有几个细节值得玩味：Google 不仅在 Android 13 中限制了设备直接通过本机 Wi-Fi 发信功能（热点、Wi-Fi Direct 等）探测附近设备的能力，还要求应用必须声明自己不会从这些 Wi-Fi 设备信息中推导地址位置信息方可通过此 API 获取授权，即便应用已适配 Android 13。否则开发者必须像未适配 Android 13 的应用一样，只能通过精确地理位置权限来达成目的——而用户对定位权限的授予一般而言是更为谨慎的。
IF 金奖进化，主题好看、图标有争议
当你为手机换上一张喜欢的壁纸时，整个系统都会因为你的喜好而发生一些微妙的变化，壁纸的差异、取色结果的不确定性，将原生 Android 一直以来所坚持的那种定制化和个性化带到了一个新的高度……
Google 在 Android 12 中引入了全新的 Material Design 3 设计语言和 Material You 主题系统，可能是当时与 Google Pixel 团队紧密合作打造的这套多彩主题+单色图标反响不错（它甚至还拿了 IF 金奖），Google 很快便开始了 Material You 向整个 Android 生态的推进工作。
在本次的 Android 13 更新中，Google 依然在完善 Material You。这套为原生 Android 准备的多彩主题，在过去这段时间从开发者预览版到测试版的使用过程中，的确也超越部分功能和特性，成为了让我难以放下也不肯回去的一大理由。
很多时候我们的喜欢，就是来源于「好看」。Android 13 在此基础上想要满足的，是更为细致的色彩偏好。
同样一张壁纸，Monet 提取到的色彩方案也许并不能满足所有人的喜好。在此前由 5 种色彩和 13 种亮度组合成 65 种取色的基础上，Android 13 进一步加入了色相（hue）和色度（chroma）来对颜色的生成过程进行干预，并由此延伸出了 6 套不同的 Material You 色彩风格（styles）。
在 Android 13 中应用任意一张壁纸，正常情况下（壁纸颜色单一除外）我们都能在 Pixel Launcher 的「壁纸和样式」设置中看到壁纸颜色、基本颜色两个大类、每个大类各 16 种动态取色方案。通过终端运行
dumpsys activity service com.android.systemui/.SystemUIService | grep -A 16 "mSystemColors"指令获取对应信息可以发现，Material You 动态颜色在 Android 13 中演化出了 SPOT、SPRITZ、VIBRANT、EXPRESSIVE、RAINBOW 以及 SALAD 六个分支，取色倾向和实际观感各有不同。
其中 SPOT 对应 Android 12 中的 Material You 取色方案，SPRITZ 的颜色更加冷淡（也是个人最喜欢的方案），VIBRANT 色彩更为大胆，EXPRESSIVE 会选取壁纸中最跳跃的一种作为主色调，RAINBOW 和 SALAD 则分别对应「基本颜色」选项中的单色和撞色方案。
除开壁纸，Google 早前为 Pixel 打造的那套 IF 金奖主题中，采用单色风格、将图标主体特征抽象为几何图形并且能够根据设备深、浅色主题切换配套样式的图标，也是一大组成元素。Android 13 将这套图标的生成与适配方法正式开放给了开发者，关于这个特性的详细介绍，请参考此前我写的另一篇文章。
关联阅读：
根据不完全统计，截至发稿已经有超过 40 款应用跟进了主题图标设计，其中既有小众的独立应用，也有像 Reddit、WhatsApp 这样的大厂作品（具体请参见上方的《已适配主题图标的应用清单》），可见有不少用户对 Google 试图统一主屏风格的做法还是比较认可的。
但另一方面，前段时间我也在微博收到了不少评论，认为主题图标的存在进一步削弱了图标应有的辨识度；而且审美本就是一件主观的事情，主题图标在开发者当中目前也有争议，比如纯纯写作的开发者就认为这种设计「像小灵通」，并且明确表示过暂时不会为纯纯写作进行适配。
和糟糕中文艺名的译名说拜拜
在 iOS 平台使用 Apple Music（国区）和在 Android 平台使用 YT Music 的用户，多少都见过一些尴尬到「脚趾抠地」的中文艺名：打倒男孩、多杰猫、威肯……
前者比较麻烦，但后者其实一直以来都可以通过类似 iOS 单独为应用设置显示语言的方法来进行规避。
Android 13 终于为我们带来了能够满足这一需求的按应用设定语言偏好功能，相关设置位于「设置 > 系统 > 语言和输入法 > 应用语言」下。
在早前的开发者预览版本中，这个页面会将设备上所有应用都罗列出来，这种做法带来了一个问题：系统在设置中提供的语言选项，应用实际上可能并不支持。因而在正式版中，只有那些为应用配置了语言文件和清单声明的应用才会出现在按应用设定语言偏好页面当中。
在升级至 Android 13 正式版后，如果你想单独设置语言偏好的应用不在设置列表当中，不妨带上版本号、机型和适配参考向应用开发者进行反馈；如果你不是很想等，也可以在连接电脑、手机开启开发者选项并授予 ADB 调试权限后，执行：
adb shell settings put global settings_app_locale_opt_in_enabled false来强制为所有应用开启语言设置选项。
媒体通知换脸，变的不只是外观
Android 近几个大版本更新中，媒体通知都是一定会「挨刀」的那一个。不过比起 Android 12，Android 13 正式版的媒体通知设计倒是重新引入了几分多彩与灵动。
设计上来说，新版媒体通知卡片直接以媒体播放应用提供的专辑封面为背景，操控按钮、播放设备选择按钮的配色也提取自专辑封面，不再与 Material You 动态取色挂钩；同时也不再像以往那样单独为收起状态提供布局，无论是通知中心、快速设置开关面板还是锁屏，均以一种尺寸进行呈现。
交互方面，Google 为 Android 13 带来了更加符合 Material Design 3 控件风格的新版进度条，播放状态下进度条会以波浪形态不断跃动，拖动调节进度时则会呈现出受压拉直的效果，主要控制按钮的动画也非常类似；这种因为操作而产生形状改变的控件动画，Android 系统的锁屏密码键盘、Google 计算器中也早有应用。
另外，如上图所示，媒体输出设备的选择弹窗也由此前的底部弹出式变成了采用按钮缩放动画的居中弹窗，弹窗色彩则采用了 Material You 动态颜色。
当然，升级之后你可能会留意，部分应用的媒体通知卡片（比如截至发稿时的 Apple Music）并不像 YT Music 这样拥有 Material Design 样式的控制按钮，这是因为 Android 13 将媒体操作的读取来源从此前的 MediaStyle 切换到了 PlaybackState。后者相比之下可以为开发者提供更丰富的媒体操作按钮定制空间。
如果应用没有包含 PlaybackState 或面向更低版本的 Android 系统开发，在 Android 13 中则不会有新的操控按钮样式。
复制了什么东西，返回又将去到哪里？
在手机上进行复制粘贴操作，我们偶尔也会问自己这样的问题：我刚刚选中的文本范围是不是足够精确、我真的复制到了自己想要的内容吗？
Android 13 新增的复制预览悬浮窗，解决的就是这样的问题。复制文本、图片后，系统会在左下角弹出一个类似截图预览的窗口为我们复制的内容提供一个简单的预览。
此时我们还可以直接点击预览进入编辑页面，将文本粘贴后的二次编辑工作变得更加简单；如果复制的是图片，编辑操作则会调用 Google Pixel 内置的截图标记工具来完成。
此外，Android 13 也为密码这样的敏感内容增加了可以手动标记隐藏预览的标签声明；比较遗憾的是，此前曾出现在测试版本中的操作建议按钮（比如复制网址时直接提供浏览器跳转打开按钮）在正式版中似乎被拿掉了。
除了复制粘贴，这种对操作结果预期的增强，也贯穿于 Android 13 的其它多处改进当中。
比如 Android 13 为添加快速设置开关这一操作增加了 API 接口，开发者可以通过接入这个 API 的方式来方便用户直接向快速设置面板添加开关，省去了手动翻找、拖拽的麻烦；再比如 Android 13 也优化了启动动画的 API 接口，在直接跳转到应用特定界面（activity）而非冷启动场景中，开发者也可以根据自己的喜好选择是否提供开屏动画。
关联阅读：开屏广告之外应有的怡人风景：Android 12 应用启动动画详解
最有代表性的是，Android 13 还在开发者选项中加入了一项名为「预测性返回手势动画」的开关。
在 Android 平台上，跳转行为的发起和结束，有时候都不是以应用为对象的，提供交互界面的也可以是各种活动窗口（activity）。而根据 Google 的介绍，预测性返回手势动画的引入想解决正是不确定返回操作执行后交互界面将会被带去哪个位置的问题。
预测性返回手势在开启开发者选项后就可以体验了，知名备份工具 Swift Backup 在近期的更新中就进行了适配，在主界面使用返回手势推出应用时，我们可以通过动画看到主屏，然后决定是否要完成返回操作。
从 Google 的规划来看，这个功能很有可能会花上好几年的时间进行完善和打磨，最终想要实现的效果是可以在执行返回操作前预览所有可能到达的页面情况，而不是像目前我们能够体验到的这样仅限主屏。
app 需要闹钟叫醒，但也不能随便用
首先需要大家理解的一个概念是：和人一样，Android 平台中的应用也需要闹钟。
在滴答清单的「设置 > 声音、通知与提醒 > 高级设置」中，你就能看到一个名为「闹钟模式」的选项。开启后，滴答清单的通知提醒将变得更为准时，但就像这个设置说明所写的那样，即便你关掉了所有给自己用的闹钟，你的手机状态栏可能会因此留下一个消不掉的闹钟图标。
这里滴答清单所用到的，正是很多依赖定时执行任务或发出提醒的应用（比如 Tasker 也用）都会用到的精确闹钟。根据应用内设置的不同，闹钟会在既定的时间拉起应用，帮助应用准时完善用户设置好的任务。
问题在于，通过精确闹钟唤醒应用是一种资源消耗极强、Google 也非常不推荐的定时任务规划手段（根据 Google 的开发者文档，精确闹钟可以随时将设备从 Doze 状态中唤醒）。从提升续航和规范化的角度出发，Google 在 Android 13 中为设置精确闹钟这一行为引入了一项专门的权限：闹钟与提醒7。
现阶段，你可以在 Android 13 正式版的「设置 > 应用 > 特殊应用权限」中找到「闹钟与提醒」权限的管理页面。虽然目前 Android 13 会在安装时为所有应用默认授予这一权限，但因为它现在与 API 等级 33 直接挂钩，Google 可以采用更新 Play 商店政策要求的方式来对开发者的使用行为进行限制。
根据最新的策略声明，从 2023 年 7 月 31 日开始，这项权限将仅向闹钟、计时器、日历这类以通知提醒为核心功能的 app 开放，推测后续 Google 或许会通过将权限设置为运行时授予这样的方式来帮助用户更好地控制应用行为，避免精确闹钟对设备续航能力的影响。
旁加载与自动化，都没那么「方便」了
对 API 接口和系统功能的规范化使用其实是 Android 系统每次更新的隐藏主线之一，除了上面提到的内容，Android 13 正式版也会为很多依赖旁加载（sideload）方式进行安装的应用和部分自动化工具带来麻烦。
一方面，Android 13 正式版通过对应用安装来源的判断，对非常规来源的应用进行了功能限制。如果应用并非通过 Play 商店进行安装（比如旁加载或第三方应用商店），我们将无法直接为这些应用开启无障碍选项或授予它们读取「设备和应用通知」的权限。
要绕过这些限制，我们必须手动前往应用的详情设置页面，然后选择左上角菜单中的「允许受限制的设置」并通过身份验证来进行解锁。
另一方面，此前被 Tasker 这类自动化工具所依赖的系统日志读取接口，在 Android 13 中也受到了大幅限制。Android 13 要求应用在每次读取系统日志时都向用户发出授权申请，并且权限授予选项仅提供「允许访问一次」和「不允许」两种选择，直接抹除了自动化工具和剪贴板后台同步 app 在后台持续监测系统日志并执行关联任务的能力。
关于系统日志的读取，@Esperdev 的高级技术编辑 Mishaal Rahman 在这串推文分享了更多背景，包括此前 Android 平台上的跨平台剪贴板应用如何利用这个权限绕过 Google 的后台剪贴板读写限制，感兴趣的朋友可前往一读。
小结
从 Android 8.0 引入 LDAC 传输协议开始，Google 便一直在通过系统版本更新的方式为 Android 增强音视频标准的兼容能力，同时也得益于 Android 平台的开放性，很多新生标准在 Android 生态内也能以系统升级的方式得到支持。比如这次的 Android 13 正式版就新增了对低功耗（LE）音频和 MIDI 2.0 支持，同时还完善了 Camera2 API 对 HDR 视频的处理能力。
此外，还有包含 DSU 性能优化、空间音频等更为底层的功能变化，Google 也并未在正式版的更新日志中提及。如果你对技术相关的内容感兴趣，Mishaal Rahman 在 esper blog 中发布的这篇长文也值得一读。
参考链接：
- 本文技术细节参考来源
- 名词翻译参考来源：Android 13 现已正式发布至 AOSP
关联阅读：
> 暑期征文 数字文具盒 截稿日延期啦！快到了分享学习方法，拿走现金奖励 🎓
> 实用、好用的 正版软件，少数派为你呈现 🚀
© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。
如有侵权请联系:admin#unsafe.sh