行為變更：指定 Android 12 為目標的應用程式

和先前版本一樣，Android 12 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 12 以上版本的應用程式。如果您的應用程式指定 Android 12，建議您視情況修改應用程式，以支援這些行為。

此外，請務必查看影響所有在 Android 12 上執行的應用程式行為變更清單。

使用者體驗

自訂通知

Android 12 會變更完全自訂通知的外觀和行為。 先前，自訂通知可使用整個通知區域，並提供自己的版面配置和樣式。這導致了反模式，可能會讓使用者感到困惑，或在不同裝置上造成版面配置相容性問題。

如果應用程式指定 Android 12 為目標平台，附帶自訂內容檢視畫面的通知將不再使用整個通知區域，系統會改為套用標準範本。這個範本可確保自訂通知與所有狀態的其他通知採用相同的裝飾設定，例如通知圖示和展開功能 (在收合狀態下)，以及通知圖示、應用程式名稱和收合功能 (在展開狀態下)。這個行為與 Notification.DecoratedCustomViewStyle 的行為幾乎相同。

Android 12 採用這種做法，讓所有通知在視覺上保持一致，方便使用者掃描，並提供可探索的熟悉通知展開方式。

下圖顯示標準範本中的自訂通知：

下列範例顯示自訂通知在收合和展開狀態下的顯示方式：

Android 12 的這項變更會影響定義 Notification.Style 自訂子類別的應用程式，或是使用 Notification.Builder 的 setCustomContentView(RemoteViews)、setCustomBigContentView(RemoteViews) 和 setCustomHeadsUpContentView(RemoteViews) 方法的應用程式。

如果您的應用程式使用全自訂通知，建議盡快使用新範本進行測試。

1. 啟用自訂通知變更：

   1. 將應用程式的 targetSdkVersion 變更為 S，即可啟用新行為。
   2. 重新編譯。
   3. 在搭載 Android 12 的裝置或模擬器上安裝應用程式。

2. 測試所有使用自訂檢視區塊的通知，確保通知在陰影中顯示的樣貌符合預期。測試時，請考量下列事項並進行必要調整：

   • 自訂檢視區塊的尺寸已變更。一般來說，自訂通知可用的高度比以往更小。在摺疊狀態下，自訂內容的高度上限已從 106dp 降至 48dp。此外，橫向空間也較小。

   • 凡是指定 Android 12 的應用程式，所有通知都可以展開。 一般來說，如果您使用 setCustomContentView，也建議使用 setBigCustomContentView，確保收合和展開狀態一致。

   • 為確保「注意安全」狀態符合預期，請務必將通知管道的重要性提升至「高」(在畫面上彈出)。

Android 應用程式連結驗證異動

如果應用程式指定 Android 12 以上版本，系統會對Android 應用程式連結的驗證方式做出幾項變更，這些變更可提供更穩定的應用程式連結體驗，讓應用程式開發人員和使用者手上有更多掌控權。

如果您依賴 Android 應用程式連結驗證在應用程式中開啟網頁連結，請檢查您新增意圖篩選器以進行 Android 應用程式連結驗證時，是否使用正確格式。特別是請確認這些意圖篩選器包含 BROWSABLE 類別，並支援 https 結構。

您也可以手動驗證應用程式的連結，測試宣告的可靠性。

改善子母畫面行為

Android 12 針對子母畫面 (PiP) 模式導入行為改善措施，並建議針對手勢操作和元素式操作的轉場動畫進行外觀改善。

詳情請參閱「子母畫面功能改善」。

重新設計浮動式訊息

在 Android 12 中，Toast 檢視畫面已重新設計。浮動式訊息現在最多只能顯示兩行文字，並會在文字旁顯示應用程式圖示。

詳情請參閱「Toast 總覽」。

安全性和隱私權

大概位置

在搭載 Android 12 以上版本的裝置上，使用者可以要求應用程式提供大概位置資訊。

WebView 中的新式 SameSite Cookie

