行為變更:所有應用程式

Android 14 平台包含可能對應用程式造成影響的行為變更。無論 targetSdkVersion 為何,當應用程式在 Android 14 上執行時,下列行為變更都會套用至所有應用程式。您應測試應用程式,並視需要修改,以便在適當情況下支援新版本功能。

請務必查看只會影響指定 Android 14 為目標版本應用程式的行為變更清單。

核心功能

根據預設,系統會拒絕排定精確鬧鐘

精確鬧鐘是針對使用者需求或需要在確切時間發生的操作所設計的通知。自 Android 14 起,SCHEDULE_EXACT_ALARM 權限不再預先授予以 Android 13 以上版本為目標所安裝的最新應用程式;該權限依預設為拒絕狀態。

進一步瞭解精準鬧鐘排程權限變更

在應用程式快取期間,註冊使用情境的廣播訊息會排入佇列

在 Android 14 中,當應用程式處於快取狀態時,系統可以將已註冊使用情境廣播訊息排入佇列。這與 Android 12 (API 級別 31) 針對非同步繫結機制交易所推出的排入佇列行為類似。系統不會將宣告資訊清單的廣播訊息排入佇列,應用程式也會自快取狀態移除,以便進行播送。

當應用程式結束快取狀態 (例如返回前景) 時,系統會傳送所有排入佇列的廣播訊息。某些廣播訊息的多個執行個體可以合併為單一廣播訊息。視其他因素 (例如系統健康狀態) 而定,應用程式可能會從快取狀態中移除,而系統會傳送先前排入佇列的所有廣播訊息。

應用程式只能終止自己的背景處理程序

Starting in Android 14, when your app calls killBackgroundProcesses(), the API can kill only the background processes of your own app.

If you pass in the package name of another app, this method has no effect on that app's background processes, and the following message appears in Logcat:

Invalid packageName: com.example.anotherapp

Your app shouldn't use the killBackgroundProcesses() API or otherwise attempt to influence the process lifecycle of other apps, even on older OS versions. Android is designed to keep cached apps in the background and kill them automatically when the system needs memory. If your app kills other apps unnecessarily, it can reduce system performance and increase battery consumption by requiring full restarts of those apps later, which takes significantly more resources than resuming an existing cached app.

第一個要求 MTU 的 GATT 用戶端的 MTU 已設為 517

從 Android 14 開始,Android 藍牙堆疊會更嚴格遵守藍牙核心規格 5.2 版,並在第一個 GATT 用戶端使用 BluetoothGatt#requestMtu(int) API 要求 MTU 時要求 BLE ATT MTU 到 517 個位元組,並忽略該 ACL 連線上的所有後續 MTU 要求。

如要解決這項變更,讓應用程式更可靠,請考慮下列選項:

  • 您的周邊裝置應回應 Android 裝置的 MTU 要求,並提供可由周邊裝置可接受的合理值。最終協商的值將至少為 Android 要求的值和遠端提供的值 (例如 min(517, remoteMtu))
    • 實作這項修正可能需要更新周邊裝置的韌體
  • 或者,您也可以根據週邊裝置的已知支援值,以及已接收的 MTU 變更,設定 GATT 特性寫入作業的最小值。
    • 提醒您,您應依據支援的標頭大小減少 5 個位元組
    • 例如:arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

應用程式會排入受限待命值區的新原因

Android 14 introduces a new reason an app can be placed into the restricted standby bucket. The app's jobs trigger ANR errors multiple times due to onStartJob, onStopJob, or onBind method timeouts. (See JobScheduler reinforces callback and network behavior for changes to onStartJob and onStopJob.)

To track whether or not the app has entered the restricted standby bucket, we recommend logging with the API UsageStatsManager.getAppStandbyBucket() on job execution or UsageStatsManager.queryEventsForSelf() on app startup.

最大 64 KB

在 Android 14 (API 級別 34) 以上版本中,平台會將可使用 mlock() 鎖定的記憶體上限降至每個程序 64 KB。在舊版中,每項程序的上限是 64 MB。這項限制可促進跨應用程式和系統的記憶體管理。為提供跨裝置的一致性,Android 14 針對相容裝置的新的 mlock() 限制新增新的 CTS 測試

