Behavior changes: Apps targeting Android 13 or higher

Like earlier releases, Android 13 includes behavior changes that may affect your app. The following behavior changes apply exclusively to apps that are targeting Android 13 or higher. If your app is targeting Android 13 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 13.

Privacy

Notification permission affects foreground service appearance

If the user denies the notification permission, they still see notices related to these foreground services in the Foreground Services (FGS) Task Manager but don't see them in the notification drawer.

New runtime permission for nearby Wi-Fi devices

On previous versions of Android, the user needs to grant your app the ACCESS_FINE_LOCATION permission in order to complete several common Wi-Fi use cases related to hotspots, Wi-Fi Direct connections, Wi-Fi RTT, and more.

Because it's difficult for users to associate location permissions with Wi-Fi functionality, Android 13 (API level 33) introduces a new runtime permission in the NEARBY_DEVICES permission group for apps that manage a device's connections to nearby access points over Wi-Fi. This permission, NEARBY_WIFI_DEVICES, fulfills these Wi-Fi use cases.

As long as your app doesn't derive physical location information from the Wi-Fi APIs, request NEARBY_WIFI_DEVICES instead of ACCESS_FINE_LOCATION when you target Android 13 or higher and use Wi-Fi APIs. This process is similar to the one you do in Android 12 (API level 31) and higher when you assert that Bluetooth device information is never used for location.

Note: This change affects your app only if you call a Wi-Fi API. View the list of affected APIs.

Learn more about the nearby Wi-Fi devices permission.

Granular media permissions

Figure 1. System permissions dialog that the user sees when you request the READ_MEDIA_AUDIO permission.

If your app targets Android 13, you must request one or more new permissions instead of the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions.

The set of permissions that you request depends on the type(s) of media that your app needs to access:

Type of media	Permission to request
Images and photos	READ_MEDIA_IMAGES
Videos	READ_MEDIA_VIDEO
Audio files	READ_MEDIA_AUDIO

If the user previously granted your app the READ_EXTERNAL_STORAGE permission, the system automatically grants each of the new permissions to your app.

Otherwise, the system shows a user-facing dialog when your app requests any of the permissions shown in the preceding table. In figure 1, the app requests the READ_MEDIA_AUDIO permission. If you request both the READ_MEDIA_IMAGES permission and the READ_MEDIA_VIDEO permission at the same time, only one system permission dialog appears.

Note: If your app only needs to access images, photos, and videos, consider using the photo picker instead of declaring the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions.

Migration steps when you target Android 13

After you target Android 13, declare the media permissions that your app needs. To maintain compatibility with older versions of Android, declare the READ_EXTERNAL_STORAGE permission while setting maxSdkVersion to 32, as shown in the following code snippet:

<manifest ...>
    <!-- Required only if your app targets Android 13. -->
    <!-- Declare one or more the following permissions only if your app needs
    to access data that's protected by them. -->
    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
    <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
    <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />

    <!-- Required to maintain app compatibility. -->
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"
                     android:maxSdkVersion="32" />
    <application ...>
        ...
    </application>
</manifest>

Note: You don't need to declare the WRITE_EXTERNAL_STORAGE permission at all anymore.

Use of body sensors in the background requires new permission

Android 13 introduces the concept of "while in use" access for body sensors, such as heart rate, temperature, and blood oxygen percentage. This access model is very similar to the one that the system introduced for location in Android 10 (API level 29).

If your app targets Android 13 and requires access to body sensor information while running in the background, you must declare the new BODY_SENSORS_BACKGROUND permission in addition to the existing BODY_SENSORS permission.

Note: This is a "hard-restricted" permission that cannot be held by an app until the device's installer allowlists the permission for your app. For more details, see this guide on restricted permissions.

Security

Intent filters block non-matching intents

When your app sends an intent to an exported component of another app that targets Android 13 or higher, that intent is delivered if and only if it matches an <intent-filter> element in the receiving app. Non-matching intents are blocked.

Exceptions where intent matching isn't enforced:

• Intents delivered to components that don't declare any intent filters.
• Intents originating from within the same app.
• Intents originating from the system; that is, intents being sent from the "system UID" (uid=1000). System apps include system_server and apps that set android:sharedUserId to android.uid.system.
• Intents originating from root.

If a receiving app upgrades to Android 13 or higher, all intents originating from external apps are delivered to an exported component if and only if it matches its declared <intent-filter> elements, regardless of the sending app's target SDK version.

Performance and battery

Battery Resource Utilization

If the user places your app in the "restricted" state for background battery usage while your app targets Android 13, the system applies several limitations related to broadcasts.

Learn more about the new limitations for restricted background battery usage on the page that describes the Battery Resource Utilization features being introduced in Android 13.

User experience

Media controls derived from PlaybackState

For apps targeting Android 13 (API level 33) and higher, the system derives media controls from PlaybackState actions. This allows the system to show a richer set of controls that are technically consistent between phones and tablet devices, and also align with how media controls are rendered on other Android platforms such as Android Auto and Android TV.

Figure 2 shows an example of how this looks on a phone and tablet device, respectively.

Figure 2: Media controls on phone and tablet devices

Prior to Android 13, the system displayed up to five actions from the MediaStyle notification in the order in which they were added. In compact mode—for example, in the collapsed quick settings—up to three actions specified with setShowActionsInCompactView() were shown.

Starting with Android 13, the system displays up to five action buttons based on the PlaybackState as described in the following table. In compact mode, only the first three action slots will be displayed. For apps that don't target Android 13 or those that don't include a PlaybackState, the system will display controls based on the Action list added to the MediaStyle notification as described in the previous paragraph.

Slot	Action	Criteria
1	Play	Current state of the PlaybackState is one of the following: STATE_NONE STATE_STOPPED STATE_PAUSED STATE_ERROR
	Loading spinner	Current state of the PlaybackState is one of the following: STATE_CONNECTING STATE_BUFFERING
	Pause	Current state of the PlaybackState is none of the above.
2	Previous	PlaybackState actions include ACTION_SKIP_TO_PREVIOUS.
	Custom	PlaybackState actions do not include ACTION_SKIP_TO_PREVIOUS and PlaybackState custom actions include a custom action that hasn't been placed yet.
	Empty	PlaybackState extras include a true boolean value for key SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV.
3	Next	PlaybackState actions include ACTION_SKIP_TO_NEXT.
	Custom	PlaybackState actions do not include ACTION_SKIP_TO_NEXT and PlaybackState custom actions include a custom action that hasn't been placed yet.
	Empty	PlaybackState extras include a true boolean value for key SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT.
4	Custom	PlaybackState custom actions include a custom action that hasn't been placed yet.
5	Custom	PlaybackState custom actions include a custom action that hasn't been placed yet.

Custom actions are placed in the order in which they were added to the PlaybackState.

Updated non-SDK restrictions

Android 13 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 13, 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), 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 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.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 13. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.