The Android 15 Beta is now available. Try it out today and let us know what you think!

本頁面由 Cloud Translation API 翻譯而成。

行為變更：指定 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. 將應用程式的 targetSdkVersion 變更為 S，以啟用新行為。
2. 重新編譯。
3. 在搭載 Android 12 的裝置或模擬器上安裝應用程式。
測試使用自訂檢視畫面的所有通知，確保通知顯示你的外觀呈現出來的成果在測試期間，請將以下考量因素納入考量並進行必要的調整：
- 自訂資料檢視的維度已有異動。一般來說提供自訂通知的時間不到以往。在收合的自訂內容的高度上限已從 106dp 設為 48 dp此外，水平空間也較少。
- 指定 Android 12 為目標的應用程式可展開所有通知。通常這表示如果您使用 setCustomContentView 請一併使用 setBigCustomContentView 確保收合和展開狀態一致
- 請先開啟「看路提醒」功能別忘了，將通知管道的重要性提高為「高」(開啟彈出式視窗畫面)。

Android 應用程式連結驗證異動

在所有指定 Android 12 以上版本的應用程式中，系統會 Android 應用程式連結的驗證。這些變更改善應用程式連結體驗的穩定性讓應用程式開發人員和使用者擁有掌控權

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

您也可以手動驗證來測試宣告是否可靠。

改善子母畫面行為

Android 12 針對子母畫面 (PiP) 模式改善行為，和針對兩個手勢的轉場動畫建議外觀改善導覽及元素式導覽

請參閱子母畫面改善服務可能不準確或不適當

吐司重新設計

在 Android 12 中，浮動式訊息檢視畫面我們重新設計了浮動式訊息現在限制為兩行文字，並顯示應用程式圖示。

圖中的 Android 裝置顯示彈出的浮動式訊息，而訊息內的應用程式圖示旁顯示「正在傳送郵件」

詳情請參閱「浮動式訊息總覽」。

安全性和隱私權

大概位置

在搭載 Android 12 以上版本的裝置上，使用者可以提出要求大概位置提升應用程式的準確率。

WebView 中的新型 SameSite Cookie

Android 的 WebView 元件是以 Chromium 為基礎 Google Chrome 瀏覽器採用的開放原始碼專案。Chromium 推出調整第三方 Cookie 的處理方式，以提高安全性並並為使用者提供更公開透明的資訊及更多控制權。自 Android 12 起，當應用程式指定為目標時，WebView也會納入這些變更 Android 12 (API 級別 31) 以上版本。

Cookie 的 SameSite 屬性可控制 Cookie 能否與任何或只用於同網站要求下列保護隱私權異動可改善第三方 Cookie 的預設處理方式防止非預期的跨網站共用：

不含 SameSite 屬性的 Cookie 會視為 SameSite=Lax。
具有 SameSite=None 的 Cookie 也必須指定 Secure 屬性，表示就需要安全內容，且應該透過 HTTPS 傳送。
系統會將網站的 HTTP 和 HTTPS 版本連結視為跨網站因此，除非將 Cookie 正確標示為 SameSite=None; Secure。

對開發人員而言，通用指南是辨識跨網站 Cookie 保持關鍵使用者流程的依附元件，並確保 SameSite 屬性 (在必要時明確設定適當的值)。您必須明確指定可在所有網站上運作的 Cookie，或。

如需網頁開發人員這些變更的完整指南，請參閱 SameSite Cookie 一文已說明和刻意安排 SameSite。

在應用程式中測試 SameSite 行為

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

留意登入和嵌入內容的問題，以及登入流程及其他驗證流程，也就是使用者透過不安全的導向安全網頁

如要使用 WebView 測試應用程式，請務必為如要測試應用程式，請完成下列任一步驟：

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

這個方法可讓您在任何搭載 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 更新頁面。如果您在 WebView 中發現錯誤你也可以在公開的 Chromium 問題中回報追蹤器。

動作感應器有速率限制

