Like previous releases, Android 14 includes behavior changes that might affect
your app. The following behavior changes apply exclusively to apps that are
targeting Android 14 (API level 34) or higher. If your app is targeting Android
14 or higher, you should modify your app to support these behaviors properly,
where applicable.

Be sure to also review the list of [behavior changes that affect all apps
running on Android 14](https://developer.android.com/about/versions/14/behavior-changes-all) regardless of
the app's [`targetSdkVersion`](https://developer.android.com/guide/topics/manifest/uses-sdk-element#target).

## Core functionality

### Foreground service types are required

If your app targets Android 14 (API level 34) or higher, it must [specify at
least one foreground service type](https://developer.android.com/about/versions/14/changes/fgs-types-required) for each [foreground service](https://developer.android.com/guide/components/foreground-services) within
your app. You should choose a foreground service type that represents your app's
use case. The system expects foreground services that have a particular type to
satisfy a particular use case.
| **Note:** Android 14 introduces foreground service types for [health](https://developer.android.com/about/versions/14/changes/fgs-types-required#health) and [remote
| messaging](https://developer.android.com/about/versions/14/changes/fgs-types-required#remote-messaging) use cases. The system also reserves new types for [short
| services](https://developer.android.com/about/versions/14/changes/fgs-types-required#short-service), [special use cases](https://developer.android.com/about/versions/14/changes/fgs-types-required#special-use), and [system exemptions](https://developer.android.com/about/versions/14/changes/fgs-types-required#system-exempted).

If a use case in your app isn't associated with any of these types, it's
strongly recommended that you migrate your logic to use [WorkManager](https://developer.android.com/topic/libraries/architecture/workmanager) or
[user-initiated data transfer jobs](https://developer.android.com/develop/background-work/background-tasks/uidt).

### Enforcement of BLUETOOTH_CONNECT permission in BluetoothAdapter

Android 14 enforces the [`BLUETOOTH_CONNECT`](https://developer.android.com/reference/android/Manifest.permission#BLUETOOTH_CONNECT) permission when calling the
`BluetoothAdapter` [`getProfileConnectionState()`](https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#getProfileConnectionState(int)) method for apps targeting
Android 14 (API level 34) or higher.

This method already required the `BLUETOOTH_CONNECT` permission, but it was not
enforced. Make sure your app declares `BLUETOOTH_CONNECT` in your app's
`AndroidManifest.xml` file as shown in the following snippet and [check that
a user has granted the permission](https://developer.android.com/training/permissions/requesting#already-granted) before calling
`getProfileConnectionState`.  

    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

### OpenJDK 17 updates

Android 14 continues the work of refreshing Android's core libraries to align
with the features in the latest OpenJDK LTS releases, including both library
updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

- **Changes to regular expressions** : Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an `IllegalArgumentException` is thrown by the [`java.util.regex.Matcher`](https://developer.android.com/reference/java/util/regex/Matcher) class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the `DISALLOW_INVALID_GROUP_REFERENCE` flag using the [compatibility framework tools](https://developer.android.com/guide/app-compatibility/test-debug#toggle-dev-options).
- **UUID handling** : The [`java.util.UUID.fromString()`](https://developer.android.com/reference/java/util/UUID#fromString(java.lang.String)) method now does more strict checks when validating the input argument, so you might see an `IllegalArgumentException` during deserialization. To enable or disable this change while testing, toggle the `ENABLE_STRICT_VALIDATION` flag using the [compatibility framework tools](https://developer.android.com/guide/app-compatibility/test-debug#toggle-dev-options).
- **ProGuard issues** : In some cases, the addition of the [`java.lang.ClassValue`](https://developer.android.com/reference/java/lang/ClassValue) class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether `Class.forName("java.lang.ClassValue")` returns a class or not. If your app was developed against an older version of the runtime without the `java.lang.ClassValue` class available, then these optimizations might remove the `computeValue` method from classes derived from `java.lang.ClassValue`.

### JobScheduler reinforces callback and network behavior

Since its introduction, JobScheduler expects your app to return from
[`onStartJob`](https://developer.android.com/reference/android/app/job/JobService#onStartJob(android.app.job.JobParameters)) or [`onStopJob`](https://developer.android.com/reference/android/app/job/JobService#onStopJob(android.app.job.JobParameters)) within a few seconds. Prior to Android 14,
if a job runs too long, the job is stopped and fails silently.
If your app targets Android 14 (API level 34) or higher and
exceeds the granted time on the main thread, the app triggers an ANR
with the error message "No response to `onStartJob`" or
"No response to `onStopJob`".

This ANR may be a result of 2 scenarios:
1. There is work blocking the main thread, preventing the callbacks `onStartJob`
or `onStopJob` from executing and completing within the expected time limit.
2. The developer is running blocking work within the JobScheduler
callback `onStartJob` or `onStopJob`, preventing the callback from
completing within the expected time limit.

To address #1, you will need to further debug what is blocking the main thread
when the ANR occurs, you can do this using
[`ApplicationExitInfo#getTraceInputStream()`](https://developer.android.com/reference/kotlin/android/app/ApplicationExitInfo#getTraceInputStream()) to get the tombstone
trace when the ANR occurs. If you're able to manually reproduce the ANR,
you can record a [system trace](https://developer.android.com/studio/profile/cpu-profiler) and inspect the trace using either
[Android Studio](https://developer.android.com/studio/profile/inspect-traces) or [Perfetto](https://developer.android.com/tools/perfetto) to better understand what is running on
the main thread when the ANR occurs.
Note that this can happen when using JobScheduler API directly
or using the androidx library WorkManager.

To address #2, consider migrating to [WorkManager](https://developer.android.com/guide/background/persistent/threading), which provides
support for wrapping any processing in `onStartJob` or `onStopJob`
in an asynchronous thread.

`JobScheduler` also introduces a requirement to declare the
[`ACCESS_NETWORK_STATE`](https://developer.android.com/reference/android/Manifest.permission#ACCESS_NETWORK_STATE) permission if using [`setRequiredNetworkType`](https://developer.android.com/android/app/job/JobInfo.Builder#setRequiredNetworkType(int)) or
[`setRequiredNetwork`](https://developer.android.com/reference/android/app/job/JobInfo.Builder#setRequiredNetwork(android.net.NetworkRequest)) constraint. If your app does not declare the
`ACCESS_NETWORK_STATE` permission when scheduling the job and is targeting
Android 14 or higher, it will result in a [`SecurityException`](https://developer.android.com/reference/java/lang/SecurityException).

### Tiles launch API

For apps targeting 14 and higher,
[`TileService#startActivityAndCollapse(Intent)`](https://developer.android.com/reference/android/service/quicksettings/TileService#startActivityAndCollapse(android.content.Intent)) is deprecated and now throws
an exception when called. If your app launches activities from tiles, use
[`TileService#startActivityAndCollapse(PendingIntent)`](https://developer.android.com/reference/android/service/quicksettings/TileService#startActivityAndCollapse(android.app.PendingIntent)) instead.

## Privacy

## Partial access to photos and videos

Android 14 introduces Selected Photos Access, which allows users to grant apps
access to specific images and videos in their library, rather than granting
access to all media of a given type.

This change is only enabled if your app targets Android 14 (API level 34) or
higher. If you don't use the photo picker yet, we recommend [implementing it in
your app](https://developer.android.com/training/data-storage/shared/photopicker) to provide a consistent experience for selecting images and videos
that also enhances user privacy without having to request any storage
permissions.

If you maintain your own gallery picker using storage permissions and need to
maintain full control over your implementation, [adapt your implementation](https://developer.android.com/about/versions/14/changes/partial-photo-video-access#app-gallery-picker)
to use the new [`READ_MEDIA_VISUAL_USER_SELECTED`](https://developer.android.com/reference/android/Manifest.permission#READ_MEDIA_VISUAL_USER_SELECTED) permission. If your app
doesn't use the new permission, the system runs your app in a [compatibility
mode](https://developer.android.com/about/versions/14/changes/partial-photo-video-access#compatibility-mode).

## User experience

### Secure full-screen Intent notifications

With Android 11 (API level 30), it was possible for any app to use
[`Notification.Builder.setFullScreenIntent`](https://developer.android.com/reference/android/app/Notification.Builder#setFullScreenIntent(android.app.PendingIntent,%20boolean)) to send full-screen
intents while the phone is locked. You could auto-grant this on app install by
declaring [`USE_FULL_SCREEN_INTENT`](https://developer.android.com/reference/android/Manifest.permission#USE_FULL_SCREEN_INTENT) permission in the
AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority
notifications demanding the user's immediate attention, such as an incoming
phone call or alarm clock settings configured by the user. For apps targeting
Android 14 (API level 34) or higher, apps that are allowed to use this
permission are limited to those that provide calling and alarms only. The Google
Play Store revokes default `USE_FULL_SCREEN_INTENT` permissions for any apps
that don't fit this profile. The deadline for these policy changes is [May 31,
2024](https://support.google.com/googleplay/android-developer/table/12921780?ref_topic=9877065).

This permission remains enabled for apps installed on the phone before the user
updates to Android 14. Users can turn this permission on and off.

You can use the new API
[`NotificationManager.canUseFullScreenIntent`](https://developer.android.com/reference/android/app/NotificationManager#canUseFullScreenIntent()) to check if your app
has the permission; if not, your app can use the new intent
[`ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT`](https://developer.android.com/reference/android/provider/Settings#ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT) to launch the settings
page where users can grant the permission.

## Security

### Restrictions to implicit and pending intents

For apps targeting Android 14 (API level 34) or higher, Android restricts apps
from sending implicit intents to internal app components in the following ways:

- Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
- If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.

These changes prevent malicious apps from intercepting implicit intents that are
intended for use by an app's internal components.

For example, here is an [intent filter](https://developer.android.com/guide/components/intents-filters#Receiving) that could be
declared in your app's manifest file:  

    <activity
        android:name=".AppActivity"
        android:exported="false">
        <intent-filter>
            <action android:name="com.example.action.<var translate="no">APP_ACTION</var>" />
            <category android:name="android.intent.category.DEFAULT" />
        </intent-filter>
    </activity>

If your app tried to launch this activity using an implicit intent, an
[`ActivityNotFoundException`](https://developer.android.com/reference/android/content/ActivityNotFoundException) exception would be thrown:  

### Kotlin

```kotlin
// Throws an https://developer.android.com/reference/android/content/ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.<var translate="no">APP_ACTION</var>"))
```

### Java

```java
// Throws an https://developer.android.com/reference/android/content/ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.<var translate="no">APP_ACTION</var>"));
```

To launch the non-exported activity, your app should use an explicit intent
instead:  

### Kotlin

```kotlin
// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.<var translate="no">APP_ACTION</var>")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)
```

### Java

```java
// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.<var translate="no">APP_ACTION</var>")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);
```

### Runtime-registered broadcasts receivers must specify export behavior

Apps and services that target Android 14 (API level 34) or higher and use
[context-registered receivers](https://developer.android.com/guide/components/broadcasts#context-registered-receivers) are required to specify a flag
to indicate whether or not the receiver should be exported to all other apps on
the device: either `RECEIVER_EXPORTED` or `RECEIVER_NOT_EXPORTED`, respectively.
This requirement helps protect apps from security vulnerabilities by leveraging
the [features for these receivers introduced in Android 13](https://developer.android.com/about/versions/13/features#runtime-receivers).

#### Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for
[system broadcasts](https://developer.android.com/guide/components/broadcasts#system-broadcasts) through `Context#registerReceiver`
methods, such as [`Context#registerReceiver()`](https://developer.android.com/reference/android/content/Context#registerReceiver(android.content.BroadcastReceiver,%20android.content.IntentFilter)), then it
shouldn't specify a flag when registering the receiver.

### Safer dynamic code loading

If your app targets Android 14 (API level 34) or higher and uses Dynamic Code
Loading (DCL), all dynamically-loaded files must be marked as read-only.
Otherwise, the system throws an exception. We recommend that apps [avoid
dynamically loading code](https://developer.android.com/privacy-and-security/security-tips#DynamicCode)
whenever possible, as doing so greatly increases the risk that an app can be
compromised by code injection or code tampering.

If you must dynamically load code, use the following approach to set the
dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon
as the file is opened and before any content is written:  

### Kotlin

```kotlin
val jar = File("<var translate="no">DYNAMICALLY_LOADED_FILE</var>.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)
```

### Java

```java
File jar = new File("<var translate="no">DYNAMICALLY_LOADED_FILE</var>.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
```

#### Handle dynamically-loaded files that already exist

To prevent exceptions from being thrown for existing dynamically-loaded files,
we recommend deleting and recreating the files before you try to dynamically
load them again in your app. As you recreate the files, follow the preceding
guidance for marking the files read-only at write time. Alternatively, you can
re-label the existing files as read-only, but in this case, we strongly
recommend that you verify the integrity of the files first (for example, by
checking the file's signature against a trusted value), to help protect your app
from malicious actions.

### Additional restrictions on starting activities from the background

For apps targeting Android 14 (API level 34) or higher, the system further
restricts when apps are allowed to start activities from the background:

- When an app sends a `PendingIntent` using [`PendingIntent#send()`](https://developer.android.com/reference/android/app/PendingIntent#send(android.content.Context,%20int,%20android.content.Intent,%20android.app.PendingIntent.OnFinished,%20android.os.Handler,%20java.lang.String,%20android.os.Bundle)) or similar methods, the app must opt in if it wants to grant its own background activity launch privileges to start the pending intent. To opt in, the app should pass an `ActivityOptions` bundle with [`setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)`](https://developer.android.com/reference/android/app/ActivityOptions#setPendingIntentBackgroundActivityStartMode(int)).
- When a visible app binds a service of another app that's in the background using the [`bindService()`](https://developer.android.com/reference/android/content/Context#bindService(android.content.Intent,%20android.content.Context.BindServiceFlags,%20java.util.concurrent.Executor,%20android.content.ServiceConnection)) method, the visible app must now opt in if it wants to grant its own background activity launch privileges to the bound service. To opt in, the app should include the [`BIND_ALLOW_ACTIVITY_STARTS`](https://developer.android.com/reference/android/content/Context#BIND_ALLOW_ACTIVITY_STARTS) flag when calling the `bindService()` method.

These changes expand the [existing set of restrictions](https://developer.android.com/guide/components/activities/background-starts) to protect
users by preventing malicious apps from abusing APIs to start disruptive
activities from the background.

### Zip path traversal

For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip
Path Traversal Vulnerability in the following way:
[`ZipFile(String)`](https://developer.android.com/reference/java/util/zip/ZipFile#public-constructors) and
[`ZipInputStream.getNextEntry()`](https://developer.android.com/reference/java/util/zip/ZipInputStream#getNextEntry()) throws a
[`ZipException`](https://developer.android.com/reference/java/util/zip/ZipException) if zip file entry names contain ".." or start
with "/".

Apps can opt-out from this validation by calling
[`dalvik.system.ZipPathValidator.clearCallback()`](https://developer.android.com/reference/dalvik/system/ZipPathValidator#clearCallback()).

### User consent required for each MediaProjection capture session

For apps targeting Android 14 (API level 34) or higher, a `SecurityException` is
thrown by [`MediaProjection#createVirtualDisplay`](https://developer.android.com/reference/android/media/projection/MediaProjection#createVirtualDisplay(java.lang.String,%20int,%20int,%20int,%20int,%20android.view.Surface,%20android.hardware.display.VirtualDisplay.Callback,%20android.os.Handler)) in either of the following
scenarios:

- Your app caches the [`Intent`](https://developer.android.com/reference/android/content/Intent) that is returned from [`MediaProjectionManager#createScreenCaptureIntent`](https://developer.android.com/reference/android/media/projection/MediaProjectionManager#createScreenCaptureIntent()), and passes it multiple times to [`MediaProjectionManager#getMediaProjection`](https://developer.android.com/reference/android/media/projection/MediaProjectionManager#getMediaProjection(int,%20android.content.Intent)).
- Your app invokes `MediaProjection#createVirtualDisplay` multiple times on the same `MediaProjection` instance.

Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
`MediaProjection#createVirtualDisplay`, and each `MediaProjection` instance must
be used only once.

#### Handle configuration changes

If your app needs to invoke `MediaProjection#createVirtualDisplay` to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the `VirtualDisplay` for the existing
`MediaProjection` instance:

1. Invoke [`VirtualDisplay#resize`](https://developer.android.com/reference/kotlin/android/hardware/display/VirtualDisplay#resize) with the new width and height.
2. Provide a new [`Surface`](https://developer.android.com/reference/kotlin/android/view/Surface) with the new width and height to [`VirtualDisplay#setSurface`](https://developer.android.com/reference/kotlin/android/hardware/display/VirtualDisplay#setsurface).

#### Register a callback

Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
[`Callback#onStop`](https://developer.android.com/reference/android/media/projection/MediaProjection.Callback#onStop()) and have your app release any related resources (such as
the `VirtualDisplay` and `Surface`).

If your app doesn't register this callback,
`MediaProjection#createVirtualDisplay` throws an [`IllegalStateException`](https://developer.android.com/reference/java/lang/IllegalStateException)
when your app invokes it.

## Updated non-SDK restrictions

Android 14 includes updated lists of restricted non-SDK
interfaces based on collaboration with Android developers and the latest
internal testing. Whenever possible, we make sure that public alternatives are
available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes
might not immediately affect you. However, while you can currently use some
non-SDK interfaces ([depending on your app's target API
level](https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces#list-names)),
using any non-SDK method or field always carries a high risk of breaking your
app.

If you are unsure if your app uses non-SDK interfaces, you can [test your
app](https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces#test-for-non-sdk)
to find out. If your app relies on non-SDK interfaces, you should begin planning
a migration to SDK alternatives. Nevertheless, we understand that some apps have
valid use cases for using non-SDK interfaces. If you cannot find an alternative
to using a non-SDK interface for a feature in your app, you should [request a
new public API](https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces#feature-request).

To learn more about the changes in this release of Android, see
[Updates to non-SDK interface restrictions in Android 14](https://developer.android.com/about/versions/14/changes/non-sdk-14).
To learn more about non-SDK interfaces generally, see
[Restrictions on non-SDK interfaces](https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces).