Android 13 introduces the
NEARBY_WIFI_DEVICES
runtime permission, part of the
NEARBY_DEVICES
permission group, for apps that manage a device's connections
to nearby access points over Wi-Fi. This permission makes it easier to justify
an app's access of nearby Wi-Fi devices; on previous versions of Android, these
apps needed to declare the
ACCESS_FINE_LOCATION
permission instead.
If your app targets Android 13 and calls several different Wi-Fi APIs, your app must obtain this new permission from the user.
Use cases affected
The new permission affects several different Wi-Fi use cases, including the following:
- Find or connect to nearby devices, such as printers or media casting devices.
This workflow allows your app to accomplish these sorts of tasks:
- Receive AP information out of band, such as through BLE.
- Discover and connect to devices over Wi-Fi Aware and Connect using a local-only hotspot.
- Discover and connect to devices over Wi-Fi Direct.
- Initiate a connection to a known SSID, such as a car or smart home device.
- Start a local-only hotspot.
- Range to nearby Wi-Fi Aware devices.
Permission is part of the nearby devices group
The NEARBY_WIFI_DEVICES
permission is part of the Nearby devices
permission group. This group, added in Android 12 (API level 31), also includes
permissions related to Bluetooth and Ultra-wideband. If your app requests
multiple permissions in this permission group, the user sees a single runtime
dialog, which asks the user to approve your app's access to nearby devices. In
system settings, the user must enable and disable the Nearby devices
permissions as a group; for example, users can't disable Wi-Fi access but keep
Bluetooth access enabled for a given app.
Strongly assert that your app doesn't derive physical location
When you target Android 13, consider whether your app ever
derives location information from Wi-Fi APIs; if not, you should strongly assert
that. To make this assertion, set the usesPermissionFlags
attribute to
neverForLocation
in your app's manifest file, as shown in the following code
snippet. This process is similar to the one you do when you
assert that Bluetooth device information is never used for location:
<manifest ...> <uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES" android:usesPermissionFlags="neverForLocation" /> <application ...> ... </application> </manifest>
Maintain backward compatibility
Because the NEARBY_WIFI_DEVICES
permission is available only on
Android 13 or higher, you should keep any declarations for
ACCESS_FINE_LOCATION
to provide backward compatibility in your app. However, as long as you strongly
assert that your app doesn't use the Wi-Fi APIs to derive physical location, you
can set the maximum SDK version of this permission to 32
, as shown in the
following code snippet:
<manifest ...> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" android:maxSdkVersion="32" /> <application ...> ... </application> </manifest>
Be aware that some APIs still require location permission
Several Wi-Fi APIs continue to require the ACCESS_FINE_LOCATION
permission to
access, just as they do on 12L and lower. Examples
include the following methods from the WifiManager
class:
Check for APIs that require the new permission
If your app targets Android 13 or higher, you must declare the
NEARBY_WIFI_DEVICES
permission to call any of the following Wi-Fi APIs:
WifiManager
WifiAwareManager
WifiAwareSession
WifiP2pManager
WifiRttManager
Wi-Fi access workflows
Figure 1 shows the Wi-Fi access workflow on devices that run
12L or lower. Note the reliance on the
ACCESS_FINE_LOCATION
permission.
Figure 2 shows the Wi-Fi access workflow on devices that run
Android 13 or higher, for apps that target
Android 13 or higher. Note that, as long as you assert that your
app doesn't derive physical location from Wi-Fi device information, you don't
need to declare the ACCESS_FINE_LOCATION
permission anymore: