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