4 月 13 日凌晨，欧博abgGoogle 按照计划上线了 Android 14 的首个 Beta 测试版本（Beta 1）。和往年一样，测试版除了方便应用开发者第一时间开展兼容性适配工作，对普通用户而言，也是既能兼顾日常使用稳定性、又能提前感受新版变化的主要途径。
在今天这篇文章中，我也收集、整理了从首个开发者预览版至今所有 Android 14 中出现的、值得关注的新功能，希望能为爱尝鲜的你提供一些参考。
文中部分描述主要以 Google Pixel 所搭载的 Android 13 作为对比，如果你不清楚 Android 13 都有哪些新特性，可以先查阅我们去年的「具透」文章。
关联阅读：升级也要图个明白：8000 字详解 Android 13 正式版的 9 个新变化
迈向「无密码」的未来：凭据管理器支持和去年的照片选择器类似，Android 14 在平台 API 中引入了凭据管理器（Credential Manager），并且通过 Jetpack 开发库和 Google Play 服务，让该功能可以一直向下支持到 Android 4.4（API 级别 19）的老设备。
凭据管理器用于简化用户认证流程，并且主要通过通行密钥（Passkey）来提高安全性——少数派的读者对通行密钥应该不陌生了，在 Android 14 中 Google 也已经为这一特性铺好了路。
关联阅读：
目前我们在密码和帐号设置中可以看到由「Google 密码管理工具」提供的通行密钥认证服务，待主流密码管理服务完成适配后，未来我们应该可以像选择自动填充服务应用那样选择用于 Android 设备的通行密钥管理服务。
此前已经宣布将提供支持的就有 1Password 和 Dashlane，在 Android 系统级功能的支持下，希望通行密钥未来也能像密码管理服务一样成为「常态」。
用什么语言、看什么单位：一处设置处处套用在 Android 13 中，Google 终于带来了像 iOS 一样应用语言偏好设置，如果你需要特定应用采用与 Android 系统设置相独立的语言来显示内容，只需前往「设置 > 系统 > 语言和输入法 > 应用语言」即可进行手动「定制」。
Android 14 在此基础上增加了两个有意思的新东西，词形变化 API 和区域偏好设置。
词形变化 API 主要针对特定语言中的语法性别现象，用 Google 所举的例子来说，比如当我们的应用界面中需要显示「你已订阅……」这句提示语时，中文和英文状态下都是无需注意语法性别的，但如果是法语，这句话则可能对应三种情况：
Vous êtes abonné à...
Vous êtes abonnée à...
Abonnement à...activé
词形变化 API 就是用来简化并解决这类问题的。根据 Google 的描述，这个 API 能够帮助开发者根据使用者的性别展示对应的语法性别文本，降低这类需求带来的开发成本，避免应用在采用特定语言显示时因为忽略语法性别而冒犯用户。
区域偏好设置对中国大陆地区的用户而言则更加好懂一些——我们或多或少都在天气应用、测量工具、量化 app 中接触过与地区偏好相关的设定，从温度、距离、长度采用哪种单位、日期显示采用年月日还是日月年到每周的第一天究竟是周日还是周一……
以往这类设置往往都散落在不同应用的设置当中，每安装一个新应用，类似的区域偏好设置就必须得重新手动选择一次。Android 14 则在「系统 > 语言和输入法」中新增了一项面为「区域偏好设置」的独立页面，一方面方便用户提前选好自己想要的温度单位、每周起始日以及数字呈现方式，另一方面也配套为开发者提供了对应 API 和 Intent 来读取这些偏好设置，然后直接套用到应用当中。根据 Google 给出的信息，欧博官网这些偏好设置也能够在设备数据备份、还原的过程中在不同设备间迁移。
最后，Android 14 还有一些针对多语言支持的改进，但主要面向应用开发者，这里仅作简单罗列：
允许 IME 输入法应用获取当前应用所使用的语言设置，从而自动切换至对应的键盘语言，提升多语言用户在不同应用中的输入体验
允许开发者借助 Android Studio Giraffe Canary 7 和 AGP 8.1.0-alpha07 提供的新工具，更快完成应用语言设置偏好特性的适配
允许开发者根据设备地区定制可选语言清单，方便开发者进行 A/B 测试或通过服务端推送、更新应用语言设置清单
让返回操作更有确定感：预见式返回动画因为全局返回手势的存在，很多 Android 用户对「使用返回手势回到上一个界面」这件事也是习以为常。但「上一个界面」在由各种活动窗口（activity）构成的 Android 系统当中，往往也是充满不确定性的：假设你正在 Android 手机的主屏幕，这时收到一条邮件通知，你点开通知、读完邮件，顺手从屏幕边缘往里一划……此时你会去到的究竟是主屏还是邮件应用的主界面？
扩展阅读：都是边缘划动，Android 与 iOS 的返回手势到底有什么区别？
早前在 Android 13 正式版发布之时便已预告过的预见式返回动画，要解决的就是返回手势操作的「确定感」问题。在 Android 14 Beta 1 中，返回手势的箭头不仅拥有了采用 Material You 动态主题色彩的 Q 弹圆形背景，在开发者选项中开启「预见式返回动画」开关后，你还能提前通过系统设置感受 Google 对这一特性的最终设计：
简单来说，预见式返回动画就是要让我们在返回操作这一输入提交之前、看到即将返回的究竟是哪个页面——如果感觉不对，那你可能要撤销这一操作然后在当前页面中找找有没有其他能够带你去到目标界面的按钮（比如「向上」）。
国产应用搞不定的小黑条，Google 亲自动手从 Android 10 开始，Google 陆续提出了边到边（edge-to-edge）和逐帧键盘动画两项面向现代「全面屏」设备的设计规范，前者希望开发者将应用内容的绘制边界推至屏幕边缘，将状态栏和导航栏下方的屏幕区域也用于内容显示。
更多细节请参考《干掉「毒瘤」只是第一步：怎样的 Android 应用才算「好应用」？》中「更适合全面屏的应用设计」小节。
由于相关规范从未强制，很多国产应用的开发者至今不知「边到边」为何物（比如微博、饿了么）。为了不让主屏操作那个「小横条」显示难看的纯黑色背景，一些厂商甚至从系统层面为这些垃圾应用做起了「反向适配」。
来到 Android 14 —— 好消息是 Google 出手了，坏消息是 Google 选择了一种非常奇怪的处理方式。
比起此前常用的通过 Play 商店上架限制等手段来强制开发者进行适配，Android 14 开发者选项中这个「默认使用透明导航栏背景」选项可以被看作是 Android 系统的一次「反向适配」。
开启后，微博、饿了么等原本在应用底部采用「小黑条」的应用，都能根据应用界面提取背景颜色对导航栏背景进行自动填充，虽然效果肯定比不上真正的边到边适配，但至少屏幕底部那个常驻的小黑条是就此干掉了。
另外，实测这个仍在处在开发者选项中的小功能对国产应用的兼容性也要好于国外应用（比如 Spotify 的播放界面就没有效果）。
向 iOS 体验看齐，照片选择器支持范围选择在去年的 Android 13 中，Google 以 iOS 为参考引入了对用户媒体数据隐私更加友好的照片选择器功能，通过系统对媒体文件选择器交互的接管，减少应用直接获取文件读写权限的必要性。这项特性甚至还借助 Google 官方的向后移植和 Google Play 系统更新服务推送给了 Android 4.4 及以上系统版本的用户（国内用户就比较惨了）。
而在 Android 14 中，照片选择器的体验将进一步向 iOS 靠拢——应用在申请读取照片媒体文件或读取视频媒体文件这两项权限时，系统会弹出新的权限确认弹窗，在这个弹窗中，我们可以像 iOS 那样选择该应用能够访问的照片或视频范围或允许/拒绝其访问所有媒体文件。
考虑到 READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 这两项细分权限是在 Android 13 中才引入的，所以媒体文件读取范围这个新功能很有可能就无法像照片选择器那样给旧版本机型下放了。国内这边更是以系统适配 app 为主要做法（比如早年的 ColorOS 适配微信选图界面），从这个角度来说我还是比较认可「Android 系统的碎片化问题根本没有好转」这种说法的。
你截屏了！系统知道、对方可能也会知道当你在即时消息里向朋友诉苦、当老板在公司群里激情发言，应用里突然弹出通知提示说「对方刚刚进行了截屏操作」……类似的功能在 Android 14 中接下来就有 API 支持了。
借助 这一 API，应用在 Android 14 中可以获知与按键操作相关的截图事件（一般是电源键+音量减）了——然后应用开发者可以向用户发出提示，比如付款应用提醒用户不要随便截图分享收款码，或者将这个事件传递给其他人（官方文档中似乎并没有限制开发者这么操作），告诉对方你刚刚进行了截图。
然后呢？然后就看谁比较尴尬吧。不过大家也不用担心，一方面这个 API 只会检测基于按键操作的截图事件，ADB、录屏应用等应该不受影响——另一方面这种 Android 新版本特性，至少你每天都要用的微信是不会跟进的。
分享菜单：从应用定制「反哺」系统功能当你在 Chrome 浏览器中点击「分享」按钮时，首先弹出的菜单是 Chrome 自行定制的分享菜单，这个分享菜单下方提供了包括屏幕截图、网页长截图、URL 链接复制等功能在内的六个分享操作——和 Android 系统的原生分享菜单（上图中点击「展开」后即是）不同，Chrome 在定制分享菜单中所提供的这些操作选项与我们的网页分享行为关联更加密切，或者说往往也是我们在浏览网页时主要考虑的一些操作。
作为规则制定者的 Google 在自家 Chrome、Google 相册中都采用「自己造轮子」的方式设计一个独立的分享菜单，正好也能说明 Android 系统原生分享菜单存在一个大问题：太公平了。无论分享的内容是什么，Android 系统都会在长长的分享菜单中将提供分享操作的应用按照名称排序，找起来不方便、有的分享操作和实际分享内容的关联性也比较差。
因此在 Android 14 中，Google 基于 Chrome 和 Google 相册的分享菜单设计思路，向应用开放了分享菜单自定义操作定制功能，允许开发者针对特定文件类型声明分享自定义操作，当用户呼出分享菜单时，这些操作选项会出现在分享列表顶部和分享内容预览之间，方便用户快速调用可能需要的应用执行下一步动作；同时 Google 也希望通过调整 Direct Share 目标排序的方式来优化 Android 分享菜单的可用性。
除了上述改动，Google 在 Android 14 中还将分享菜单做成了可独立更新的 Project Mainline 模块方便功能迭代，并且允许用户通过分享预览即时调整、编辑分享内容，Mishaal Rahman 在这篇技术解析博文中做了详细说明，感兴趣的朋友可以前往阅读。
从无障碍到应用安装，处处设卡才更安全除了对用户而言感受更加直观甚至能够直接体验到的功能改进，Android 14 也在无障碍、应用安装、权限授予甚至应用代码加载等方面新增了不少限制。
无障碍方面，除了新增的非线性 200% 字体缩放特性外，Android 14 还进一步限制了应用对无障碍功能的访问，熟悉 Android 的朋友都知道，很多应用此前都会借助无障碍设置的识屏功能来达成便利（比如小星记账的自动记账功能），但权限越大风险也越大，同样的方法也极易被恶意应用利用，成为盗取用户隐私信息的突破口。
因此 Android 14 在 Android 13 的基础上进一步加强了限制：系统会通过新引入的 accessibilityDataSensitive 属性来判断应用是否为真正面向残障用户的特定应用（该属性的真实性将通过 Google Play Protect 服务保障），无法通过属性判断的应用将无法与特定的无障碍选项进行交互。根据 Mishaal Rahman 在其博文中的技术解析，Android 14 甚至还会通过获取应用安装方式的途径来判断应用来源，安装途径为非可信应用商店的应用，对无障碍功能的访问能力在后续的 Android 14 更新中很有可能将受到更进一步的削弱。
说到应用安装，从 Android 14 开始，面向 Android 6 以下系统版本开发的应用（targetSdkVersion<23）将无法安装——此举是为了避免部分恶意应用通过降低 targetSdkVersion 的方式绕开运行时权限机制，对用户而言算是一件好事；此外，从 Android 14 开始，我们在这篇文章中解释过原理的权限也不再向所有应用默认授予。
Pixel 独占特性速览及未来更新展望除了上面提到的更新内容，目前在 Android 14 Beta 1 中能够看到的还有不少细节，很多在正式版发售时可能也活不过厂商的「定制」环节因此只能成为 Pixel 独占，考虑到本文篇幅我们简单带过。
首先，Android 14 的甜品代号是 UpsideDownCake，简称 UDC，它的图标样式也已经确认了：
其次，Pixel 的系统设置已经基于 Jetpack Compose 重写了一遍——你不需要知道 Jetpack Compose 是什么，你只需要知道重写后的系统设置少了很多老旧的界面控件，多了很多与 Material Design 3 相符的新元素，比如圆角和开关：
最后，Pixel 也对一些常用功能进行了调整，比如壁纸预览现在默认采用全屏样式了，电池使用情况除了单独展示亮屏时间还会展示 CPU 耗电（Tensor 真是可怕），iPhone 用户用了很多年的来电闪光功能，在 Pixel 中则以闪烁通知的形式推出了……
至于此前呼声挺高的应用克隆功能，在今天放出的 Android 14 Beta 1 中依然没有正式上线，希望 Google 能在正式版之前将其打磨成型吧。
参考链接：
Android 14 首个开发者预览版到来
即刻体验 | Android 14 开发者预览版 2
android-developers.googleblog.com