為了保護使用者的相關機密資訊 (如果應用程式鎖定在 Android 12 以上版本中，系統會對重新整理作業設下限制特定動作感應器和位置感應器提供的資料速率。

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

應用程式休眠

Android 12 會進一步擴充自動重設權限的功能行為這是 Android 11 (API 級別 30) 所引進的功能。如果應用程式指定 Android 12 和使用者未與應用程式互動的時間系統會自動重設所有授予的權限，並將應用程式加入 hibernation 狀態。

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

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

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 以上版本

系統會顯示下列訊息：

資訊清單檔案會顯示以下 Lint 警告：

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

嘗試編譯應用程式時，以下建構錯誤訊息會顯示：

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 物件建立應用程式這項額外要求可以提升應用程式的安全性。

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

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

啟動不安全的意圖

為提昇平台安全性，Android 12 以上版本提供針對偵測出不安全啟動項目的偵錯功能意圖。時間系統偵測到這類不安全的啟動情形違反 StrictMode 政策。

成效

前景服務啟動限制

指定 Android 12 以上版本的應用程式無法啟動前景以及 GCP 中運作的背景但少了一些案件。如果應用程式嘗試在背景中，則發生例外狀況 (少數特殊情況除外)。

考慮使用 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() 內部 IP 位址

應用程式嘗試透過服務或廣播接收器啟動活動時作為通知彈跳床，系統會防止活動，下列訊息會顯示在 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」文字。這個區段包含所需的資訊，有助於識別啟動程式的元件顯示這則通知

請更新應用程式

如果您的應用程式會從以下類型的服務或廣播接收器啟動活動：通知彈跳床，請完成下列遷移步驟：

建立 PendingIntent 物件。與使用者輕觸通知。
使用您在上一個步驟中建立的 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 設定適用的格式不同這種格式您必須在 Google 雲端硬碟備份和 D2D 之間明確傳輸檔案，方法是要求您為雲端備份和 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 設定時，系統會忽略指向舊設定的 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 只有單一網路因此，API 的行為在在 Android 12 以上版本中執行下列操作：

如果只有一個 Wi-Fi 網路可用，系統會傳回其 WifiInfo。
如有多個 Wi-Fi 網路可用，且發起通話的應用程式觸發了點對點連線，與對等裝置相對應的 WifiInfo 為。
如有多個 Wi-Fi 網路可用，但發起通話的應用程式並未觸發點對點連線，這是主要透過網際網路提供的連線傳回 WifiInfo。

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

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

Kotlin

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
    ...
  }
}

Java

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;
    ...
  }
  ...
};

mDNSResponseer 原生 API

Android 12 會在應用程式可使用 mDNSResponseer 原生 API。過去，當應用程式在網路上註冊服務時並呼叫 getSystemService() 方法，系統才會啟動 mDNSResponseer Daemon，應用程式尚未呼叫任何 NsdManager 方法。接著，Daemon 訂閱了傳送至所有節點的多點傳播群組，導致系統喚醒更長時間並且使用額外電源為了盡可能減少電池用量，請使用 Android 12 之後，系統就會只在需要時才啟動 mDNSResponseer Daemon ，並在之後停止

這項變更會影響 mDNSResponseer Daemon 的可用性，因此應用程式我們假設 mDNSResponseer Daemon 在呼叫 getSystemService() 方法可能會接收來自系統的訊息： mDNSResponseer Daemon 無法使用。使用 NsdManager 但未採用使用 mDNSResponseer 原生 API 則不受此變更的影響。

供應商程式庫

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

非 NDK 原生共享程式庫無法存取由晶片供應商或裝置製造商提供的在預設情況下，如果應用程式指定 Android 12 (API 級別 31) 以上版本為目標。只有使用 <uses-native-library> 標記之前。

如果應用程式指定的是 Android 11 (API 級別 30) 以下版本，則不必提供 <uses-native-library> 標記。在這個例子中，任何原生共用無論程式庫是否為 NDK 程式庫，皆可存取程式庫。

更新非 SDK 限制

Android 12 內含最新的受限制非 SDK 清單介面是以與 Android 開發人員合作為基礎，並採用內部測試。我們會盡可能確保公開的替代方案，然後再限制非 SDK 介面使用

如果您的應用程式並不是以 Android 12 為目標版本，則其中某些變更可能無法立即對您造成影響不過，雖然您目前可以使用非 SDK 介面 (視應用程式的目標 API 級別而定)，使用任何非 SDK 方法或欄位，都有很高的風險應用程式。

如果不確定應用程式是否使用非 SDK 介面，可以測試應用程式讓我們一探究竟。如果您的應用程式仰賴非 SDK 介面，建議您著手規劃轉換至 SDK 替代方案我們瞭解有些應用程式使用非 SDK 介面的有效用途。如果您找不到替代選項針對應用程式中的某個功能使用非 SDK 介面，則應要求新的公用 API

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