系統會強制使用快取應用程式的資源

By design, an app's process is in a cached state when it's moved to the background and no other app process components are running. Such an app process is subject to being killed due to system memory pressure. Any work that Activity instances perform after the onStop() method has been called and returned, while in this state, is unreliable and strongly discouraged.

Android 14 introduces consistency and enforcement to this design. Shortly after an app process enters a cached state, background work is disallowed, until a process component re-enters an active state of the lifecycle.

Apps that use typical framework-supported lifecycle APIs – such as services, JobScheduler, and Jetpack WorkManager – shouldn't be impacted by these changes.

使用者體驗

關於使用者無法關閉通知的變更

If your app shows non-dismissable foreground notifications to users, Android 14 has changed the behavior to allow users to dismiss such notifications.

This change applies to apps that prevent users from dismissing foreground notifications by setting Notification.FLAG_ONGOING_EVENT through Notification.Builder#setOngoing(true) or NotificationCompat.Builder#setOngoing(true). The behavior of FLAG_ONGOING_EVENT has changed to make such notifications actually dismissable by the user.

These kinds of notifications are still non-dismissable in the following conditions:

  • When the phone is locked
  • If the user selects a Clear all notification action (which helps with accidental dismissals)

Also, this new behavior doesn't apply to notifications in the following use cases:

  • CallStyle notifications
  • Device policy controller (DPC) and supporting packages for enterprise
  • Media notifications
  • The default Search Selector package

以更清楚的方式顯示資料安全性資訊

為了加強使用者隱私,Android 14 會增加系統顯示您在 Play 管理中心表單中宣告的資訊地點數量。目前,使用者可以在 Google Play 應用程式商店資訊的資料安全性部分查看這項資訊。

建議您查看應用程式的位置資料分享政策,並撥冗為應用程式的 Google Play「資料安全性」專區進行適用的更新。

詳情請參閱這份指南,瞭解 Android 14 如何以更清楚的方式顯示資料安全性資訊。

無障礙功能

非線性字型縮放至 200%

自 Android 14 起,系統將支援高達 200% 的字型縮放功能,為低視能使用者提供符合無障礙網頁內容規範 (WCAG)的額外無障礙選項。

如果您已使用縮放像素 (sp) 單位來定義文字大小,這項變更可能不會對應用程式造成顯著影響。但是,建議您執行啟用最大字型大小 (200%) 的 UI 測試,確保應用程式可以在不影響可用性的情況下,因應較大的字型。

安全性

可安裝的目標 API 級別下限

自 Android 14 起,無法安裝 targetSdkVersion 低於 23 的應用程式。要求應用程式符合這些最低目標 API 級別規定,可提升使用者的安全性和隱私權。

為了規避 Android 較新版本的安全性和隱私權保護措施,惡意軟體通常會鎖定舊版 API 級別。舉例來說,某些惡意軟體應用程式會使用 22 的 targetSdkVersion,以避免受到 Android 6.0 Marshmallow (API 級別 23) 在 2015 年推出的執行階段權限模型。這項 Android 14 變更會讓惡意軟體更難躲過更嚴謹的安全性和隱私權措施。如果嘗試安裝以較低 API 級別為目標的應用程式,則將導致安裝失敗,Logcat 也會顯示以下訊息:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

在升級至 Android 14 的裝置上,targetSdkVersion 低於 23 的所有應用程式均不會遭到移除。

如果您需要測試以舊版 API 級別為目標的應用程式,請使用下列 ADB 指令:

adb install --bypass-low-target-sdk-block FILENAME.apk

媒體擁有者的套件名稱可能會被遮蓋

您可以使用媒體儲存區查詢列有儲存特定媒體檔案應用程式OWNER_PACKAGE_NAME 資料欄。自 Android 14 版本起,除非符合下列至少一項條件,否則系統將遮蓋此值:

  • 儲存媒體檔案的應用程式會具備一律可由其他應用程式瀏覽的套件名稱。
  • 查詢媒體儲存區的應用程式會要求 QUERY_ALL_PACKAGES 權限。

進一步瞭解 Android 如何篩選套件的瀏覽權限,以保護隱私權。