Android 的 WebView 元件是以 Chromium 為基礎，這個開放原始碼專案是 Google Chrome 瀏覽器的幕後功臣。Chromium 導入了第三方 Cookie 處理方式的變更，以提供更完善的安全性和隱私權保護，並讓使用者進一步掌握及控管相關情形。自 Android 12 起，如果應用程式指定 Android 12 (API 級別 31) 以上版本，WebView 也會包含這些變更。

Cookie 的 SameSite 屬性會控管 Cookie 是否可隨任何要求傳送，或僅限隨同網站要求傳送。下列隱私權保護異動可改善第三方 Cookie 的預設處理方式，並防範非預期的跨網站共用行為：

• 沒有 SameSite 屬性的 Cookie 會被視為 SameSite=Lax。
• 具有 SameSite=None 的 Cookie 也必須指定 Secure 屬性，也就是說，這類 Cookie 需要安全環境，且應透過 HTTPS 傳送。
• 現在，系統會將網站 HTTP 和 HTTPS 版本之間的連結視為跨網站要求，因此除非 Cookie 適當標示為 SameSite=None; Secure，否則不會傳送。

對開發人員而言，一般指引是找出重要使用者流程中的跨網站 Cookie 依附元件，並確保在需要時，SameSite屬性會明確設定適當的值。您必須明確指定允許跨網站運作的 Cookie，或允許在從 HTTP 移至 HTTPS 的同網站導覽中運作的 Cookie。

如需這些變更的完整網頁開發人員指南，請參閱「SameSite Cookie 說明」和「具結構定義的 SameSite」。

測試應用程式中的 SameSite 行為

如果您的應用程式使用 WebView，或是您管理的網站或服務使用 Cookie，建議在 Android 12 WebView 上測試流程。如果發現問題，可能需要更新 Cookie，才能支援新的 SameSite 行為。

請注意登入和嵌入內容的問題，以及登入流程、購買流程和其他驗證流程，這些流程會讓使用者從不安全的網頁轉移到安全網頁。

如要使用 WebView 測試應用程式，請完成下列任一步驟，為要測試的應用程式啟用新的 SameSite 行為：

• 在WebView 開發人員工具中切換 UI 旗標 webview-enable-modern-cookie-same-site，在測試裝置上手動啟用 SameSite 行為。

  採用這種做法，您就能在搭載 Android 5.0 (API 級別 21) 以上版本 (包括 Android 12) 和 WebView 89.0.4385.0 以上版本的任何裝置上進行測試。

• 請在 targetSdkVersion前編譯應用程式，指定 Android 12 (API 級別 31) 為目標。

  如果採用這種做法，您必須使用搭載 Android 12 的裝置。

如要瞭解如何對 Android 上的 WebView 進行遠端偵錯，請參閱「開始對 Android 裝置進行遠端偵錯」。

其他資源

如要進一步瞭解 SameSite 的新版行為，以及 Chrome 和 WebView 的推出時間，請造訪 Chromium SameSite Updates 頁面。如果在 WebView 或 Chromium 中發現錯誤，可以在公開的 Chromium 問題追蹤器中回報。

動作感應器受到速率限制

為保護使用者可能具有私密性質的資訊，如果您的應用程式指定 Android 12 以上版本，系統會限制特定動作感應器和位置感應器的資料重新整理率。

進一步瞭解感應器速率限制。

應用程式休眠

Android 12 進一步擴充 Android 11 (API 級別 30) 推出的權限自動重設行為。如果應用程式指定的是 Android 12，而使用者已經數個月未與應用程式互動，系統便會自動重設所有已授予的權限，並將應用程式設為「休眠」狀態。

詳情請參閱應用程式休眠指南。

資料存取稽核中的歸因聲明

Android 11 (API 級別 30) 推出的資料存取稽核 API 可讓您根據應用程式的使用情境建立歸因標記。這些標記可協助您判斷應用程式的哪個部分會存取特定類型的資料。

如果應用程式指定 Android 12 以上版本，您必須在應用程式的資訊清單檔案中宣告這些歸因標記。

ADB 備份限制

為保護私人應用程式資料，Android 12 變更了 adb backup 指令的預設行為。如果應用程式指定 Android 12 (API 級別 31) 以上版本，使用者執行 adb backup 指令時，應用程式資料會從裝置匯出的任何其他系統資料中排除。

