4 月13 日凌晨，Google 按照計劃上線了Android 14 的首個Beta 測試版本（Beta 1）。和往年一樣，測試版除了方便應用開發者第一時間開展兼容性適配工作，對普通用戶而言，也是既能兼顧日常使用穩定性、又能提前感受新版變化的主要途徑。
在今天這篇文章中，我也收集、整理了從首個開發者預覽版至今所有Android 14 中出現的、值得關注的新功能，希望能為愛嚐鮮的你提供一些參考。
文中部分描述主要以Google Pixel 所搭載的Android 13 作為對比，如果你不清楚Android 13 都有哪些新特性，可以先查閱我們去年的「具透」文章。
邁向「無密碼」的未來：憑據管理器支持
和去年的照片選擇器類似，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 支持了。
借助 DETECT_SCREEN_CAPTURE 這一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 能在正式版之前將其打磨成型吧。
