The Android 14 platform includes behavior changes that may affect your apps. The following behavior changes apply to all apps running on Android 14, regardless of targetSdkVersion. Apps should be tested and then modified as necessary to properly support them (if applicable).
Core functions
Deny scheduled exact alerts by default
Precise alerts are for notifications that the user expects, or actions that need to happen at a precise time. Starting with Android 14, most newly installed apps on Android 13 and higher no longer pre-grant the SCHEDULE_EXACT_ALARM permission, which is denied by default.
Learn more about permission changes to schedule precision alerts.
Broadcasts for context registrations are queued while caching the application
On Android 14, the system might queue context-registered broadcasts while the app is in a cached state. This is similar to the queuing behavior introduced by Android 12 (API level 31) for asynchronous binder transactions. Broadcasts declared by the manifest are not queued, and the app is removed from 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 some broadcasts can be combined into one broadcast.
Apps can only terminate their own background processes
Starting with Android 14, when your app calls killBackgroundProcesses(), the API can only kill your own app's background processes.
If another app's package name is passed in, this method has no effect on that app's background processes, and the following message is displayed in Logcat:
Invalid packageName: com.example.anotherappYour app should not use killBackgroundProcesses() APIs or otherwise attempt to affect the process lifecycle of other apps, even on older OS versions. Android is designed to keep cached apps in the background and automatically kill them when the system needs memory. If your app kills other apps unnecessarily, it can degrade system performance and increase battery drain because it requires a full restart of those apps later, which is far more resource intensive than restoring an existing cached app.
Note: Third-party apps cannot improve the memory, power, or thermal behavior of Android devices. You should ensure that your app complies with Google Play's policy on misleading claims.
Safety
Minimum installable target API level
Starting from Android 14, apps with targetSdkVersion lower than 23 cannot be installed. Requiring apps to meet these minimum target API level requirements increases user security and privacy.
Malware often targets older API levels to bypass security and privacy protections introduced in newer Android versions. For example, some malware apps use targetSdkVersion 22 to avoid being affected by the runtime permissions model introduced in 2015 with Android 6.0 Marshmallow (API level 23). This Android 14 change makes it harder for malware to avoid security and privacy improvements. Attempts to install an application targeting a lower API level will cause the installation to fail with the following message in Logcat:
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7On devices upgraded to Android 14, targetSdkVersion any apps below 23 will remain installed.
If you need to test your app targeting an older API level, use the following ADB command:
adb install --bypass-low-target-sdk-block FILENAME.apkMedia owner package name may be edited
The media store supports queries on the OWNER_PACKAGE_NAME column, which indicates the app that stores a particular media file. Starting with Android 14, the system modifies this value unless at least one of the following conditions is true:
- Apps that store media files have a package name that is always visible to other apps.
-
Apps that query media storage request the QUERY_ALL_PACKAGES permission.
Note: Usage
QUERY_ALL_PACKAGESpermissions are governed by Google Play policies.
Learn more about how Android filters wrapper visibility for privacy purposes.
user experience
Changes to the way users experience undismissable notifications
If your app presents the user with a foreground notification that cannot be dismissed, Android 14 has changed the behavior to allow the user to dismiss such notifications.
This change applies to apps that prevent users from dismissing foreground notifications by setting Notification.FLAG_ONGOING_EVENT via Notification.Builder#setOngoingNotification.Builder#setOngoing(true) . The behavior of FLAG_ONGOING_EVENT has been changed so that the user can actually dismiss such notifications.
These types of notifications still cannot be dismissed if:
- when the phone is locked
- If the user selects the " Clear all notifications" action (this helps with accidental dismissals)
Additionally, this new behavior does not apply to undismissable notifications in the following use cases:
-
Notifications created with MediaStyle
- Policy that limits use to security and privacy cases
- Device Policy Controller (DPC) and Support Packages for Enterprise
Grant partial access to photos and videos
Note: If your app already uses a photo picker, no action is required to support this change.
On Android 14, users can grant partial access to their photos and videos when an app requests any of the visual media permissions introduced in Android 13 (API level 33): READ_MEDIA_IMAGESor READ_MEDIA_VIDEO.
The new dialog displays the following permission options:
- Select photos and videos: New in Android 14. Users choose specific photos and videos to make available to your app.
- Allow All : The user grants full gallery access to all photos and videos on the device.
- Do Not Allow : The user is denied all access.
To handle this change more gracefully in your app, consider declaring the new READ_MEDIA_VISUAL_USER_SELECTED permission. Learn more about supporting scenarios where users grant partial permissions to their media library.
accessibility
Non-linear font scaling to 200%
Starting with Android 14, the system supports up to 200% font scaling, providing low-vision users with additional accessibility options that comply with the Web Content Accessibility Guidelines (WCAG).
If you have defined text size using scaled pixel (sp) units, this change may not have much impact on your app. However, UI testing should be performed with the maximum font size enabled (200%) to ensure that the app can accommodate larger font sizes without impacting usability.