如果您的測試或開發工作流程依賴使用 adb backup 的應用程式資料，現在可以在應用程式的資訊清單檔案中將 android:debuggable 設為 true，選擇匯出應用程式資料。

更安全的元件匯出功能

如果應用程式指定 Android 12 以上版本，且包含使用意圖篩選器的活動、服務或廣播接收器，您必須為這些應用程式元件明確宣告 android:exported 屬性。

如果應用程式元件包含 LAUNCHER 類別，請將 android:exported 設為 true。在大多數其他情況下，請將 android:exported 設為 false。

以下程式碼片段顯示服務範例，其中包含 android:exported 屬性設為 false 的意圖篩選器：

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Android Studio 中的訊息

如果應用程式包含使用意圖篩選器的活動、服務或廣播接收器，但未宣告 android:exported，系統會顯示下列警告訊息 (視您使用的 Android Studio 版本而定)：

Android Studio 2020.3.1 Canary 11 以上版本

系統會顯示下列訊息：

1. 資訊清單檔案中會顯示下列 Lint 警告：

   When using intent filters, please specify android:exported as well
   

2. 嘗試編譯應用程式時，系統會顯示下列建構錯誤訊息：

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

舊版 Android Studio

如果嘗試安裝應用程式，Logcat 會顯示下列錯誤訊息：

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

待處理意圖的可變動性

如果應用程式指定 Android 12 為目標，您必須為應用程式建立的每個 PendingIntent 物件指定可變動性。這項額外規定可提升應用程式的安全性。

測試待處理意圖可變動性變更

如要判斷應用程式是否缺少可變動性宣告，請在 Android Studio 中尋找下列 Lint 警告：

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

啟動不安全的意圖

為提升平台安全性，Android 12 以上版本提供偵錯功能，可偵測不安全的意圖啟動作業。系統偵測到這類不安全的啟動作業時，就會發生 StrictMode 違規情形。

成效

前景服務啟動限制

如果應用程式指定 Android 12 以上版本，就無法在背景執行時啟動前景服務，少數特殊情況除外。如果應用程式嘗試在背景執行時啟動前景服務，就會發生例外情況 (少數特殊情況除外)。

在應用程式於背景執行的情況下，建議您使用 WorkManager 安排及啟動加急作業。如要完成使用者要求且須及時處理的動作，請在確切的鬧鐘時間內啟動前景服務。

精確鬧鐘權限

為鼓勵應用程式節省系統資源，指定 Android 12 以上版本且設定精確鬧鐘的應用程式，必須具備「鬧鐘與提醒」功能存取權，這項功能會顯示在系統設定的「特殊應用程式存取權」畫面中。

如要取得這項特殊應用程式存取權，請在資訊清單中要求 SCHEDULE_EXACT_ALARM 權限。

精確鬧鐘只能用於面向使用者的功能。進一步瞭解設定精確鬧鐘的適用情況。

停用行為變更

準備讓應用程式以 Android 12 為目標平台時，您可以暫時在可偵錯的建構變體中停用行為變更，以利進行測試。如要這樣做，請完成下列任一工作：

• 在「開發人員選項」設定畫面中，選取「應用程式相容性變更」。在隨即顯示的畫面上輕觸應用程式名稱，然後關閉「REQUIRE_EXACT_ALARM_PERMISSION」。

• 在開發機器的終端機視窗中，執行下列指令：

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

通知彈跳床限制

使用者與通知互動時，部分應用程式會啟動應用程式元件，最終啟動使用者查看及互動的活動。這個應用程式元件又稱為「通知彈跳床」。

為改善應用程式效能和使用者體驗，目標 Android 12 以上版本的應用程式無法透過服務，或可當成通知彈跳床的廣播接收器啟動活動。換句話說，使用者輕觸通知或通知中的動作按鈕後，您的應用程式就無法在服務或廣播接收器中呼叫 startActivity()。

如果應用程式嘗試從做為通知彈跳床的服務或廣播接收器啟動活動，系統會禁止啟動活動，並在 Logcat 中顯示下列訊息：

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

