和去年 8 月中旬发布的 Android 13 正式版不同，今年的 Android 14 正式版延后到了 10 月 4 日——也就是 Pixel 8 系列发布的同一天。原因我们似乎也能从 Google 宣传新特性中略窥一二：

除了明确表示会率先向特定 Pixel 机型推送的 AI 壁纸生成，因为 OEM 厂商一般都会在系统界面、配色方案上搞「二创」，所以 Android 14 官方页面所宣传的锁屏时钟样式、黑白风格主题等特性，最后也极有可能只有 Pixel 用户才能体验到。

那 Android 14 能为非 Pixel 机型的用户带来什么？参考 Google 的官方介绍视频，我们也从相关文档中整理了一份 Android 14 值得更新的 14 项新特性供你参考。

1.更强大的照片格式

超强 HDR 图像格式！

从 MIUI 相册的 HDR 显示到 OPPO 新近机型的 ProXDR，Android 在 HDR 照片显示这件事情上今年又上演了一次「厂商倒逼 Google」的戏码。在 Android 14 中，Google 终于为我们带来了对 10bit HDR 图像的原生支持，并且还一并推出了新的 Ultra HDR 图像格式。

根据 Google 的介绍，Ultra HDR 图像格式在保存时会保留来自传感器的更多信息，并在查看时展示更鲜艳的色彩、更高的动态范围和更强烈的对比度，简单来说就是小部分国产厂商近几年在卷的那种 HDR 照片显示效果。值得一提的是 Ultra HDR 格式可以完全向后兼容 JPEG 图像格式，它不仅能在 Google 相册等支持 HDR UI 的应用中被正确解码，在未适配 HDR 或不支持 HDR 显示的设备上，Ultra HDR 格式图像也能回落至标准动态范围（SDR）来正常显示。

针对 Pixel 系列机型的 HDR 照片支持目前也是蓄势待发，刚发布不久的 Pixel 8 系列的相机应用已经内置了拍摄选项，开启该选项后所拍摄的 Ultra HDR 格式照片能够在 Google 相册中以 HDR 效果进行查看，同时 Lightroom 移动版也在最新的 9.0 版本针对 Pixel 7 系列和 Android 14 带来了 HDR 编辑与导出支持。

总体而言 HDR 照片对大家来说依然是一个陌生的新生态，比如尽管我很想放上几张对比图给大家看看效果——咱们的编辑器和网页都不允许。

另外 Android 14 也为 Camera2 和 CameraX 等相机扩展组件带来了更新，允许第三方应用支持更长的照片处理时间、调用系统相机的算法密集型拍照功能（如暗光拍摄能力）等，这类面向开发者（并且不会有多少国内应用适配）的细节这里就不展开了。

2.更规范的照片选取

好吧，至少从某种程度上来说是这样的。

从某种程度上来说，Google 正在强制推行自 Android 13 引入的照片选择器。对用户而言这当然是需要重点关注的头等好事。

简单来说，和此前需要开发者适配、需要 Google Play 服务更新支持的做法不同，Android 14 直接引入了一个让用户为 app 选择可见媒体文件的「中间层」，这个「中间层」用的正是照片选择器同样的设计：一个从底部弹出的照片和视频选择面板，内含支持多选和长按预览的「照片」（其实也可以选择视频）和可以按照路径位置查找媒体文件的「影集」两个页面。

在 Android 13 引入照片选择器这一设计后，Android 14 又新增了类似 iOS 那样的媒体文件范围选取机制，这套机制在 Android 14 中对应的权限是 READ_MEDIA_VISUAL_USER_SELECTED。

这个权限和以往大部分新系统、新权限最大的不同点，在于它是由系统自动附加的。只要应用请求 READ_MEDIA_IMAGES、READ_MEDIA_VIDEO 或 ACCESS_MEDIA_LOCATION 三类权限的任意一种，无论应用是否面向 Android 14 进行适配，READ_MEDIA_VISUAL_USER_SELECTED 这一权限都会被自动添加到应用的声明清单中。

