Android Bluetooth permissions when targeting SDK 29 and running on Android 12

Question

So just assume for a second that I don't have a choice (which technically I don't). I am in a situation where an older build of software that targets SDK 29 needs to run on Android 12.

I can't change the target to 31 as it would require a complete regression of the app (it's a cordova application) and QE won't go for it without full regression.

• First question : since it's Android 12...am I required to have the BLUETOOTH_SCAN permission? If so I'm assuming it's impossible to request it at run-time since I'm targeting 29.

Is my assumption correct?

• Second question: can someone help me truly understand targetSdk versus compileSdk? I believe compileSdk is the meat and potatoes of the app. This is the API that's available to me during development.

If so, what's the point of targetSdk? I'm reading that targetSdk is something about "well our app was tested an validated against targetSdk 'XX'. Ok...but how does that really impact anything beyond being meta-data'ish?

• Lastly... What do you think would happen if I targetSDK 29 and attempt to request BLUETOOTH_SCAN permission?

Thanks

Answer 1

First Question Yes, you need to add BLUETOOTH_SCAN to your manifest file.

Bluetooth permission are run-time permission, you always need to request them at runtime. Check this https://developer.android.com/guide/topics/connectivity/bluetooth/permissions

Second question

compileSdkVersion: this represents the version of android that your app is compiled against. It determines which Android features and APIs you can use in your code.

targetSdkVersion app will behave differently depending on the version. Usually it is equal to compileSdkVersion but it is not mandatory.

Let's consider android 14. Stable release is approaching, but you might not have the time to fully support it. What you can do is increase targetSdkVersion to 34 (android 14) this means your app can benefit from android 14 optimization and new features that.

All optimization and features that comes without you (the developer) asking for them in the code will be used automatically to user running android 14. However, features that require developer implementation, like new run-time permissions is up to the android team to handle any incompatibility issue.

Answer 2

The Android Guide on Bluetooth permissions shows you the permissions needed for your specific targetSdk. That means you need to refer to this section where it states:

If your app targets Android 11 (API level 30) or lower, declare the following permissions in your app's manifest file:

• BLUETOOTH is necessary to perform any Bluetooth classic or BLE communication, such as requesting a connection, accepting a connection, and transferring data.
• ACCESS_FINE_LOCATION is necessary because, on Android 11 and lower, a Bluetooth scan could potentially be used to gather information about the location of the user.

Your second question was already answered here: What is the difference between compileSdkVersion and targetSdkVersion?

compileSdkVersion

The compileSdkVersion is the version of the API the app is compiled against. This means you can use Android API features included in that version of the API (as well as all previous versions, obviously). If you try and use API 16 features but set compileSdkVersion to 15, you will get a compilation error. If you set compileSdkVersion to 16 you can still run the app on a API 15 device as long as your app's execution paths do not attempt to invoke any APIs specific to API 16.

targetSdkVersion

The targetSdkVersion has nothing to do with how your app is compiled or what APIs you can utilize. The targetSdkVersion is supposed to indicate that you have tested your app on (presumably up to and including) the version you specify. This is more like a certification or sign off you are giving the Android OS as a hint to how it should handle your app in terms of OS features.

Regarding using BLUETOOTH_SCAN with targetSDK 29: Since it was introduced with API level 31 it would fail to compile if your compileSdk is set below 31. If only your targetSDK is below 31 the cited paragraph above comes into effect:

If you set compileSdkVersion to 16 you can still run the app on a API 15 device as long as your app's execution paths do not attempt to invoke any APIs specific to API 16.

I would assume your app crashes or gives you an error message but I did not test this.