找出做為通知彈跳床的應用程式元件

測試應用程式時，輕觸通知後，您可以找出應用程式中做為通知彈跳床的服務或廣播接收器。方法是查看下列終端機指令的輸出內容：

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

輸出內容的某個部分包含「NotifInteractionLog」文字。本節包含的資訊可用於識別因輕觸通知而啟動的元件。

請更新應用程式

如果應用程式是透過做為通知彈跳床的服務或廣播接收器啟動活動，請完成下列遷移步驟：

1. 建立與 PendingIntent 物件相關聯的活動，使用者輕觸通知後就會看到該活動。
2. 使用您在上一個步驟中建立的 PendingIntent 物件，建構通知。

如要識別活動來源 (例如執行記錄作業)，請在發布通知時使用額外資訊。如要集中記錄，請使用 ActivityLifecycleCallbacks 或 Jetpack 生命週期觀察器。

切換行為

測試應用程式的可偵錯版本時，您可以使用 NOTIFICATION_TRAMPOLINE_BLOCK 應用程式相容性標記，啟用及停用這項限制。

備份與還原

對於指定並運作於 Android 12 (API 級別 31) 的應用程式，備份與還原作業的運作方式有所變更。Android 備份與還原功能有兩種形式：

• 雲端備份：使用者資料會儲存在使用者的 Google 雲端硬碟中，以便日後在該裝置或新裝置上還原。
• 裝置對裝置 (D2D) 轉移：使用者資料會直接從舊裝置傳送到新裝置，例如使用傳輸線。

如要進一步瞭解如何備份及還原資料，請參閱「使用自動備份功能備份使用者資料」和「使用 Android Backup Service 備份鍵/值組合」。

D2D 傳輸功能異動

如果應用程式在 Android 12 以上版本上執行，且指定 Android 12 以上版本：

• 使用 XML 設定機制指定納入和排除規則不會影響 D2D 轉移，但仍會影響雲端備份和還原 (例如 Google 雲端硬碟備份)。如要指定 D2D 轉移的規則，請使用下一節介紹的新設定。

• 在部分裝置製造商的裝置上，指定 android:allowBackup="false" 會停用 Google 雲端硬碟備份功能，但不會停用應用程式的 D2D 轉移功能。

新的納入和排除格式

在指定 Android 12 以上版本的裝置上執行的應用程式，會使用不同格式的 XML 設定。這個格式會要求您分別為雲端備份和 D2D 轉移作業指定納入和排除規則，明確區分 Google 雲端硬碟備份和 D2D 轉移作業。

您也可以選擇使用這項功能指定備份規則，如果裝置搭載 Android 12 以上版本，系統會忽略先前使用的設定。搭載 Android 11 以下版本的裝置仍須使用舊版設定。

XML 格式異動

以下是 Android 11 以下版本中，備份與還原設定所用的格式：

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

以下以粗體顯示格式變更。

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

詳情請參閱「使用自動備份功能備份使用者資料」指南中的相應章節。

應用程式的資訊清單標記

在資訊清單檔案中使用 android:dataExtractionRules 屬性，將應用程式指向新的 XML 設定。指向新的 XML 設定時，搭載 Android 12 以上版本的裝置會忽略指向舊設定的 android:fullBackupContent 屬性。以下程式碼範例顯示新的資訊清單檔案項目：

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

連線能力

藍牙權限

Android 12 推出了 BLUETOOTH_SCAN、BLUETOOTH_ADVERTISE 和 BLUETOOTH_CONNECT 權限。如果應用程式以 Android 12 為目標平台，這些權限可讓應用程式與藍牙裝置互動，特別是無需存取裝置位置資訊的應用程式。

如要準備指定 Android 12 以上版本的裝置，請更新應用程式的邏輯。請宣告較新的藍牙權限組合，而非宣告舊版藍牙權限組合。

同時進行點對點連線和網際網路連線

如果應用程式指定 Android 12 (API 級別 31) 以上版本，支援並行對等互連和網際網路連線的裝置，可以同時與對等互連裝置和主要網際網路供應網路維持 Wi-Fi 連線，提供更流暢的使用者體驗。如果應用程式指定 Android 11 (API 級別 30) 以下版本，仍會採用舊版行為，也就是先中斷主要 Wi-Fi 網路，再連線至對等互連裝置。