从我们的实际体验来看，市面上主流的、已经适配了 Android 13 媒体权限（即将音乐和音频、照片和视频两类权限分开授予）的应用，在 Android 14 中访问照片和视频权限时的确都会先调起 Google 的照片选择器——先让用户选择应用可以访问的内容，然后应用内置的媒体选择器才能将已授权的内容展示出来。并且这种授予也是临时的，一旦应用被放进后台或进程被用户结束，下次启动时相关的授予流程就还会再出现一次。

如此一来这套新权限的局限性（虽然是暂时的）也很明显了：依然有少部分应用获得了调用照片选择器的豁免权，最具代表性的比如目标 API 级别为 32、依然面向 Android 12 进行适配的「小而美」。

我知道你想说什么但先别急，我们在上面也提到「强制」和「暂时」，是因为根据 Google Play 商店的目标 API 级别要求，2023 年 8 月 31 日起所有提交至商店的应用更新都必须面向 Android 13 进行适配，虽然 Google 允许开发者申请延期至 11 月 1 日，但微信在 Play 商店的最后一次更新恰好是 8 月 24 日……张小龙会如何应对我们拭目以待。

当然了，Google 也还是希望开发者都用标准化的照片管理器实现，毕竟视觉风格上与系统更搭。适配过的应用即便依然选择使用自己的媒体选择器实现方式，它们在 Android 14 中也能借助界面和操作提示引导用户重新选取更多媒体文件。

3.更省电的缓存机制

每次更新之后他们都这么说，这次是不是真的？

尽管我一直坚持是因为天气转凉，升级到 Android 14 之后，的确有不少手持 Google Tensor 处理器设备的朋友向我表示手机更凉爽、续航也更长了。

那暂且将功劳归于 Android 14 开始生效的缓存应用冻结机制吧。

缓存，即将前台运行的应用放进内存，和直接杀掉进程不同，缓存的应用调用起来更快、重新开启所需要消耗的资源相比冷启动也更少。所以将暂时不用的应用放进缓存是一种非常合理的做法，Google 将「暂停执行已缓存的应用」放进 Android 系统的「开发者选项」后，这个功能也一直以「Android 的墓碑后台机制」的身份备受玩机群体的推崇。

根据 Google 公开的数据，被暂停执行的已缓存应用在 Android 14 测试版中消耗的 CPU 周期要比 Android 13 正式版少 50%，因此在 Android 14 中这一机制得到「转正」，以往缓存的应用可以基本不受限制地运行，但在 Android 14 上这些应用在进入缓存后很短的时间内就会被系统冻结，直接杜绝其 CPU 资源调用。

不知道是不是已经知道了此前「暂停执行已缓存应用」机制的问题，这次 Google 也特别提到冻结仅适用于常规的 Android 应用生命周期 API（如前台服务、JobScheduler 或 WorkManager）之外的后台工作。

另外值得一提的是，随着缓存机制的优化，Android 14 也打破了平台缓存应用数量的长期限制，减少了冷启动应用的情况，而且设备 RAM 越大改善就越明显：在 8GB 内存的设备上冷启动应用速度提高了 20%，在 12GB 内存的设备上则提高了 30%。

4.更无感的登录体验

和刚发布不久的 Windows 11 Moment 4 更新一样，Android 14 也是首个系统级支持通行密钥（Passkey）的版本。Android 14 在平台 API 中引入了凭据管理器（Credential Manager），并且通过 Jetpack 开发库和 Google Play 服务，让该功能可以一直向下支持到 Android 4.4（API 级别 19）的老设备。

凭据管理器用于简化用户认证流程，并且主要通过通行密钥（Passkey）来提高安全性。

目前我们在 Android 14 的密码和帐号设置中可以看到通行密钥认证服务的相关设置，换句话说除了可以将手机上的生物识别信息作为通行密钥认证方式，Android 14 也支持添加第三方应用作为通行密钥管理应用。

