和先前版本一樣,Android 13 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 13 以上版本的應用程式。如果您的應用程式指定 Android 13 以上版本,建議您視情況修改應用程式,以支援這些行為。
此外,請務必查看影響所有在 Android 13 上執行的應用程式行為變更清單。
隱私權
通知權限會影響前景服務外觀
如果使用者拒絕通知權限,就不會在通知導覽匣中看到前景服務相關的通知。不過,無論是否授予通知權限,使用者仍會在工作管理員中看到前景服務相關通知。
鄰近 Wi-Fi 裝置的新執行階段權限
在舊版 Android 中,使用者必須授予應用程式 ACCESS_FINE_LOCATION
權限,才能完成幾種常見的 Wi-Fi 用途。
由於使用者很難將位置存取權與 Wi-Fi 功能建立關聯,Android 13 (API 級別 33) 在 NEARBY_DEVICES
權限群組中導入了執行階段權限,供管理裝置透過 Wi-Fi 連線至鄰近存取點的應用程式使用。這個權限 NEARBY_WIFI_DEVICES
可滿足 Wi-Fi 用途,例如:
- 尋找或連線至附近的裝置,例如印表機或媒體投放裝置。
此工作流程允許應用程式完成以下類型的工作:
- 在頻帶外接收 AP 資訊,例如透過 BLE。
- 透過 Wi-Fi Aware 探索及連線至裝置,並使用僅限本機的無線基地台連線。
- 透過 Wi-Fi Direct 探索裝置並連線。
- 啟動與已知 SSID 的連線,例如車輛或智慧住宅裝置。
- 啟動僅限本機的無線基地台。
- 範圍:鄰近的 Wi-Fi Aware 裝置。
只要應用程式不會透過 Wi-Fi API 取得實體位置資訊,請在指定 Android 13 以上版本並使用 Wi-Fi API 時要求 NEARBY_WIFI_DEVICES
,而非 ACCESS_FINE_LOCATION
。宣告 NEARBY_WIFI_DEVICES
權限時,請明確指出應用程式絕不會從 Wi-Fi API 擷取實體位置資訊。如要這樣做,請將 android:usesPermissionFlags
屬性設為 neverForLocation
。這個程序與您在 Android 12 (API 級別 31) 以上版本中斷言 Bluetooth 裝置資訊絕不會用於位置資訊時所執行的程序類似。
進一步瞭解如何要求存取鄰近 Wi-Fi 裝置的權限。
精細媒體權限
如果您的應用程式指定 Android 13 以上版本,且需要存取其他應用程式建立的媒體檔案,則您必須要求下列一或多項精細媒體權限,而非 READ_EXTERNAL_STORAGE
權限:
媒體類型 | 要求權限 |
---|---|
圖片和相片 | READ_MEDIA_IMAGES |
影片 | READ_MEDIA_VIDEO |
音訊檔案 | READ_MEDIA_AUDIO |
在存取其他應用程式的媒體檔案之前,請確認使用者已將適當的細項媒體權限授予您的應用程式。
圖 1 顯示要求 READ_MEDIA_AUDIO
權限的應用程式。
如果您同時要求 READ_MEDIA_IMAGES
權限和 READ_MEDIA_VIDEO
權限,系統只會顯示一個系統權限對話方塊。
如果應用程式先前已取得 READ_EXTERNAL_STORAGE
權限,則升級時會自動授予所要求的 READ_MEDIA_*
權限。您可以使用下列 ADB 指令查看已升級的權限:
adb shell cmd appops get --uid PACKAGE_NAME
如要在背景使用人體感應器,必須取得新權限
Android 13 引進了「使用期間」存取人體感應器的概念,例如心率、體溫和血氧比例。這個存取模式與系統在 Android 10 (API 級別 29) 中針對位置資訊推出的模式非常相似。
如果您的應用程式指定 Android 13 為目標版本,且需要在背景執行時存取人體感應器資訊,除了現有的 BODY_SENSORS
權限外,您還必須宣告新的 BODY_SENSORS_BACKGROUND
權限。
效能和電池
電池資源使用率
如果使用者在應用程式以 Android 13 為目標版本時,讓應用程式處於「受限制」狀態的背景電池用量,則除非應用程式基於其他原因啟動,否則系統不會傳送 BOOT_COMPLETED
或 LOCKED_BOOT_COMPLETED
廣播訊息。
使用者體驗
媒體控制選項源自 PlaybackState
如果應用程式指定 Android 13 (API 級別 33) 以上版本,系統會從 PlaybackState
動作衍生媒體控制項。這可讓系統顯示更豐富的控制項組合,在手機和平板電腦裝置之間達到技術上的一致性,並與其他 Android 平台 (例如 Android Auto 和 Android TV) 上顯示媒體控制項的方式保持一致。
圖 2 舉例說明此效果在手機和平板電腦裝置上如何呈現。
在 Android 13 之前,系統會按照新增的順序,從 MediaStyle
通知顯示最多五個動作。在精簡模式 (例如在摺疊的快速設定中),最多會顯示三個使用 setShowActionsInCompactView()
指定的動作。
從 Android 13 開始,系統會根據 PlaybackState
顯示最多五個動作按鈕,如下表所述。在精簡模式中,系統只會顯示前三個動作方塊。如果應用程式未指定 Android 13 為目標版本,或是未包含 PlaybackState
,系統會根據新增至 MediaStyle
通知的 Action
清單顯示控制項,如前一段所述。
版位 | 動作 | 條件 |
---|---|---|
1 | 播放 |
PlaybackState 的目前狀態為下列其中一種:
|
載入中的旋轉圖示 |
PlaybackState 目前的狀態為下列其中一種:
|
|
暫停 | PlaybackState 目前的狀態並非上述任何一種。 |
|
2 | 上一頁 | PlaybackState actions 包含 ACTION_SKIP_TO_PREVIOUS 。 |
自訂 | PlaybackState 動作不包含 ACTION_SKIP_TO_PREVIOUS ,且 PlaybackState 自訂動作包含尚未放置的自訂動作。 |
|
空白 | PlaybackState 「extras」包含鍵 SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV 的 true 布林值。 |
|
3 | 繼續 | PlaybackState actions 包含 ACTION_SKIP_TO_NEXT 。 |
自訂 | PlaybackState 動作不包含 ACTION_SKIP_TO_NEXT ,且 PlaybackState 自訂動作包含尚未放置的自訂動作。 |
|
空白 | PlaybackState extras 包含鍵 SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT 的 true 布林值。 |
|
4 | 自訂 | PlaybackState 自訂動作包含尚未放置的自訂動作。 |
5 | 自訂 | PlaybackState 自訂動作包含尚未放置的自訂動作。 |
自訂動作會按照新增至 PlaybackState
的順序排列。
應用程式色彩主題自動套用至 WebView 內容
針對指定 Android 13 (API 級別 33) 以上版本的應用程式,setForceDark()
方法已淘汰,若呼叫此方法,會導致免人工管理。
相反地,WebView 現在會根據應用程式的主題屬性 isLightTheme
來設定媒體查詢 prefers-color-scheme
。換句話說,如果 isLightTheme
是 true
或未指定,prefers-color-scheme
就是 light
;否則,就是 dark
。這項行為表示,如果網頁內容支援深色主題,系統會自動套用網頁內容的淺色或深色樣式,以配合應用程式主題。
對於大多數應用程式,新行為應會自動套用合適的應用程式樣式,不過您應該測試應用程式,確認是否有任何手動控制深色模式設定的情況。
如果您仍須自訂應用程式的色彩主題行為,請改用 setAlgorithmicDarkeningAllowed()
方法。為了回溯與先前的 Android 版本相容,我們建議您在 AndroidX 中使用同等的 setAlgorithmicDarkeningAllowed()
方法。
請參閱該方法的說明文件,進一步瞭解應用程式會根據應用程式的 targetSdkVersion
和主題設定,產生哪些行為。
連線能力
已淘汰 BluetoothAdapter#enable() 和 BluetoothAdapter#disable()
如果應用程式指定 Android 13 (API 級別 33) 以上版本,則 BluetoothAdapter#enable()
和 BluetoothAdapter#disable()
方法已淘汰,並一律傳回 false
。
下列類型的應用程式不受這些變更影響:
- 裝置擁有者應用程式
- 設定檔擁有者應用程式
- 系統應用程式
Google Play 服務
廣告 ID 所需權限
如果應用程式使用 Google Play 服務的廣告 ID,且指定 Android 13 (API 級別 33) 以上版本為目標版本,就必須在應用程式資訊清單檔案中宣告 AD_ID
一般權限,如下所示:
<manifest ...>
<!-- Required only if your app targets Android 13 or higher. -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>
<application ...>
...
</application>
</manifest>
如果應用程式指定 Android 13 以上版本為目標版本,但未宣告這項權限,系統會自動移除廣告 ID,並以零字串替代該 ID。
如果應用程式使用的 SDK 在程式庫的資訊清單中宣告了 AD_ID
權限,則根據預設,該權限會與應用程式的資訊清單檔案合併。在這種情況下,您不需要在應用程式的資訊清單檔案中宣告權限。
如需更多資訊,請參閱 Play 管理中心說明的「廣告 ID」一文。
更新非 SDK 限制
基於與 Android 開發人員合作及最新的內部測試,Android 13 包含更新後的受限制非 SDK 介面清單。在限制非 SDK 介面之前,我們盡可能確保公開替代方案的可得性。
如果您的應用程式並不是以 Android 13 為目標版本,則此處所述的某些變更可能不會立即對您造成影響。雖然您目前可以使用某些非 SDK 介面 (視應用程式的目標 API 級別而定),但使用任何非 SDK 方法或欄位時,均可能面臨應用程式故障的高度風險。
如果不確定應用程式是否使用非 SDK 介面,您可以測試應用程式來確認。如果您的應用程式仰賴非 SDK 介面,則建議您開始規劃遷移至 SDK 替代方案。不過,我們瞭解有些應用程式可使用非 SDK 介面運作。如果您除了為應用程式中的某個功能使用非 SDK 介面外,已別無他法,則應要求新的公用 API。
如要進一步瞭解此 Android 版本中的變更,請參閱「Android 13 的非 SDK 介面限制更新內容」。如要進一步瞭解非 SDK 介面的一般資訊,請參閱「非 SDK 介面的限制」。