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.
在應用程式快取期間，註冊使用情境的廣播訊息會排入佇列
On Android 14, the system can place context-registered broadcasts in a queue while the app is in the cached state. This is similar to the queuing behavior that Android 12 (API level 31) introduced for async binder transactions. Manifest-declared broadcasts aren't queued, and apps are removed from the cached state for broadcast delivery.
When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast. Depending on other factors, such as system health, apps might be removed from the cached state, and any previously queued broadcasts are delivered.
應用程式只能終止自己的背景處理程序
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
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 引進了一個新原因，說明應用程式可以進入受限制的待命值區。由於 onStartJob、onStopJob 或 onBind 方法逾時，應用程式工作多次觸發 ANR 錯誤。(如要瞭解變更 onStartJob 和 onStopJob，請參閱 JobScheduler 加強回呼和網路行為。)
如要追蹤應用程式是否已進入受限待命值區，建議您在執行工作時UsageStatsManager.getAppStandbyBucket()或應用程式啟動時使用 API 記錄。UsageStatsManager.queryEventsForSelf()
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.
系統會強制執行快取應用程式的資源使用情形
依設計，當應用程式移至背景，且當下沒有其他正在執行的應用程式處理程序元件，應用程式的處理程序會處於快取狀態。這類應用程式處理程序可能會因為系統記憶體不足而遭終止。在此狀態下，若呼叫 onStop() 方法並傳回後，任何 Activity 執行個體執行的工作都會處於不穩定的狀態，因此強烈不建議執行此類操作。
Android 14 為此設計導入一致性和強制執行機制。應用程式程序進入快取狀態後不久，系統不允許背景工作，直到程序元件重新進入生命週期的有效狀態為止。
如果應用程式使用一般架構支援的生命週期 API (例如 服務、JobScheduler 和 Jetpack WorkManager)，則應該不會受此類變更影響。
使用者體驗
關於使用者無法關閉通知的變更
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:
CallStylenotifications- Device policy controller (DPC) and supporting packages for enterprise
- Media notifications
- The default Search Selector package
以更清楚的方式顯示資料安全性資訊
To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console form. Currently, users can view this information in the Data safety section on your app's listing in Google Play.
We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.
Learn more in the guide about how data safety information is more visible on Android 14.
無障礙設定
非線性字型縮放至 200%
自 Android 14 起，系統將支援高達 200% 的字型縮放功能，為低視能使用者提供符合無障礙網頁內容規範 (WCAG)的額外無障礙選項。
如果您已使用縮放像素 (sp) 單位來定義文字大小，這項變更可能不會對應用程式造成顯著影響。但是，建議您執行啟用最大字型大小 (200%) 的 UI 測試，確保應用程式可以在不影響可用性的情況下，因應較大的字型。
安全性
可安裝的目標 API 級別下限
自 Android 14 起，搭載
比 23 低 targetSdkVersion
。要求應用程式符合這些最低目標 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 較低的所有應用程式
仍會保留安裝版本。
如要測試以舊版 API 級別為目標的應用程式，請使用下列 ADB 指令：
adb install --bypass-low-target-sdk-block FILENAME.apk
媒體擁有者的套件名稱可能會被遮蓋
您可以使用媒體儲存區查詢列有儲存特定媒體檔案應用程式的 OWNER_PACKAGE_NAME 資料欄。自 Android 14 版本起，除非符合下列至少一項條件，否則系統將遮蓋此值：
- 儲存媒體檔案的應用程式會具備一律可由其他應用程式瀏覽的套件名稱。
查詢媒體儲存區的應用程式會要求
QUERY_ALL_PACKAGES權限。
進一步瞭解 Android 如何篩選套件的瀏覽權限，以保護隱私權。