相容性

WifiManager.getConnectionInfo() 只能傳回單一網路的 WifiInfo。因此，Android 12 以上版本已針對 API 行為做出下列變更：

• 如果只有單一 Wi-Fi 網路可用，系統會傳回其 WifiInfo。
• 如果有多個可用的 Wi-Fi 網路，且通話應用程式觸發了對等互連連線，系統會傳回對應對等互連裝置的 WifiInfo。
• 如果有多個可用的 Wi-Fi 網路，且通話應用程式未觸發對等互連連線，系統會傳回主要提供網際網路連線的 WifiInfo。

為在支援雙重並行 Wi-Fi 網路的裝置上提供更優質的使用者體驗，建議所有應用程式 (尤其是會觸發對等互連連線的應用程式) 遷移，不要再呼叫 WifiManager.getConnectionInfo()，改為使用 NetworkCallback.onCapabilitiesChanged() 取得與用於註冊 NetworkCallback 的 NetworkRequest 相符的所有 WifiInfo 物件。getConnectionInfo() 已於 Android 12 淘汰。

以下程式碼範例說明如何在 NetworkCallback 中取得 WifiInfo：

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder 原生 API

Android 12 變更了應用程式何時可使用 mDNSResponder 原生 API 與 mDNSResponder 精靈互動。先前，當應用程式在網路上註冊服務並呼叫 getSystemService() 方法時，即使應用程式尚未呼叫任何 NsdManager 方法，系統的 NSD 服務仍會啟動 mDNSResponder 精靈。精靈隨後會將裝置訂閱至所有節點的多點播送群組，導致系統更頻繁地喚醒並使用額外電力。為盡量減少耗電量，在 Android 12 以上版本中，系統現在只會在 NSD 事件需要時啟動 mDNSResponder 精靈，並在之後停止。

這項變更會影響 mDNSResponder 精靈的可用時間，因此假設 mDNSResponder 精靈會在呼叫 getSystemService() 方法後啟動的應用程式，可能會收到系統傳送的訊息，指出 mDNSResponder 精靈無法使用。如果應用程式使用 NsdManager，但未使用 mDNSResponder 原生 API，就不會受到這項異動影響。

供應商程式庫

供應商提供的原生共用程式庫

非 NDK 原生共用程式庫 根據預設，如果應用程式是指定 Android 12 (API 級別 31) 以上版本為目標平台，無法存取由晶片供應商或裝置製造商提供的非 NDK 原生共用程式庫。只有使用 <uses-native-library> 標記明確要求時，才能存取這些程式庫。

如果應用程式指定 Android 11 (API 級別 30) 以下版本，則不需要 <uses-native-library> 標記。在這種情況下，任何原生共用程式庫均可存取，無論其是否為 NDK 程式庫。

更新非 SDK 限制

基於與 Android 開發人員合作及最新的內部測試，Android 12 包含更新後的受限制非 SDK 介面清單。在限制非 SDK 介面之前，我們盡可能確保公開替代方案的可得性。

如果您的應用程式並不是以 Android 12 為目標版本，則此處所述的某些變更可能不會立即對您造成影響。雖然您目前可以使用某些非 SDK 介面 (視應用程式的目標 API 級別而定)，但使用任何非 SDK 方法或欄位時，均可能面臨應用程式故障的高度風險。

如果不確定應用程式是否使用非 SDK 介面，可對應用程式進行測試以便確認。如果您的應用程式仰賴非 SDK 介面，則建議您開始規劃遷移至 SDK 替代方案。我們瞭解有些應用程式可使用非 SDK 介面運作。如果您除了為應用程式中的某個功能使用非 SDK 介面外，已別無他法，則應要求新的公用 API。

如要進一步瞭解此 Android 版本中的變更，請參閱「Android 12 的非 SDK 介面限制更新」。如要進一步瞭解非 SDK 介面的一般資訊，請參閱「非 SDK 介面的限制」。