不过虽然 1Password 早前宣布过对 Android 14 通行密钥管理的功能支持，但在最新的 Beta 测试版本中我们还无法成功调用 1Password 来创建通行密钥。

5.更好看的返回动画

但「预见式返回动画」竟然还在「开发者选项」里。

Google 提出的一个、有关 Android 系统返回的问题，即我们很多时候都不太确定返回操作会将自己带向何方。

为此 Android 13 提出了「预见式返回动画」这个解决方案，即通过一个类似「半确定」状态的动画预览，告知我们接下来会被带到哪里去——如果目的地非你所愿，那可能你就得取消返回操作、在当前界面中找找其他导航按键了（比如「向上」）。

两年过去了，这个特性准备得怎么样了？坏消息是它依然放在「开发者选项」里，好消息是它的确更完善了。

除了给返回箭头添加一个圆圆的、形状可变、颜色为 Material You 动态取色得背景之外，Android 14 正式版当中默认的预见式返回动画效果更自然、表现也更加稳定。同时 Google 也在 Android 14 中支持了自定义预见式返回手势动画的能力，允许开发者为应用中不同组件和不同界面的跳转加上更加赏心悦目的动画，官方 Material Design 组件库中也提供的底部菜单、侧栏菜单和搜索三种组件的返回动画供开发者参考、适配。

6.更好的多语言支持

简体中文除外。

和 MIUI 这类完全不管多语言支持的做法不同，Google 在原生 Android 的多语言支持上走的是另一个极端：完全不管除了简体中文以外的多语言支持——比起在 AOSP 提交中否决支持文字体可变字重支持的冷酷，今年 Android 14 引入的多语言支持可谓相当温暖：

比如针对特定语言中的语法性别现象的词形变化 API，用 Google 所举的例子来说，比如当我们的应用界面中需要显示「你已订阅……」这句提示语时，中文和英文状态下都是无需注意语法性别的，但如果是法语，这句话则可能对应三种情况：

• Vous êtes abonné à…
• Vous êtes abonnée à…
• Abonnement à…activé

词形变化 API 就是用来简化并解决这类问题的。根据 Google 的描述，这个 API 能够帮助开发者根据使用者的性别展示对应的语法性别文本，降低这类需求带来的开发成本，避免应用在采用特定语言显示时因为忽略语法性别而冒犯用户。

再比如区域偏好设置。我们或多或少都在天气应用、测量工具、量化 app 中接触过与地区偏好相关的设定，从温度、距离、长度采用哪种单位、日期显示采用年月日还是日月年到每周的第一天究竟是周日还是周一……以往这类设置往往都散落在不同应用的设置当中，Android 14 则在「系统 > 语言和输入法」中新增了一项面为「区域偏好设置」的独立页面，一方面方便用户提前选好自己想要的温度单位、每周起始日以及数字呈现方式，另一方面也配套为开发者提供了对应 API 和 Intent 来读取这些偏好设置，然后直接套用到应用当中。

根据 Google 给出的信息，这些偏好设置也能够在设备数据备份、还原的过程中在不同设备间迁移。

最后，针对 Android 13 引入的应用语言偏好设定，Android 14 也向输入法开放了应用语言的获取接口，让输入法能够根据不同应用的不同语言设定，自动弹出对应的输入键盘。

7.更聪明的分享菜单

造轮子造出的新思路。

当你在 Chrome 浏览器中点击「分享」按钮时，首先弹出的菜单是 Chrome 自行定制的分享菜单，这个分享菜单下方提供了包括屏幕截图、网页长截图、URL 链接复制等功能在内的六个分享操作——和 Android 系统的原生分享菜单（上图中点击「展开」后即是）不同，Chrome 在定制分享菜单中所提供的这些操作选项与我们的网页分享行为关联更加密切，或者说往往也是我们在浏览网页时主要考虑的一些操作。

