Android 12 平台包含可能對應用程式造成影響的行為變更。無論 targetSdkVersion 為何，在 Android 12 上執行的所有應用程式都會套用下列行為變更。您應測試應用程式，並視需要修改，以便在適當情況下支援新版本功能。
請務必另外查看只會影響指定 Android 12 為目標版本應用程式的行為變更清單。
使用者體驗
延展過度捲動效果
在搭載 Android 12 以上版本的裝置上，過度捲動事件的視覺行為會隨之改變。
在 Android 11 及以下版本中，過度捲動事件會導致視覺元素產生光暈；在 Android 12 以上版本中，視覺元素在拖曳事件上延展並彈回，在快速滑過事件上延展並彈回。
詳情請參閱為捲動手勢加上動畫效果指南。
應用程式啟動畫面
如果您先前已在 Android 11 以下版本中實作自訂啟動畫面，就必須將應用程式遷移至 SplashScreen API，以確保應用程式從 Android 12 開始都能正確顯示。如果不遷移應用程式，會導致應用程式啟動體驗不佳，或出現非預期的啟動體驗。
如需操作說明，請參閱將現有啟動畫面實作遷移至 Android 12。
此外，從 Android 12 開始，系統會一律為所有應用程式在冷啟動和暖啟動時套用新的 Android 系統預設啟動畫面。根據預設，系統會使用應用程式的啟動器圖示元素和主題的 windowBackground (如果單一顏色) 建構這個系統預設啟動畫面。
詳情請參閱啟動畫面開發人員指南。
網路意圖解析
自 Android 12 (API 級別 31) 起，只有在應用程式已獲準用於該網路意圖中的特定網域時，一般網路意圖才會解析為應用程式中的活動。如果您的應用程式未獲網域核准，網路意圖會改為解析至使用者的預設瀏覽器應用程式。
應用程式可透過下列其中一種方式獲得核准：
使用 Android 應用程式連結驗證網域。
如果應用程式指定 Android 12 以上版本，系統會變更自動驗證應用程式的 Android 應用程式連結的方式。請在應用程式的意圖篩選器中檢查您是否已納入
BROWSABLE類別，並支援https配置。在 Android 12 以上版本中，您可以手動驗證應用程式的 Android 應用程式連結，以測試這個更新後的邏輯對應用程式的影響。
在系統設定中，要求使用者將應用程式與網域建立關聯。
如果應用程式會叫用網路意圖，建議新增提示或對話方塊，要求使用者確認動作。
改善手勢操作的沉浸模式
Android 12 整合了現有行為，讓使用者更容易在沉浸模式下執行手勢操作指令。此外，Android 12 也提供固定式沉浸模式的回溯相容性行為。
Display#getRealSize 和 getRealMetrics：淘汰與限制
Android 裝置有多種不同的板型規格，例如大螢幕、平板電腦和折疊式裝置。為了針對各種裝置適當轉譯內容，應用程式需要判斷螢幕或顯示大小。隨著時間過去，Android 提供不同的 API 來擷取這項資訊。我們在 Android 11 中推出了 WindowMetrics API，並淘汰下列方法：
在 Android 12 中，我們會繼續使用 WindowMetrics，並淘汰下列方法：
為了減少使用 Display API 擷取應用程式邊界的應用程式行為，Android 12 會針對無法完全調整大小的應用程式限制 API 傳回的值。這可能會影響透過 MediaProjection 使用這項資訊的應用程式。
應用程式應使用 WindowMetrics API 查詢視窗邊界，並使用 Configuration.densityDpi 查詢目前的密度。
為了擴大與舊版 Android 的相容性，您可以使用 Jetpack WindowManager 程式庫，其中包含支援 Android 4.0 (API 級別 14) 以上版本的 WindowMetrics 類別。
WindowMetrics 的使用範例
首先，請確認應用程式活動可完全調整大小。
活動應仰賴活動結構定義中的 WindowMetrics 進行任何 UI 相關工作，尤其是 WindowManager.getCurrentWindowMetrics() 或 Jetpack 的 WindowMetricsCalculator.computeCurrentWindowMetrics()。
如果您的應用程式建立 MediaProjection，由於投影會擷取執行投影機應用程式的螢幕分區，因此範圍大小必須正確。
如果應用程式可以完全調整大小，活動內容會傳回正確的邊界，如下所示：
Kotlin
val projectionMetrics: WindowMetrics = activityContext
.getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext
.getSystemService(WindowManager.class).getMaximumWindowMetrics();
如果應用程式無法完全調整大小，則必須透過 WindowContext 執行個體查詢，並使用 WindowManager.getMaximumWindowMetrics() 或 Jetpack 方法 WindowMetricsCalculator.computeMaximumWindowMetrics() 擷取活動邊界的 WindowMetrics。
Kotlin
val windowContext = context.createWindowContext(mContext.display!!,
WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
.maximumWindowMetrics
Java
Context windowContext = context.createWindowContext(mContext.getDisplay(),
WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
.getMaximumWindowMetrics();
使用多視窗模式的所有應用程式
Android 12 則做出多視窗模式的標準行為。
在大螢幕 (sw >= 600dp) 上，無論應用程式設定為何，平台都支援所有應用程式的多視窗模式。如果 resizeableActivity="false"，應用程式會在必要時進入相容模式，以配合顯示尺寸。
在小螢幕 (sw < 600dp) 上，系統會檢查活動的 minWidth 和 minHeight，判斷活動是否能在多視窗模式下執行。如果設為 resizeableActivity="false"，無論最小寬度和高度為何，應用程式都無法在多視窗模式下執行。
詳情請參閱「多視窗模式支援」。
在大型螢幕上預覽相機畫面
相機應用程式通常會假設裝置方向與相機預覽畫面的顯示比例有固定關係。但大螢幕板型規格 (例如摺疊式裝置) 和顯示模式 (例如多視窗和多螢幕) 必須面對這樣的假設。
在 Android 12 中，如果相機應用程式要求特定螢幕方向，且無法調整大小 (resizeableActivity="false")，會自動進入插邊模式，確保相機預覽畫面的方向和長寬比正確。在折疊式裝置和具有相機硬體抽象層 (HAL) 的其他裝置上，為因應相機感應器方向，額外旋轉角度會套用於相機輸出內容，並裁剪相機輸出內容，以符合應用程式的相機預覽畫面。無論裝置螢幕方向和摺疊/展開狀態為何，裁剪和額外旋轉，都能確保相機預覽畫面正確呈現。
前景服務通知的使用者體驗延遲時間
為提供短期執行的前景服務流暢體驗，如果裝置搭載 Android 12 以上版本，可將前景服務通知的顯示延遲 10 秒，但有一些例外狀況。此變更讓短期工作有機會在顯示通知之前完成。
效能
受限制的應用程式待命值區
Android 11 (API 級別 30) 推出了受限制值區做為應用程式待命值區。從 Android 12 開始，這個值區預設為啟用。受限制值區的優先順序是所有值區的最低 (且限制最高)。依優先順序由高到低排列的值區如下：
- 使用中：應用程式目前正在使用或最近剛使用過。
- 工作組：應用程式會定期使用。
- 常用：應用程式經常使用，但不是每天都會使用。
- 很少使用：應用程式不常使用。
- 受限制：應用程式會耗用大量系統資源，或可能有不理想的行為。
除了使用模式外，系統也會考量應用程式行為，判斷是否將應用程式排入受限制值區。
如果應用程式以負責任的方式使用系統資源，就較不可能將應用程式排入受限制值區。此外，如果使用者直接與應用程式互動，系統也會將應用程式排入限制較少的值區。
檢查應用程式是否位於受限制值區
如要確認系統是否已將應用程式排入受限制值區，請呼叫 getAppStandbyBucket()。如果這個方法的傳回值為 STANDBY_BUCKET_RESTRICTED，表示應用程式位於受限制的值區中。
測試受限值區的行為
如要測試應用程式在系統將應用程式排入受限制值區時的行為，您可以手動將應用程式移至該值區。方法是在終端機視窗中執行下列指令：
adb shell am set-standby-bucket PACKAGE_NAME restricted
安全性和隱私權
概略位置
在搭載 Android 12 以上版本的裝置上，使用者可以要求應用程式只能存取大概位置資訊資訊。
如果應用程式會要求 ACCESS_FINE_LOCATION 執行階段權限，您也應要求 ACCESS_COARSE_LOCATION 權限，以便處理使用者授予應用程式大概位置存取權的情況。您應在單一執行階段要求中同時加入這兩項權限。
系統權限對話方塊包含使用者的下列選項，如圖 1 所示：
- 精確位置：授予精確位置資訊的存取權。
- 概略：僅授予大概位置資訊的存取權。
麥克風和相機快速停用鈕
如果是搭載 Android 12 以上版本的受支援裝置，使用者只需按下一個切換鈕，即可啟用或停用裝置上所有應用程式的相機和麥克風存取權。使用者可以透過「快速設定」或系統設定中的「隱私」畫面存取切換選項 (如圖 1 所示)。
進一步瞭解這些切換鈕，以及如何檢查應用程式是否遵循有關 CAMERA 和 RECORD_AUDIO 權限的最佳做法。
麥克風和相機指標
若是搭載 Android 12 以上版本的裝置，當應用程式存取麥克風或相機，狀態列中會顯示相應圖示。
進一步瞭解這些指標，以及如何檢查應用程式是否遵循關於 CAMERA 和 RECORD_AUDIO 權限的最佳做法。
權限套件瀏覽權限
在搭載 Android 12 以上版本的裝置上，如果應用程式指定 Android 11 (API 級別 30) 以上版本，並呼叫下列任一方法，就會根據該應用程式對其他應用程式的套件瀏覽權限，接收一組經過篩選的結果：
已移除 BouncyCastle 實作
Android 12 移除了許多先前淘汰的密碼演算法 BouncyCastle 實作，包括所有 AES 演算法。而是使用這些演算法的 Conscrypt 實作。
如果發生下列任一情況，您的應用程式就會受到這項異動影響：
- 應用程式使用 512 位元的金鑰大小。Conscrypt 不支援這個金鑰大小。如有必要，請更新應用程式的密碼編譯邏輯，使用不同的金鑰大小。
您的應用程式在
KeyGenerator中使用無效的金鑰大小。Conscrypt 實作的KeyGenerator會對鍵參數執行額外的驗證，與 BouncyCastle 相比。舉例來說，Conscrypt 不允許您的應用程式產生 64 位元 AES 金鑰，因為 AES 僅支援 128、192 和 256 位元金鑰。BouncyCastle 可以產生無效大小的鍵，但如果這些金鑰與
Cipher搭配使用，則會失敗。Conscrypt 已提前失敗，使用 12 個位元組以外的大小，初始化 Galois/計數器模式 (GCM) 演算法。Conscrypt 實作
GcmParameterSpec時需要初始化 12 個位元組，而 NIST 的建議是。
剪貼簿存取通知
在 Android 12 以上版本中，當應用程式首次呼叫 getPrimaryClip() 以從其他應用程式存取剪輯資料時，系統會透過浮動式訊息通知使用者這項剪貼簿存取權。
浮動式訊息中的文字含有以下格式：APP pasted from your clipboard.
剪輯片段說明中的文字相關資訊
在 Android 12 以上版本中，getPrimaryClipDescription() 可以偵測下列詳細資料：
- 使用
isStyledText()風格化文字。 - 使用
getConfidenceScore()將網址等不同的文字分類。
應用程式無法關閉系統對話方塊
為提升使用者與應用程式和系統互動時的控制權，自 Android 12 起，ACTION_CLOSE_SYSTEM_DIALOGS 意圖動作會遭到淘汰。當應用程式嘗試叫用包含這項動作的意圖時，除了少數特殊情況外，系統會根據應用程式的目標 SDK 版本，執行下列其中一項操作：
- 如果應用程式指定 Android 12 或以上版本，就會發生
SecurityException。 如果您的應用程式指定 Android 11 (API 級別 30) 以下版本，則系統不會執行意圖，且 Logcat 中會顯示下列訊息：
E ActivityTaskManager Permission Denial: \ android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \ com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \ dropping broadcast.
例外狀況
在下列情況中，應用程式仍可關閉 Android 12 以上版本的系統對話方塊：
- 應用程式正在執行檢測設備測試。
您的應用程式指定 Android 11 以下版本，並在通知導覽匣上方顯示一個視窗。
您的應用程式指定 Android 11 以下版本為目標。此外，使用者可能會使用通知的動作按鈕與通知互動，且您的應用程式正在處理服務或廣播接收器來回應該使用者操作。
應用程式指定 Android 11 以下版本，且具備有效的無障礙服務。如果您的應用程式指定 Android 12 版本為目標，且想關閉通知列，請改用
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE無障礙動作。
已封鎖不受信任的觸控事件
為維護系統安全並提供良好的使用者體驗，Android 12 會防止應用程式利用觸控事件，避免應用程式以不安全的方式掩蓋應用程式。也就是說，系統會封鎖通過特定視窗的觸控動作，但有些例外。
受影響的應用程式
這項變更會影響選擇允許輕觸通過視窗的應用程式 (例如使用 FLAG_NOT_TOUCHABLE 標記)。以下列舉幾個例子：
- 需要
SYSTEM_ALERT_WINDOW權限的疊加層 (例如使用TYPE_APPLICATION_OVERLAY的視窗)，以及使用FLAG_NOT_TOUCHABLE旗標的視窗。 - 使用
FLAG_NOT_TOUCHABLE旗標的活動視窗。
例外狀況
在下列情況中，可以使用「直通」觸控：
- 應用程式內互動：應用程式會顯示重疊元素，且只會在使用者與應用程式互動時顯示。
信任的視窗。這類視窗包括但不限於：
完全透明的視窗。視窗的
alpha屬性為 0.0。充足的半透明系統警示期。當組合的不透明度小於或等於系統的觸控不透明度上限時，系統會認為一組系統快訊視窗足以提供足夠的半透明。在 Android 12 中，這個透明度上限預設為 0.8。
偵測是否有不受信任的觸控功能封鎖
如果系統封鎖觸控動作，Logcat 會記錄下列訊息：
Untrusted touch due to occlusion by PACKAGE_NAME
測試變更
搭載 Android 12 以上版本的裝置，預設會封鎖不信任的觸控動作。如要允許不受信任的觸控動作，請在終端機視窗中執行下列 ADB 指令：
# A specific app adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps # If you'd still like to see a Logcat message warning when a touch would be # blocked, use 1 instead of 0. adb shell settings put global block_untrusted_touches 0
如要將行為還原為預設 (封鎖不受信任的觸控動作)，請執行下列指令：
# A specific app adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps adb shell settings put global block_untrusted_touches 2
活動生命週期
按下返回按鈕時，根啟動器活動不會再完成
Android 12 會變更系統 Back 在工作根按下啟動器活動時的預設處理方式。在舊版中，返回按下返回按鈕後，系統會完成這些活動。在 Android 12 中，系統現在會將活動及其任務移至背景，而非完成活動。使用主畫面按鈕或手勢離開應用程式時，新行為符合目前行為。
對大多數應用程式而言，這項變更表示使用返回瀏覽應用程式的使用者能夠更快從暖狀態恢復應用程式，而不必從冷狀態完全重新啟動應用程式。
我們建議您利用這項異動來測試應用程式。如果您的應用程式目前覆寫了 onBackPressed() 以處理返回導覽並完成 Activity，請將實作更新為透過 super.onBackPressed() 呼叫，而不是完成作業。呼叫 super.onBackPressed() 會視情況將活動及其任務移至背景，並為跨應用程式使用者提供更一致的瀏覽體驗。
另請注意，一般來說，我們建議使用 AndroidX Activity API 提供自訂返回瀏覽功能，而非覆寫 onBackPressed()。如果沒有元件攔截系統返回按下按鈕，AndroidX Activity API 會自動延遲至適當的系統行為。
圖形和圖片
改善刷新率切換功能
在 Android 12 中，無論螢幕是否支援順利改用新的刷新率，使用 setFrameRate() 都會發生刷新率變化，流暢的轉場是指沒有任何視覺幹擾的情況，例如一或兩秒的黑色畫面。先前如果螢幕不支援流暢轉換，通常會在呼叫 setFrameRate() 後繼續使用相同的刷新率。您可以呼叫 getAlternativeRefreshRates()，確認是否能順利轉換至新的重新整理作業。一般來說，重新整理頻率切換完成後，系統會呼叫回呼 onDisplayChanged()，但對於某些外部連結的螢幕，系統會在不流暢轉換時呼叫回呼。
以下為實作這項功能的範例：
Kotlin
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. val refreshRates = this.display?.mode?.alternativeRefreshRates val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate) // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)
Java
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. Display display = context.getDisplay(); // API 30+ Display.Mode mode = display.getMode(); float[] refreshRates = mode.getAlternativeRefreshRates(); boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate); // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);
連線能力
Passpoint 更新
Android 12 新增了下列 API：
isPasspointTermsAndConditionsSupported()：條款及細則是 Passpoint 功能，可讓您在網路部署項目中，透過安全的 Passpoint 網路，取代不安全的網頁認證入口。在必須接受條款及細則的情況下，使用者會看到通知。如果應用程式建議受條款及細則管制的 Passpoint 網路，就必須先呼叫這個 API，確保裝置支援這項功能。如果裝置不支援這項功能，將無法連線至這個網路，因此系統必須建議使用替代或舊版網路。isDecoratedIdentitySupported()：對具有前置字串裝飾的網路進行驗證時，網路運算子可以更新網路存取 ID (NAI)，透過 AAA 網路中的多個 Proxy 執行明確轉送 (詳情請參閱 RFC 7542)。Android 12 會實作這項功能，以符合 PPS-MO 擴充功能的 WBA 規格。如果應用程式建議的 Passpoint 網路需要經過裝飾的身分，您必須先呼叫這個 API，以確保裝置支援此功能。如果裝置不支援這項功能，則系統不會裝飾身分識別，網路驗證可能會失敗。
如要建立 Passpoint 建議，應用程式必須使用 PasspointConfiguration、Credential 和 HomeSp 類別。這些類別說明的 Passpoint 設定檔，請參閱 Wi-Fi Alliance Passpoint 規範。
詳情請參閱適用於網際網路連線的 Wi-Fi Suggestion API。
更新非 SDK 介面限制
基於與 Android 開發人員合作及最新的內部測試，Android 12 包含更新後的受限制非 SDK 介面清單。在限制非 SDK 介面之前，我們盡可能確保公開替代方案的可得性。
如果您的應用程式並不是以 Android 12 為目標版本，則此處所述的某些變更可能不會立即對您造成影響。不過，雖然您目前可使用某些非 SDK 介面 (視應用程式的目標 API 級別而定)，但使用任何非 SDK 方法或欄位時，一律可能會導致應用程式停止運作。
如果不確定應用程式是否使用非 SDK 介面，可對應用程式進行測試以便確認。如果您的應用程式仰賴非 SDK 介面，則建議您開始規劃遷移至 SDK 替代方案。我們瞭解有些應用程式可使用非 SDK 介面運作。如果您除了為應用程式中的某個功能使用非 SDK 介面外，已別無他法，則應要求新的公用 API。
如要進一步瞭解此 Android 版本中的變更，請參閱 Android 12 的非 SDK 介面限制更新。如要進一步瞭解非 SDK 介面的一般資訊，請參閱非 SDK 介面的限制。