Incorrect permissions handling on lower target sdk apps

[jamorham]

Describe the bug
Scan permissions handling does not seem to be correct for apps with target sdk less than 31

It appears to me that on later android versions (likely 12+ but only tested on 16) that the presence of the BLUETOOTH_SCAN permission in the manifest means that the permission handler for bluetooth requires this permission to be granted even if the app targets a lower sdk version before this permission was introduced.

This behavior differs from other ways that target sdk affects how the android framework treats apps.

I believe that the fix would be in ClientComponent.java provideRecommendedScanRuntimePermissionNames to change the line which says:

int sdkVersion = Math.min(deviceSdk, targetSdk);

To something like:

boolean permissionsPresentEvenWithLowerTargetSdk = (targetSdk < 31 && deviceSdk >= 31) && isNearbyServicesNeverForLocation;
int sdkVersion = permissionsPresentEvenWithLowerTargetSdk ? deviceSdk : Math.min(deviceSdk, targetSdk);

What do you think? I can provide a PR for this fix which I am currently testing on a local fork.

[dariuszseweryn]

Hey, thanks for rising this!

I imagine that at some deviceSdk the targetSdk allowing for using legacy permissions may not be respected but I have not found any info about it.

This behavior differs from other ways that target sdk affects how the android framework treats apps.

I am a little bit surprised that it did not surfaced earlier in the lifetime of this library as the same approach is used throughout it for other permissions checks. Could you give an example? (I am not into Android dev for quite some years now)

[jamorham]

If you target sdk 24 in an app using rxandroidble and have android.permission.BLUETOOTH_SCAN in the manifest then currently it does not work. I have a modified fork with the changes I mentioned previously and this does work.

[jamorham]

Is there any time/interest in looking at this issue? I can provide a PR, but otherwise I am planning to start using my fork as the dependency. I would prefer to be able to be able to use the official upstream repository of course.

[dariuszseweryn]

I hoped for getting my hands on a proper device to test but failed on that front. Since there is No other work batched for the release, potential revert will be easy so I'll rely on your report only.

Please provide a PR and we will roll with it. Thanks!

Edit: and sorry for the delay. Life's not easy to manage :)