image

隨著 Android 12 正式版 的發布，越來越多的用戶將升級至最新版本。Android 12 帶來大量新 API 和功能更新的同時也帶來了平臺兼容性的變更，我們建議開發者優先對當前應用進行測試，并進行兼容性更新。這樣一來，當用戶將設備更新至 Android 12 時，可確保其擁有良好的體驗。

本文將重點介紹 Android 12 中最大的兼容性變更，并分享有關如何讓用戶順利過渡到最新版本系統的一些建議。此外，我們還會分享一些來自領先應用的案例和建議，以幫助您了解其他開發者如何充分利用 Android 12 的功能，以及如何借鑒到自己的應用中。

如果您更喜歡通過視頻了解此內容，請 點擊此處 查看。

Android 12 中的變更

兼容性變更主要分為兩類，一類默認影響所有運行的應用，另一類則只基于應用已聲明的目標 SDK 級別對其產生影響。方便起見，本文將在變更標題中加以備注以幫助您更好地了解對應變更內容對您應用的影響。

Android 12 采用全新的個性化 Material Design 實現了跨越式的視覺更新。我們一直致力于簡化和完善現有體驗并幫助您構建美觀、安全和高性能的應用來滿足用戶需求。為此，我們專注于用戶界面、性能和隱私三大方面進行優化。本文中將主要介紹 Android 12 在用戶界面和性能方面的變更。

用戶界面相關的變更

應用開屏頁 (影響所有應用)

從 Android 12 開始，系統會在冷啟動和暖啟動應用時都使用新的默認開屏頁。該開屏頁由應用的啟動圖標和主題的 windowBackground 組成，并在啟動時展現順滑、流暢的過渡動畫。

△ Android 12 中的默認開屏頁

這種全新的體驗適用于所有運行在 Android 12 上的應用。如果您的應用實現了自定義開屏頁，則需要遷移到新的 SplashScreen API。我們建議使用 Jetpack 的 SplashScreen 庫來實現向后兼容性，以在所有 Android 版本中提供一致的觀感。

由于新開屏頁可完全自定義，因此，即使您現有的開屏頁用于路由，我們也建議將其完全移除。這樣將避免開屏頁重復，而且能減少加載時間。

如需了解詳細的適配流程，請查閱 Android 開發者網站的 遷移指南。

自定義通知 (僅影響 targetSdkVersion 為 31 的應用)

Android 12 更改了完全自定義通知的外觀和行為，使其在視覺上保持一致且易于瀏覽，并為用戶提供可檢測到的、熟悉的通知展開狀態。

[圖片上傳失敗...(image-f3b97c-1641875507146)]

在之前，自定義通知能使用整個通知區域，并能提供自己的布局和樣式。對于面向 Android 12 的應用，帶有自定義內容視圖的通知將不再使用整個通知區域，系統改而使用標準模板。

△ Android 12 之前和之后自定義通知可使用的區域對比

該模板確保自定義通知在所有狀態下的裝飾與其他通知相同，例如圖標、應用名、展開和收起狀態標識。該變更會影響使用自定義 Notification.Style 子類或使用 Notification.Builder 方法設置自定義內容視圖的應用。如果您的應用正在使用完全自定義通知，請務必測試這類通知是否能夠兼容新模板。

△ 受影響的自定義內容視圖的 API

沉浸式模式下的手勢導航 (影響所有應用)

Android 12 還整合了現有行為，讓用戶在沉浸模式下更輕松地執行手勢導航命令。即使處于沉浸式模式下，系統手勢也會立即響應。BEHAVIOR_SHOW_BARS_BY_TOUCH 和 BEHAVIOR_SHOW_BARS_BY_SWIPE 這兩種行為現已棄用，被新的 BEHAVIOR_DEFAULT 行為所取代。BEHAVIOR_DEFAULT 行為讓用戶只需滑動一次即可執行手勢導航，而在 Android 11 上則需要滑動兩次。即使是開發全屏游戲的體驗，仍可在沉浸模式下通過使用 BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 標記來防止用戶受到誤觸手勢的影響。

[圖片上傳失敗...(image-c0b75b-1641875507146)]

性能相關的變更

前臺服務 (僅影響 targetSdkVersion 為 31 的應用)

前臺服務能讓 Android 系統確保資源優先用于完成用戶發起的耗時任務，但它經常被濫用。我們發現幾乎一半的前臺服務是從后臺啟動的，這導致了許多問題，包括電量會被迅速耗盡，以及用戶會被意外的前臺服務通知困擾等。因此從 Android 12 開始，將禁止從后臺啟動前臺服務，并對啟動前臺服務作了限制。以下情況可啟動前臺服務:

• 可見的 Activity 或窗口
• 用戶操作，如通知、小部件等等
• 特定的廣播和回調
• STICKY 類型的服務可在崩潰或由于低內存而停止運行的情況下重啟

有關前臺服務啟動限制的完整豁免列表，請查閱 Android 開發者網站—— 前臺服務。

