Android 14 平台包含可能對應用程式造成影響的行為變更。無論 targetSdkVersion 為何,當應用程式在 Android 14 上執行時,下列行為變更將會套用至所有應用程式。您應測試應用程式,並視需要修改,以便在適當情況下支援新版本功能。
另請務必查看僅對指定 Android 14 為目標版本的應用程式造成影響的行為變更。
核心功能
根據預設,系統會拒絕排定精確鬧鐘
Exact alarms are meant for user-intentioned notifications, or for actions that
need to happen at a precise time. Starting in Android 14, the
SCHEDULE_EXACT_ALARM
permission is no longer being pre-granted to most newly installed apps
targeting Android 13 and higher—the permission is denied by default.
Learn more about the changes to the permission for scheduling exact alarms.
在應用程式快取期間,註冊使用情境的廣播訊息會排入佇列
在 Android 14 中,當應用程式處於快取狀態時,系統可以將已註冊使用情境的廣播訊息排入佇列。這類似於佇列 Android 12 (API 級別 31) 為非同步繫結器引入的行為 交易系統不會將宣告資訊清單的廣播訊息排入佇列,而且應用程式會遭到移除 以便進行廣播傳遞
當應用程式結束快取狀態 (例如返回前景時), 系統會傳送所有排入佇列的廣播訊息某些廣播訊息的多個執行個體可以合併為單一廣播訊息。根據其他因素,例如系統 健康狀態、應用程式可能會從快取狀態中移除, 廣播訊息
應用程式只能終止自己的背景處理程序
自 Android 14 起,當應用程式呼叫 killBackgroundProcesses() 時,
API 只能終止您自有應用程式的背景處理程序。
如果傳入其他應用程式的套件名稱,此方法不會 ,而 Logcat 中會顯示以下訊息:
Invalid packageName: com.example.anotherapp
您的應用程式不應使用 killBackgroundProcesses() API,或嘗試影響其他應用程式的處理程序生命週期,即使是在舊版 OS 上也是如此。Android 的設計是為了在背景作業中保留快取的應用程式,並且能夠在系統需要記憶體時自動終止這些應用程式。如果您的應用程式不小心關閉其他應用程式,可能會因為需要在稍後重新啟動這些應用程式 (比起恢復現有已快取的應用程式會耗用更多的資源),進而降低系統效能並增加電池用量。
針對第一個要求 MTU 的 GATT 用戶端,MTU 會設為 517
Starting from Android 14, the Android Bluetooth stack more strictly adheres to
Version 5.2 of the Bluetooth Core Specification and requests
the BLE ATT MTU to 517 bytes when the first GATT client requests an MTU using
the BluetoothGatt#requestMtu(int) API, and disregards all subsequent MTU
requests on that ACL connection.
To address this change and make your app more robust, consider the following options:
- Your peripheral device should respond to the Android device's MTU request
with a reasonable value that can be accommodated by the peripheral. The
final negotiated value will be a minimum of the Android requested value and
the remote provided value (for example,
min(517, remoteMtu))- Implementing this fix could require a firmware update for peripheral
- Alternatively, limit your GATT characteristic writes based on the minimum
between the known supported value of your peripheral and the received MTU
change
- A reminder that you should reduce 5 bytes from the supported size for the headers
- For example:
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.
mlock 上限為 64 KB
In Android 14 (API level 34) and higher, the platform reduces the maximum memory
that can be locked using mlock() to 64 KB per process. In
previous versions, the limit was 64 MB per process. This restriction
promotes better memory management across apps and the system. To provide more
consistency across devices, Android 14 adds a new CTS test for the
new mlock() limit on compatible devices.
系統強制執行快取應用程式的資源用量
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.
使用者體驗
關於使用者無法關閉通知的變更
如果您的應用程式會向使用者顯示無法關閉的前景通知,則 Android 14 已變更允許使用者關閉此類通知的行為。
這項異動適用於防止使用者關閉前景的應用程式
將 Notification.FLAG_ONGOING_EVENT 設為
Notification.Builder#setOngoing(true) 或
NotificationCompat.Builder#setOngoing(true)。當
FLAG_ONGOING_EVENT 已變更,以便讓這類通知確實存在
可由使用者關閉。
使用者無法在以下情況中關閉這些類型的通知 條件:
- 手機鎖定時
- 當使用者選取全部清除通知動作 (有助 意外關閉)
此外,這項新行為也不適用於 以下用途:
CallStyle通知- 裝置政策控制器 (DPC) 與企業支援套件
- 媒體通知
- 預設搜尋選取器套件
以更清楚的方式顯示資料安全性資訊
為了加強使用者隱私,Android 14 會增加系統顯示您在 Play 管理中心表單中宣告的資訊地點數量。目前,使用者可以在 Google Play 應用程式商店資訊的「資料安全性」專區中查看這項資訊。
建議您查看應用程式的位置資料分享政策,並撥冗為應用程式的 Google Play 資料安全性專區進行適用的更新。
詳情請參閱這份指南,瞭解 Android 14 如何以更清楚的方式顯示資料安全性資訊。
無障礙設定
非線性字型縮放至 200%
Starting in Android 14, the system supports font scaling up to 200%, providing users with additional accessibility options.
If you already use scaled pixels (sp) units to define text sizing, then this change probably won't have a high impact on your app. However, you should perform UI testing with the maximum font size enabled (200%) to ensure that your app can accommodate larger font sizes without impacting usability.
安全性
可安裝的目標 API 級別下限
Starting with Android 14, apps with a
targetSdkVersion lower than 23
can't be installed. Requiring apps to meet these minimum target API level
requirements improves security and privacy for users.
Malware often targets older API levels in order to bypass security and privacy
protections that have been introduced in newer Android versions. For example,
some malware apps use a targetSdkVersion of 22 to avoid being subjected to the
runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API
level 23). This Android 14 change makes it harder for malware to avoid security
and privacy improvements.
Attempting to install an app targeting a lower API level will result in an
installation failure, with the following message appearing in Logcat:
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7
On devices upgrading to Android 14, any apps with a targetSdkVersion lower
than 23 will remain installed.
If you need to test an app targeting an older API level, use the following ADB command:
adb install --bypass-low-target-sdk-block FILENAME.apk
媒體擁有者的套件名稱可能會被遮蓋
The media store supports queries for the OWNER_PACKAGE_NAME column, which
indicates the app that stored a particular media file. Starting in Android
14, this value is redacted unless at least one of the following conditions is
true:
- The app that stored the media file has a package name that is always visible to other apps.
The app that queries the media store requests the
QUERY_ALL_PACKAGESpermission.
Learn more about how Android filters package visibility for privacy purposes.