作为规则制定者的 Google 在自家 Chrome、Google 相册中都采用「自己造轮子」的方式设计一个独立的分享菜单，正好也能说明 Android 系统原生分享菜单存在一个大问题：太公平了。无论分享的内容是什么，Android 系统都会在长长的分享菜单中将提供分享操作的应用按照名称排序，找起来不方便、有的分享操作和实际分享内容的关联性也比较差。

因此在 Android 14 中，Google 基于 Chrome 和 Google 相册的分享菜单设计思路，向应用开放了分享菜单自定义操作定制功能，允许开发者针对特定文件类型声明分享自定义操作，当用户呼出分享菜单时，这些操作选项会出现在分享列表顶部和分享内容预览之间，方便用户快速调用可能需要的应用执行下一步动作；同时 Google 也希望通过调整 Direct Share 目标排序的方式来优化 Android 分享菜单的可用性。

除了上述改动，Google 在 Android 14 中还将分享菜单做成了可独立更新的 Project Mainline 模块方便功能迭代，并且允许用户通过分享预览即时调整、编辑分享内容。

8.更友好的缩放体验

可惜来得有点晚，国内适老化的字体改造已经乱七八糟了。

在 Android 14 中，Google 还带来了最高 200% 的非线性字体缩放功能。和此前版本的机械缩放不同，采用非线性放大曲线的好处在于，界面中原本已经足够大的文本不会随着全局设定而同步缩放，文本之间的大小关系、层级结构都能得到有效保留，较大的字体更不会因为缩放而出现文本截断、难以阅读等问题。

在后续的版本中，Google 还在系统的快速设置面板中添加了一个专门用于字体缩放的开关，有这方面需求的朋友可以借助这个开关随时调整阅读体验。

9.更透明的权限调用

收紧关键权限、方便用户管理是永恒的主题。

很多人不知道的是，很多依赖定时执行任务或发出提醒的应用（比如 Tasker 也用）都会用到的闹钟——你看不见也听不到的那种。根据应用内设置的不同，这些闹钟会在既定的时间拉起应用，帮助应用准时完善用户设置好的任务。

不过问题在于，通过精确闹钟唤醒应用是一种资源消耗极强、Google 也非常不推荐的定时任务规划手段（根据 Google 的开发者文档它可以随时将设备从 Doze 状态中唤醒），此前引入的 闹钟和提醒 权限不再默认授予。这项限制适用于新安装的、面向 Android 13 及以上系统适配的应用。

与之类似的，Android 14 开始 Google 也会通过 Play 商店策略对非通话、闹钟类型的应用移除针对 USE_FULL_SCREEN_INTENT 这一权限的默认授权——在此前的版本中，应用可以借助这一权限在锁屏状态下弹出全屏通知，而 2023 年年底这一政策生效之后，开发者就需要通过适配专门的新 API 来向用户发起授权申请了。

Google 也在提高用户敏感数据使用情况在 Android 14 中的可见性。除了将部分数据安全相关的信息直接放进对应的权限授予弹窗外，Android 14 还会在特定情况下向用户发出通知提醒，包括：

• 应用开始向第三方共享位置信息
• 应用开始将位置信息用于广告目的

尽管目前大部分与敏感信息使用透明化相关的改动都围绕位置信息，此前 Google 在 I/O 大会上也透露过后续会将范围向其他个人信息扩展的计划。

10.更尴尬的截图提示

你截屏了！系统知道、对方可能也会知道。

当你在即时消息里向朋友诉苦、当老板在公司群里激情发言，应用里突然弹出通知提示说「对方刚刚进行了截屏操作」……类似的功能在 Android 14 中接下来就有 API 支持了。

借助 DETECT_SCREEN_CAPTURE 这一 API，应用在 Android 14 中可以获知与按键操作相关的截图事件（一般是电源键+音量减）了——然后应用开发者可以向用户发出提示，比如付款应用提醒用户不要随便截图分享收款码，或者将这个事件传递给其他人（官方文档中似乎并没有限制开发者这么操作），告诉对方你刚刚进行了截图。

