Behavior changes: Apps targeting Android 13 or higher  |  Android 13 Developer P...

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

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 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.

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

Learn more about the nearby Wi-Fi devices permission.

Security

Intent filters block non-matching intents

In the existing implementation, the term “intent filter” was counterintuitive as it does not filter what intents are delivered to a component; instead it was only relevant during intent resolution of an implicit intent. When an app registers an exported component in its manifest and adds an <intent-filter>, the component can be started by any intent—even those that do not match the intent filter.

Without checking the intent when the component is started, in some circumstances this allowed external apps to trigger functionality that was supposed to be internal to an app.

Before this change, there are two ways to deliver an intent to a component (such as an <activity>) where the intent does not match the component’s declared <intent-filter> elements:

1. Explicit intents: intents with a component name set will always be delivered to the component, as long as the sender has permission.

2. Intent selectors: when setting a matching intent as a selector of the main intent, the main intent will always be delivered.

For apps targeting Android 13 or higher (the intent-receiving side), all intents originating from external apps are delivered to an exported component if and only if it matches its declared <intent-filter> elements.

Non-matching intents are blocked. Exceptions where intent matching is not enforced include the following:

• Intents delivered to components that don’t declare any intent filters
• Intents originating within the same app, from the system, and from root