今年早些時候，我們在 Jetpack 的 WorkManager 庫中引入了加急任務。這些低延遲任務可從前臺或后臺調用并會立即執行。這些任務可在低電量模式下運行。我們鼓勵開發者盡可能使用這些任務來替代啟動前臺服務。

精確鬧鐘權限 (僅影響 targetSdkVersion 為 31 的應用)

在大多數情況下，應用應使用粗精確度鬧鐘，其優勢在于省電。在鬧鐘和計時器等特殊情況下，可使用精確鬧鐘。Android 12 新增了一項清單權限——SCHEDULE_EXACT_ALARM，用戶可查看并控制擁有此權限的應用。此外，還新增了一個新的 API —— canScheduleExactAlarms()，您可使用此 API 來檢查應用的權限狀態。

通知 trampoline (Notification trampolines，僅影響 targetSdkVersion 為 31 的應用)

一些應用在處理用戶點擊通知的行為時，會使用廣播接收器或服務等中間組件，這些組件被稱為通知 trampoline，它們常常導致延遲和用戶流程中斷，面向 Android 12 的應用將不能從這些蹦床啟動 Activity。這一新限制有助于減少從通知啟動應用的延遲。我們鼓勵棄用通知 trampoline 并直接從通知啟動目標 Activity。舉個例子，在棄用通知 trampoline 后，Google 相冊應用的啟動速度提高了 34%。如果您的應用使用了通知 trampoline，請使用以下 adb 命令查看用戶與通知交互時所啟動的組件:

$ adb shell dumpsys activity service \ 
com.android.systemui/.dump.SystemUIAuxiliaryDumpService

△ 使用該命令查看用戶與通知交互時所啟動的組件

應用鏈接 (僅影響 targetSdkVersion 為 31 的應用)

Android 支持應用鏈接的概念，它可以讓 HTTP 網址直接鏈接到已安裝的應用。這樣便可完全繞過消歧對話框，通過消除用戶使用過程中的分歧來改善用戶體驗。應用鏈接與深層鏈接的區別在于應用鏈接只能處理 HTTP 模式，而深層鏈接可以處理任何模式。

不同于以前的版本，Android 12 將始終為未驗證的鏈接打開默認瀏覽器。這可能是應用鏈接在行為方面最重要的變更。Android 12 還引入了逐條鏈接驗證，因此，如果存在任何服務器端集成或配置錯誤，將僅限于未通過驗證的鏈接，您可以使用新 DomainVerificationManager API 檢查域名驗證狀態，并在需要時將用戶帶到「設置」以便批準應用使用的域名。如需了解詳情，請參閱 Android 開發者網站—— 驗證 Android 應用鏈接。

△ 使用應用鏈接繞過消歧對話框直達已安裝應用

兼容性框架工具

現在我們已了解 Android 12 中的新功能和變更，下面我們來看看讓應用兼容的測試和工具。在 Android 11 中我們引入了兼容性框架工具以便針對變更更輕松地測試和調試應用。有了這些工具您可以單獨打開和關閉某個重大變更并評估其對應用的影響。通過這種方式，您可以一次只針對一項行為變更進行隔離和測試，或輕松啟用 targetSDK 對應的變更。

△ 開發者選項 > 應用兼容性變更

您可以使用開發者選項、logcat 或 adb 命令來檢查當前啟用的行為變更。對于每項行為變更，當應用首次調用受影響的 API 時，系統會輸出一條類似這樣的 logcat 消息:

D CompatibilityChangeReporter: Compat change id reported: 170668199 ;
UID 10265; state: ENABLED

△ Logcat 為某項變更的輸出示例

您可以使用以下 adb 命令列出系統已知的所有兼容性變更 (包括已啟用和禁用的變更) 及其當前的啟用情況。列表中的每項變更都有名稱、供引用的變更 ID 和啟用/禁用狀態。

$ adb shell dumpsys platform-compat

△ 使用 adb 命令列出系統已知的所有兼容性變更

還可以使用以下 adb 命令打開或關閉某個軟件包的變更:

$ adb shell am compat enable|disable|reset <CHANGE_ID | CHANGE_NAME> <PACKAGE_NAME>

△ 使用 adb 命令設置單個應用的變更

在基本測試中無需更改 targetSdkVersion 或重新編譯應用，Android 平臺會自動調整其內部邏輯。由于可單獨打開或關閉變更，因此可逐一進行隔離測試、調試行為變更，或禁用導致問題的單項變更。

請注意，由于只能打開或關閉可調試應用的變更。因此，如果在兼容性框架中未看到您的應用請確保在清單中將應用設置為可調試:

<application
    android:debuggable="true">

△ 在清單文件中將應用設置為可調試

請記住在已簽名的 Android 發布版本上，無法修改影響所有應用的變更的啟用狀態。Android 12 添加了新的 adb 命令來測試和驗證應用的應用鏈接。您可使用這些命令在設備上手動驗證鏈接，或將其添加到持續集成工具鏈中。

// 清除應用任何已經驗證的狀態：
$ adb shell pm set-app-links --package PACKAGE_NAME 0 all
 
// 開始驗證測試：
$ adb shell pm verify-app-links --re-verify PACKAGE_NAME
 