然后呢？然后就看谁比较尴尬吧。不过大家也不用担心，一方面这个 API 只会检测基于按键操作的截图事件，ADB、录屏应用等应该不受影响——另一方面这种 Android 新版本特性，至少你每天都要用的微信是不会跟进的。

11.更灵活的常驻通知

那么「常驻」的意义是……？

一个相比其他改动而言不怎么起眼，但真正用的时候能让人楞上几秒的小改动：在 Android 14 中，常驻通知可以被用户手动划走消除了。

Google 也为常驻通知消除机制设定了一套比较基础的规则：

• 当我们点击通知面板中的「清除全部」按钮时，常驻通知不受影响
• 当手机屏幕锁定时，常驻通知不可被消除
• CallStyle 类别（通常与通话相关）的常驻通知不可被消除
• 使用通知面板中的「清除全部」选项时，常驻通知不会被消除

12.更现代的无损音频

给 USB-C 有线耳机用户一点爱。

干掉 3.5mm 接口之后，近几年真无线蓝牙耳机井喷式发展，各种传输协议也是日新月异。好在 Android 14 这次也关照到了那些坚持使用 USB-C 接口有线听歌的音乐发烧友。

Android 14 向开发者开放了 USB 设备首选混音器属性的能力，允许开发者注册侦听器以获取首选混音器属性的更改，并使用新的 AudioMixerAttributes 类配置混音器属性。AudioMixerAttributes 类支持在无混音、音量调整或后处理效果的前提下直接传输音频，进而带来无损的有线听歌体验。

13.更通用的健康数据

继健康数据与平台解绑之后，Health Connect 自身进一步与 Google Play 商店解绑。好事。

2022 年 5 月，今年 5 月，Google 在 Android 开发者官方博客中隆重推出了一个名为 Health Connect 的新平台并推出了相应的 API。Health Connect 官方网站用非常显眼的大标题和副标题简洁地描述了其核心功能与优势：简化健康类应用之间的连接。

散落在不同应用、服务和可穿戴设备中的健康数据，在 Android 平台上有了一个通用的、可实现数据迁移的中间平台。而从 Android 14 开始，Health Connect 开始从此前需要从 Play 商店下载安装的独立应用升级为系统能力，它将以系统组件的身份通过 Google Play 系统更新接收更新，对不能直接访问 Play 商店但可以借助 OEM 厂商定期更新系统的国内用户而言也是好事一件。

另外，Health Connect 也跟随本次更新新增了包括运动路线在内的更多数据类型。

14.更开放的商店策略

感谢欧盟。

8 月 25 日，欧盟《数字服务法案》正式生效。作为受该法案重点关照的大公司之一，Google 也在第三方应用商店这个反垄断诉讼的「热门话题」上做了不少工作。

在 Android 14 中，Google 引入了多个 PackageInstaller API 来保证第三方应用商店的使用体验：

• requestUserPreapproval() 允许第三方应用商店提前请求用户的安装批准，并且在用户授权后可以实现后台下载和安装体验
• setRequestUpdateOwnership() 允许第三方应用商店通过所有权声明指定应用自动更新的安装来源，非指定来源的应用升级需要用户手动批准
• InstallConstraints API 允许第三方应用商店选择用户并未与 app 交互的时段更新应用
• setDontKillApp() 允许第三方应用商店针对支持拆分式安装包（APKs）的应用采用无缝更新，比如仅更新用户当前未在使用的组件
  最后，从 Android 14 开始系统软件包安装程序也允许开发者指定要包含在应用中的 Google Play 应用商店页面的应用元数据，例如数据安全信息等。这同时也能方便第三方应用商店获取与应用相关的元数据信息

以上文章转载自少数派文章(https://sspai.com/post/83501)