Name the actual Bluetooth operation
| Operation | Current permission family to review |
|---|---|
| Discover nearby Bluetooth devices | Scan access |
| Communicate with a paired device | Connect access |
| Make the device discoverable or advertise | Advertise access |
| Support older scanning behavior | Relevant legacy Bluetooth and location rules |
Follow the Bluetooth permissions guide for API-specific declarations, including when legacy permissions should be limited to older versions.
Do not assert “never for location” casually
A neverForLocation assertion should reflect the actual use of scan results. It is not simply a switch to avoid explaining location access. The platform documentation notes behavioral consequences, including filtering in some scenarios.
If the feature derives physical location from Bluetooth information, model and disclose that use honestly rather than declaring otherwise to simplify the prompt.
Check grants at the operation boundary
Request the applicable nearby-device access when the user pairs or connects a device, not at unrelated app startup. Handle denial, Bluetooth being disabled, no devices found and the device disconnecting after a grant.
A granted permission does not mean the adapter is enabled or that the target peripheral is reachable.
Test a useful compatibility matrix
Test a supported older Android release, Android 12-era nearby permissions and current target/device behavior. Include a fresh install, denied scan access, granted connection access and revocation after pairing.
Use representative peripherals. A test against one device model cannot prove compatibility with every Bluetooth service or manufacturer implementation.
Inspect the release manifest
APKLint's permission checker can help identify scan, connect, advertise and legacy declarations. It cannot determine radio availability, peripheral behavior or whether the app uses results for location. Keep the manifest review alongside runtime pairing and reconnection tests, with an explanation for each requested capability.
Separate discovery from an established printer connection
Consider an app that finds a Bluetooth label printer, pairs with it and later reconnects to print another label. Discovery and communication are different operations. Map the permissions needed for each supported Android version, then request the relevant capability when the user starts that operation. A connection to a known device should not be described as a successful new scan.
The Bluetooth permission guide distinguishes scan, connect and advertise capabilities for the applicable platform path. Advertising is not automatically required merely because the app communicates with a peripheral. Keep the manifest aligned with actual behavior instead of adding every nearby-device permission to address an unidentified failure.
Diagnose an empty scan without misreporting access
An empty device list can result from a denied grant, a disabled adapter, an out-of-range printer, incompatible discovery behavior or filtering. Show the state you can establish and offer the corresponding action. A granted permission should not cause the UI to claim a device is connected before service discovery and the application protocol succeed.
If the app asserts neverForLocation, verify that scan results are not used to derive physical location anywhere in its feature or dependency flow. The official documentation warns that this assertion can filter some BLE beacons. Test the actual peripheral classes the product supports; do not remove the assertion solely to make a test list longer without reviewing the app's real use and disclosure.
Build a synthetic print test containing an obvious unique label for each run. Print one label, disconnect or disable the adapter, then reconnect and send a different label. Confirm that the second operation does not display the first job's success or replay stale data. Test revocation between pairing and reconnecting so the operation fails clearly rather than crashing through a protected API call.
On supported older versions, validate the legacy permission and location branch separately. On newer versions, test the nearby-device request and the exact scan/connect grants used. Manufacturer behavior and peripheral firmware can affect discovery independently of Android permission rules, so record the device and printer models with the result.
For companion-device use cases, review the platform's supported pairing APIs as another design option. Permission inspection identifies declared capabilities; only an actual pairing, communication and recovery test establishes whether this application's peripheral workflow works.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