// 查看測試結果：
$ adb shell pm get-app-links PACKAGE_NAME

△ 在 Android 12 中使用這些 adb 命令測試應用鏈接

請務必嘗試使用 Android Studio Arctic Fox 進行開發和測試。我們已添加 lint 檢查來幫助您發現代碼可能受 Android 12 變更影響的地方。例如自定義開屏頁、針對精確位置使用的粗略位置權限、媒體格式等。當然，首先要做的就是設置 Android 12 SDK。

開發者案例

現在我們將展示一些開發者已經適配 Android 12 的成功案例。由于適配了 Android 12，他們的用戶便可以充分利用這種新體驗。

附近設備權限 (僅影響 targetSdkVersion 為 31 的應用)

Withings 的 HealthMate 應用讓用戶能通過藍牙連接和同步 Withings 的設備。Android 12 引入了一項新權限將藍牙掃描與位置權限分離。

△ HealthMate 應用申請附近設備權限

△ HealthMate 應用申請附近設備權限

對我們而言，附近設備權限是 Android 12 中最重要的變更之一。

Withings HealthMate

在隱私層面上，很難向終端用戶解釋位置權限與藍牙的關系。有好幾年，Withings 的團隊不得不在客戶服務主題和教程方面投入成本，以便用戶了解應用需要位置權限才能掃描藍牙的原因。即使做了充分的解釋，該團隊也因申請位置權限而收到了負面反饋。

相比之下，附近設備權限更有效。因為它只在掃描和連接時要求權限。Withings 的工程師提出了一些建議:

• 將檢查和申請新權限的邏輯進行抽象。這有助于控制入口點并盡可能減少測試工作；
• 在所有受支持的 Android 版本上對所有權限檢查進行單元測試；
• 使用 Android 真機并測試不同的升級場景以確保應用正常運行；
• 如果應用在之前的 Android 版本上獲得了位置權限，當用戶升級到 Android 12 時，該應用將自動被授予附近設備權限。

要使用新的附近設備權限，必須在清單文件中聲明 BLUETOOTH_SCAN 權限:

<uses-permission
    android:name="android.permission.BLUETOOTH_SCAN"
    android:usesPermissionFlags="neverForLocation" />

△ 掃描附近設備時應在清單文件中聲明權限

這是一項運行時權限，除了在清單中聲明外，應用還必須在開始掃描設備之前，在運行時檢查并申請此權限。您可以通過將 usesPermissionFlags 屬性聲明為 neverForLocation，來表明不打算使用掃描結果獲取用戶位置。

如果只需要連接到設備，則可以聲明 BLUETOOTH_CONNECT 權限:

<uses-permission
    android:name="android.permission.BLUETOOTH_CONNECT" />

△ 連接設備時應在清單文件中聲明權限

過度滾動效果 (Overscroll Effect，影響所有應用)

在 Android 12 上大多數應用都會有一種新的過度滾動拉伸效果。一些使用 Android 12 的 Beta 用戶在 Signal 應用中滾動瀏覽消息時，注意到了一種奇怪的效果:

△ Signal 應用中的奇怪效果

在 Signal 的案例中，應用支持自定義背景。該應用使用了一種可穿透界面層級的掩蔽算法，每當布局或滾動內容時，Signal 應用都會在屏幕上建立一個消息氣泡投影列表，然后應用將使用這些投影創建一個蒙版，并將其應用于給定的漸變色或純色。

工程團隊很快想出了一個利用 RecyclerView.ItemDecoration 的解決方案。盡早修復過度滾動問題可讓 Signal 應用在新版設備上提供用戶期望的體驗而不影響性能。

△ Signal 修復過度滾動問題后的效果

我們為 Android 12 正式版及時修復了過度滾動的問題并為用戶提供了統一的體驗。

Signal Private Messenger

Signal 團隊提出了一些建議:

• 注意混合模式及其作為附加層的工作原理。Android 12 過度滾動使用附加層來渲染拉伸效果，這可通過不同混合算法生成不同的結果；
• 確保背景由 RecyclerView 渲染；
• 在發布之前，執行一次全面質量檢查，并解決用戶對 Android 12 兼容性的反饋。

Signal 應用是提供愉悅用戶體驗的一個范例。幸運的是，Android 版 Signal Private Messenger 為開源軟件，您可在 GitHub 上查看其修復代碼。

總結

在本文中，我們介紹了 Android 12 給開發者及用戶帶來的最重要的幾項變更，并提出部分建議:

• Android 12 帶來了明顯的視覺更新
• 使用已提供的工具和建議來測試您的應用
• 從其他開發者處獲得啟發

更多變更相關內容，請參閱 Android 開發者網站——Android 12。

最重要的一點，記得測試您的應用并確認其與 Android 12 的兼容性。許多開發者已完成此任務，現在是時候為這些變更做好準備并提供出色的用戶體驗。我們期待在 Android 12 上看到您的應用。

歡迎您 點擊這里 向我們提交反饋，或分享您喜歡的內容、發現的問題。您的反饋對我們非常重要，感謝您的支持！