Android 12 平台包含的行為變更:
對應用程式的影響。下列行為變更會套用至所有應用程式
在 Android 12 上執行,無論 targetSdkVersion
為何。請
然後視需要修改應用程式,以便正確支援這些功能。
請務必檢閱影響應用程式的行為變更清單 針對 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 12 以上版本的應用程式中,系統 變更自動 驗證 請點選應用程式的 Android 應用程式連結在應用程式的意圖中 篩選器, 檢查是否納入
BROWSABLE
類別,並支援https
配置。在 Android 12 以上版本中, 可以手動 驗證 應用程式的 Android 應用程式連結,藉此測試這個更新過的邏輯對 應用程式。
要求使用者將應用程式與 網域 更改設定
如果您的應用程式會叫用網路意圖,請考慮新增 確認動作
改善手勢操作的沉浸模式
Android 12 整合了現有行為,讓使用者更容易 在沉浸式體驗中執行手勢操作指令 模式。於 此外,Android 12 針對固定式設計提供回溯相容性行為 沉浸式體驗 模式。
Display#getRealSize 和 getRealMetrics:淘汰與限制
Android 裝置有多種不同的板型規格,例如:大型
螢幕、平板電腦和摺疊式裝置為了針對各個
應用程式就必須決定螢幕或顯示大小。隨著新版本
Android 提供不同的 API 來擷取這項資訊。在 Android 中
11,我們推出了 WindowMetrics
淘汰了下列方法:
在 Android 12 中,我們會繼續使用 WindowMetrics
,
淘汰這些方法:
在使用 Display API 擷取
應用程式的邊界,Android 12 會限制 API 傳回的值
無法完全調整大小的應用程式這可能影響
正在搭配 MediaProjection
使用這項資訊的應用程式。
應用程式應使用 WindowMetrics
API 查詢
視窗,以及 Configuration.densityDpi
來查詢目前的密度。
如要提升與舊版 Android 的相容性,您可以使用
Jetpack WindowManager
程式庫
包含 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
查詢
來擷取活動範圍的 WindowMetrics
WindowManager.getMaximumWindowMetrics()
敬上
或者 Jetpack 方法
WindowMetricsCalculator.computeMaximumWindowMetrics()
。
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 已提前失敗,您使用其他大小將 Galois/計數器模式 (GCM) 加密 大於 12 個位元組Conscrypt 實作
GcmParameterSpec
需要 符合 NIST 建議的 12 個位元組初始化。
剪貼簿存取通知
在 Android 12 以上版本中,當應用程式呼叫
getPrimaryClip()
敬上
以存取其他來源的
app,並且首次傳送浮動式訊息
通知使用者此剪貼簿的存取權。
浮動式訊息中的文字包含下列格式:
APP pasted from your clipboard.
剪輯片段說明中的文字相關資訊
在 Android 12 以上版本中,getPrimaryClipDescription()
可以
偵測下列詳細資料:
- 風格化文字,使用
isStyledText()
。 - 使用不同文字分類文字 (例如網址)
getConfidenceScore()
。
應用程式無法關閉系統對話方塊
為了加強使用者與應用程式和系統互動時的控制權,
ACTION_CLOSE_SYSTEM_DIALOGS
敬上
意圖動作已於 Android 12 淘汰。只有少數
特殊情況。如果應用程式嘗試叫用
包含這個動作的意圖
系統會根據應用程式的目標 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 裝置的裝置上封鎖不信任的觸控動作 搭載 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 會變更系統返回按下啟動器時的預設處理方式 授予其工作根層級的活動在先前的版本中,系統 在按下「返回」按鈕時,就會完成這些活動。在 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) 執行透過多個 Proxy 執行的明確轉送 的 AAA 網路 (請參閱 專用 RFC 7542 。Android 12 會實作這項功能,以符合 WBA 的 PPS-MO 擴充功能。 如果應用程式建議使用的 Passpoint 網路為需要裝飾的身分,就必須這麼做 請先呼叫此 API,確認裝置支援此功能。如果 裝置不支援這項功能,系統將不會裝飾這個身分 網路驗證可能會失敗
如要建立 Passpoint 建議,應用程式必須使用
PasspointConfiguration
、
Credential
和
HomeSp
類別。這些
類別會說明 Passpoint 設定檔 (定義於 Wi-Fi Alliance)
Passpoint
規格。
詳情請參閱適用於網際網路連線的 Wi-Fi Suggestion API。
更新非 SDK 介面限制
Android 12 內含最新的受限制非 SDK 清單 介面是以與 Android 開發人員合作為基礎,並採用 內部測試。我們會盡可能確保公開的替代方案 ,然後再限制非 SDK 介面使用
如果您的應用程式並不是以 Android 12 為目標版本,則其中某些變更 可能無法立即對您造成影響不過,雖然您目前可以使用 非 SDK 介面 (視應用程式的目標 API 級別而定), 使用任何非 SDK 方法或欄位,都有很高的風險 應用程式。
如果不確定應用程式是否使用非 SDK 介面,可以測試 應用程式 讓我們一探究竟。如果您的應用程式仰賴非 SDK 介面,建議您著手規劃 轉換至 SDK 替代方案我們瞭解有些應用程式 使用非 SDK 介面的有效用途。如果您找不到替代選項 針對應用程式中的某個功能使用非 SDK 介面,則應要求 新的公用 API
如要進一步瞭解此 Android 版本中的變更,請參閱 更新 Android 12 的非 SDK 介面限制。瞭解詳情 如需非 SDK 介面的一般資訊,請參閱非 SDK 的相關限制 介面。