IssueTracker

I have the same issue on a Nexus 9 running Android 6.0.

Is there any way to scan BLE devices without enabling location service?

I'm having the same issue. This doesn't seem like it should be necessary. For me I had to enable GPS in order for scanning to work. Now I must put a prompt up to tell the user they must enable GPS when our app actually has an optional tracking feature which they may have disabled. So now even customers who don' want GPS must turn it on to connect with the BLE device.

same issue with a Nexus 5 with Android 6.0. As previous comment says, we will now need to add something to ask the user to enable location. Doesn't make any sense since we don't need location at all at that point, we just need to scan for devices.

Hi,
Thank you for reporting this issue. We have passed this on to the development team and will update this issue with more information as it becomes available.

I'm having the same issue with the Deprecated BluetoothAdapter.startLeScan on several Nexus 5 running Android 6.0

It appears that only works when Location Services are on because of privacy, technically if you have a fleet of BLE beacons well placed and you know each beacon's location you can tell where the user is, so companies can target the user walking near a store and subsequently send them a notification.
We've to wait to hear why it is required now

I'm writing an app that connects to our Bluetooth LE device. We don't need the location in order to operate our BLE device. Google, please drop the necessity for granting the permission ACCESS_COARSE_LOCATION. I don't want our users to enable GPS in order to use our app. Thanks!

#11:please raise another AOSP issue,it is easy to track.

Thanks.

#12: I raised another AOSP here: https://code.google.com/p/android/issues/detail?id=196485

I have merged all the Issues in one thread so that its easy to track.

To access the hardware identifiers of nearby external devices via Bluetooth and Wi-Fi scans, your app must now have the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permissions

Link : http://developer.android.com/intl/ko/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id

All  BLE devices need location for identity, intrinsically you can't do one without the other.

Even the case cited, Nest pairing, is a location use case since its by proximity to nearby Nest devices.

Only Apps targeting API 23 have this more stringent requirement so existing Apps can prepare UX as needed for the runtime prompt

This is very strange design, I don't think you can ever explain to users why you need a location permission when using a BT device. So this will create support overhead on developer side..

Of course it works as intended in the Android documentation, but not as intended in the final user mind..

#12: You asked me to create a new issue because you say the problem is then easier track. So I did. But now my new issue has been merged back into this issue. Is that what you intended?

#17: Could you please clarify what you mean by

"All  BLE devices need location for identity, intrinsically you can't do one without the other."

Our BLE devices don't need location, they work well with API level < 23. Why do you state "you can't do one without the other."?

I sort of (sort of) get the need for requiring Location as beacons become more ubiquitous, but the logic for wrangling all the necessary Intents and system calls and saving stuff to SharedPreferences took my company several weeks of work. There are numerous edge cases to account for, especially considering most people will deny Location the first time around because they assume it means GPS tracking.

My hope is that these requirements are throttled back a bit in the next Android release, but in the mean time maybe others will find our solution useful: https://github.com/iDevicesInc/SweetBlue/blob/master/src/com/idevicesinc/sweetblue/utils/BluetoothEnabler.java

Please check the initial issue description.
>The app was granted the 'location' permission 'ACCESS_COARSE_LOCATION'.
>But after my testing, if I enabled Location Service, it worked.

The key issue here isn't the need of location permission, but the need to enable Location Service. Grant permission not enough.

#25: is right. I did just test that. This is incredible. To scan for BT devices you need the location service running. This makes sense! #wtfgoogle

Note that if Location Services are off you can still do Bluetooth classic discovery, which will return LE devices, but only their name and mac address. This may be enough to filter on if your device has a unique name.

[Comment deleted]

[Comment deleted]

#27: How do you perform "classic" search on Android 6.0 that don't require location services?

Please reread the problem. As the #25 and #26 previously said the issue here isn't the required permissions but the fact that the location services need to be enabled by the user to be able to scan for BLE devices. If the location services aren't enabled the app won't necessarily "crash and burn" but no devices will be discovered. This was tested on the Nexus 7. I really hope this isn't a case of "working as intended".

#30: BluetoothAdapter.startDiscovery() and BluetoothAdapter.stopDiscovery() and then set up a Broadcast Receiver.

Or use https://github.com/iDevicesInc/SweetBlue where you just call BleManager.startScan() and it automatically falls back to whatever scanning mode is available, pre-L, post-L, or Classic.

#32: The documentation about BluetoothAdapter.startDiscovery() says:

"The discovery process usually involves an inquiry scan of about 12 seconds, followed by a page scan of each new device to retrieve its Bluetooth name."

Looks like that the fact that scans take 12 seconds and only then names are retrieved is a huge disadvantage over bluetoothAdapter.startLeScan() / bluetoothAdapter.getBluetoothLeScanner().startScan()

It then takes much longer than on pre-API23 Android devices to find BLE devices without location services enabled.

Am I right?

#33: Not sure what the API docs mean. Classic Discovery is just as fast as LE scanning. For one project I did the fallback was fine because the devices had a very unique name, so full advertising packets with service UUIDs weren't even necessary. Alternatively maybe you have a block of mac addresses you can filter on.

#34: Our devices have unique names. Therefore, if devices are discovered  quickly enough, I'll definitely fallback to BluetoothAdapter.startDiscovery()

It's totally irritating and frustrating for our users that our app suddenly needs location services enabled.

Thank you very much for your hint to use classic discovery through BluetoothAdapter.startDiscovery() instead.

Google has not yet clearly stated WHY they want location services enabled for BLE devices that worked totally fine without location services before API 23.

Even without this very bad behavior (location service enabled to scan device), it makes no sense to ask a location permission from the user perspective.. An application connecting only to a smartwatch for example won't need this permission.

It's a bad design choice. If you think Bluetooth permission is bad because you can locate the user with beacons or so, you should define the Bluetooth permission as a dangerous one or define a new one and stop bother the user with an ambiguous permission.

#34: Classic Discovery via BluetoothAdapter.startDiscovery() also needs the ACCESS_COARSE_LOCATION permission.

The documentation states it here: http://developer.android.com/intl/ko/reference/android/bluetooth/BluetoothDevice.html#ACTION_FOUND

So users still need to be bothered with the location service when BLE devices are to be discovered.

At this point I see no advantage of using classic discovery over BluetoothAdapter.startLeScan. At least it doesn't require implementing intent filters and broadcast receivers. That's really a mess when you are first dealing with it.

Just tested this and I can confirm startDiscovery() also requires the ACCESS_COARSE_LOCATION permission at least on Nexus 5 Android M

#37: Yes you need ACCESS_COARSE_LOCATION *permission*, but you do not need actual Location Services enabled for classic discovery (at least not yet...I spilled the beans so maybe Google will lock that down too).

Permissions are a PITA but at least it only needs to be done once per app-install. Location Services are routinely turned off by users when not in use, so it's pretty nice to not have to bother them every time the app opens.

You're right that setting up Classic Discovery is a pain but see https://github.com/iDevicesInc/SweetBlue/blob/master/src/com/idevicesinc/sweetblue/P_BleManager_Listeners.java for an example of how to do it.

As the OP and many after after him said, the issue here is that although the app has been granted the location permissions, Location Services need to be turned *ON* whenever you want to connect to a LE device, because the connect depends on a LE scan.

At least, give us a way to connect to a specific LE device (identified by MAC) that works with Location Services OFF. There's no way of using that for finding the user's location.

To be honest, with the rise of IoT and the millions of bluetooth LE connected devices that are flooding the market, linking *Location Services* to a recurring connection was extremely close-minded.

#40 You can directly connect to a device with a known mac address without scanning beforehand. This is another way to get around this issue. You can "scan" for nearby devices with known mac addresses simply by trying to connect.

Of course at *some point* in the past you need to have scanned, but at least this way the app can still be functional in case user decides to deny services some particular time.

Hi,
I think two topics in this thread.

(1) To get BLE scan result, need enabling Location Service.
(2) To get BLE scan result, need ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permissions.

I'm understanding them as follows.

----------------------------------------------------
Q: Which is a main topic in this thread?
A: Main topic is "(1)".

Q: Does some open document have the explanation about it?
A: (1)No.
   (2)Yes. ex.:http://developer.android.com/intl/ja/reference/android/bluetooth/le/BluetoothLeScanner.html#startScan(android.bluetooth.le.ScanCallback)

Q: About the coping method, are the guidelines for application developers shown?
A: (1)No.
   (2)Yes. ex.:http://developer.android.com/intl/ja/training/permissions/best-practices.html
----------------------------------------------------

I think topic"(1)" gives heavy damage for application developers.
Because the application developers have to notify an application user about enabling Location Service being necessary by self application UI.
Furthermore It does't provide any coping method, The application developer must think about the method by oneself !!!!

I strongly hope to return it to the implementation of the lollipop.

thanks.

I agree 100% on comment #43.

The issue is not the permission but the fact that we have to have ocation services running to use BLE scan (actually to receive the results). Trying to explain that to the app user is doomed to fail...

So the above "WorkingAsIntended" is really wrong in this case since surely no-one would intend a feature work this obscurely...

Please Re-open!

[Comment deleted]

Disagree with #44 and #43

For 1) there is at least a workaround for some use-cases, you can use discovery instead of scan, than there is no need to have the service on.

But 2) much more severe. The permission is very hard to explain to users. IMHO 99% won't understand how you could possibly get their location from BT devices, they will recognize your app as malicious or spyware and this will lead to uninstalls and bad ratings. The think that this is documented does not make it a good design..

[Comment deleted]

#44,#46: Thanks for your comment.
#46: I understand your opinion. I wish google to correct topic(2) too, in my mind. But, as you recognized in #26, the key issue here is topic(1).

I think both topics are very hard to explain to users. But Google answered in #17 about topic(2) only and closed this thread. As commented in #35, Google has not yet clearly answered about topic(1).

Unfortunately, I recognized topic(2) as specifications of Marshmallow based on security policy of Google. But I cannot understand topic(1) without enough explanation from Google.

[Comment deleted]

Fucking, Google, how do I explain to the user "I need permission to scan BLE devices???????
What do you think? I think you stopped to think

Egg pain !!! scan BLE  need enable location Service .

This appears to be a very bad design by Google, or a tactical design to get users to enable location services and then forget to turn it off.  Enabling location services does not only affect the bluetooth low energy scans, but then allows others apps to gain access to location data when the user may not intend it to do so.  Please change this behavior Google!

It is very simple - for most of BT LE devices (wearables, body sensors and similar)the location is well known - it is on user's body :-). For Google: maybe you should implement the KISS principle and think what are you doing..

i agree this design is bad what!Google what where you thinking?

I also agree that the design is bad - as long as there is no disclaimer in the UI why the GPS is needed. If make such design, then please, remember about user experience. People don't know why they need GPS to use a GPS irrelevant BT device.

Does this have something to do with Bluetooth Proximity protocol, which is part of Bluetooth LE? Bluetooth Proximity allows for acquiring a relative location, which can be converted to an absolute position.

To me, that feels like the only logical explanation for requiring Location permissions with Bluetooth LE.

Yes, there is no question that there are ways to obtain the user location through a Bluetooth scan. The problems are these:

- It is not documented that you need location services to scan. Not in the BLE developer guides and not in the BluetoothLeScanner API reference.
- No thought was given to user experience. Now the process for initiating a bluetooth scan is way too cumbersome. You need to launch a system dialog to enable the bluetooth adapter. You also need a system dialog to get location permissions; since the system doesn't help explaining to the user that this is needed for a bluetooth scan, you'll probably need another dialog for explaining this. Finally, you need to launch the location settings activity, where you depend on the user figuring that they just need to toggle the location settings, and then you don't even get a callback.

I realize it might be difficult to come with an alternative to improve user experience, but currently the problem has just been pushed to developers without any documentation or guides.

Why does startDiscovery() also require the ACCESS_COARSE_LOCATION permission?

From the standpoint of strictly connecting to a bluetooth low energy device, the requirement that you shall demand and require location services to both be granted (documented) and enabled (undocumented) is unacceptable.

Coming from an iOS background, Apple very cleanly decoupled their beacon/location API from bluetooth entirely. I understand that obtaining the MAC address of a device in itself can be a privacy concern, one could do proximity tracking. That being said however, for applications that don't have any location use case shouldn't have to demand the user grant location, and have location services enabled.

Say you want to connect to a heart rate monitor, or some other gadget and you connect to it via BluetoothLeScanner.startScan w/ service UUID filters--there is no way of doing this without the location items mentioned above.

I hope Google's Bluetooth LE API gets completely overhauled when 5.0 comes out. Even if there was a big refactor of the API like from 4.4 to 5.0, the percentage of users that could access it wouldn't be high enough. Android M is almost to 20% on the dashboard. N isn't even up there yet.

#59: Yes!

Perhaps we should open up a FeatureRequest where to discuss allowing Bluetooth LE scans without revealing location-specific data like MAC address unless location permission and location services are enabled. AFAIK that's what CoreBluetooth does on iOS?

Hi everyone, google API > 23 says : "startScan....Requires BLUETOOTH_ADMIN permission. An app must hold ACCESS_COARSE_LOCATION !OR! ACCESS_FINE_LOCATION permission in order to get results.".

My app has AT LEAST ! Acces_coarse_location permission :
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-feature android:name="android.hardware.bluetooth_le"  android:required="true"

I made sure to request manualy to the user to permit the COARSE location service.
"ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_COARSE_LOCATION}, 1);"

The problem is I done exactly what the doc told me.. but I MUST also activate the GPS (the Location Service) in order to discover the ble.

Is this a google api Documentation problem or a software glitch ?

I spend almost 1 week to figure out this problem... and I Hope it's not a doc problem ! Bluetooth ble should not depend on GPS...! because It will be no more "Low Energy"

Just set targetSdkVersion 22
and it will work

Thank you!!! Lowering the targetSdkVersion finally solved the problem for me.

FYI, for anyone struggling with Classic. I have a Nexus 7 2013 and the two changes I had to make were:

1. Setting ACCESS_COARSE_LOCATION (yes, documented, but not on Google's top-level tutorial page and missing from their included example).
2. Setting targetSdkVersion 22 in app/build.gradle.

This work around is not a good workaround.  Google encourages you to build against the latest SDK.  Google, you know about this issue so when are you going to fix it?  We are receiving complaint after complaint because users are afraid we are using their location for other things.  We let them know exactly why we need it, but still the complaints keep flowing in.

Fitbit: https://community.fitbit.com/t5/Android-App/location-services/td-p/1194269
Android Forum: http://androidforums.com/threads/bluetooth-pairing-requires-location.1003404/
Third party library built to just fix BLE issues, including handling location services: https://github.com/iDevicesInc/SweetBlue/wiki/Android-BLE-Issues
Garmin: https://forums.garmin.com/showthread.php?341559-New-GCM-requires-location-to-sync&s=3f20db4b13798f7bdb7d4493c15877e7


Twitter messages:
"@Garmin @pjcjohnson Why? Android says that it's on you guys. WTF is up with needing GPS to pair?"
@drevilsj :"upgraded GSS5 to Android 6; now the changes in bluetooth & location services is making me rethink #Google programming #hateit"
@Mezentine: "Why does Android 6.0 need Location on to scan for Bluetooth devices?"
@sammer2001: "@Android do apps now have to use location to use Bluetooth?"
@nirvdrum: "@AnovaCulinary Why does the Android app require location access to pair with bluetooth? That seems unnecessary at first blush."
@TDAStephen: "But question remains for @google - why does #android require location for Bluetooth functionality? It wasn't always this way @FitbitSupport"
@Genesis_Bound: "@Android any idea when location requirement on bluetooth sync will be removed? As a major security issue left no choice but downgrade"
 ‏@internetofdongs: "Really @Android, Bluetooth connections in 6.0+ require location permissions? https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id … Thats a privacy nightmare for dongs"
@samthehobbit_98: "hey @jawbonesupport, why does the latest android UP app require my phones location to sync my data over bluetooth?"
@TimothySCarter: "@AndroidDev, @Android, Any idea why the Bluetooth Remote device discovered now requires ACCESS_COARSE_LOCATION?"
@9thcircledesign: "No, @fitbit, I am not going to turn on location services for my phone just to sync. It's completely unnecessary and invasive."


Though this is old news, companies are literally not building products for it. http://www.pocket-lint.com/news/124762-nike-lack-of-bluetooth-le-support-is-why-there-s-no-android-fuelband-app

[Comment deleted]

[Comment deleted]

Unfortunately, the combination of ACCESS_COARSE_LOCATION and targetSdkVersion 22 does not work on some devices.<br>This is not a good method, but I have solved it in the following way without using runtime permissions (ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION)

 1. Set your 'targetSdkVersion' to 19 (I think maybe api19 ~ api22 will be possible)
 2. Add the following permission to your manifest file

        <uses-permission android:name="android.permission.READ_OWNER_DATA" />
        <uses-permission android:name="android.permission.WRITE_OWNER_DATA" />

tested to Android 4.4 ~ 7.1.1

This is not a good solution and I think Google should separate BLE permissions and location permissions.

@jt, If I remember correctly from when I was investigating this, iOS uses location when scanning for BLE, they just do it without the user knowing which is what I suggest Android does.

Exists any full code that implement all this fixes?? I'm not able to get work it well with a Marshmallow device. Thx!!

Dumb. Android should at least match iOS in terms of developer experience for this.

Google, you must change this. People do not want to get location tracked, when connecting to their BT Devices. Get yourself sorted!

WTF is going on you need to fix this because there is no way I need to have GPS on to connect to BT on any of my other apps. Only reason I can think of this is because you are tracking to ssee where this is being used like when driving? It is also draining my battery Samsung S7 in 40min totally uncalled for and I am bringing the device back for a refund

As a user, I just ran into this issue and immediately questioned why a Bluetooth Thermometer required location permissions to be enabled.  It is a thermometer that will sit in my house and never go anywhere else.  Why should the app need access to my location to work?  

Google's response of, "“The MAC address and the SSID can be used to identify surrounding devices. Knowing the location of these devices can be used to infer the phone location. As we have no way to know if the app would try to infer user’s location via WiFi scans we take a conservative approach to protect the user’s privacy. If an app is targeting pre M SDK does not have ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION it will get scan results only if it is in the foreground. For M SDK apps the location permission is required to get scan results” doesn't make sense to me.  

#57 concept of "allowing Bluetooth LE scans without revealing location-specific data like MAC address unless location permission and location services are enabled" sounds very reasonable.  Google, you need to fix this issue.  You say this makes my privacy more secure...please tell me exactly how providing an app permissions to my location, when the device I'm connecting to has no need for my location, makes me MORE SECURE?

Hi

Response to # 16
'All  BLE devices need location for identity, intrinsically you can't do one without the other. '
That is an invalid assumption, for the following reasons :
1. All BLE devices don't need location for identity. For example, there are many use cases where all the phone needs to know is that there is a compatible BLE device around, based on MAC address, beacon data or some other such proprietary method. The location doesn't matter. Example : a BLE beacon that advertises it's presence to an app that is looking for it. It can then connect to the beacon and perform specific functions. In this case, identification is important, but location is not.
2. All BLE devices don't need identity either. Example: Google's own project, Eddystone and Physical Web, using Eddystone-URL  is an example. In the case of the Eddystone-URL beacon, the URL itself is what needs to be presented, and no further identification may be necessary. In this case, identity itself is not needed.

These cases are where location and (possibly) identity are not required. Of course, there will be many cases where they are required, and used in that manner.
The decision to require Location permission for beacon scanning seems like a reasonable choice to make, as it informs the user that their location might be tracked by means other than actual GPS. However, by NOT documenting that Location service does NOT need to be running after permission is available, Android has opened the doors to arbitrary implementations where some manufacturers require the SERVICE to be running, not the PERMISSION to be granted. This completely throws the user experience out for a user when the Blueooth is off.
a. First, the user has to give permission to switch on  bluetooth if it is off
b. Then the user has to give permission to switch on location if it is off.
This makes the user suspicious as well, about why their GPS location is needed to scan for a beacon.

It would be great if Google recognised this as an experience issue and worked to remedy it. Even adding a simple line of documentation would go a long way in providing a good reference to the manufacturers who customize Android to enable app developers to deliver a great experience.

My application devices are Tablets that use BLE to connect and control our tech devices locally.  These devices do not have location options on them with GPS. I have wound all my SDK options to 22 to get around this.

Doesn't really making any sense that we will need location enabled to get a ble scan...

To be clear, getting permission for location is not enough anymore? we need to force user to switch on location to scan BLE devices? am I wrong?

This seriously needs fixing and stronger definitions how it must work. This literally makes Bluetooth LE unusable for Android apps, the implementations differ so much, they're inconsistent and nothing works like it should, it basically killed a startup here in Estonia. You need to fix this.

It's not only that it requires these permissions, even then it's not guaranteed that we get scan results at all and that's horrible behaviour that should be forbidden.

When is the fix date for this bug? It has really been hanging out here for quite some time.

This getting fixed?

Same issue. Pax app. Pixel 2 XL Android 8
I really don't want to have to turn on location just to connect to my product.

Any chance this is getting fixed anytime soon? I'd luv to be able to use the PAX app in order to use my PAX 3 properly...
There is no way in hell I'll ever turn on Location on my Tablet.

Tablet Location: In one of my hands.
PAX 3 Location: In my other hand.

Can I now use the free app that has been made for the 300$CAD device I've paid for in full, over 6 months ago? Please?!? -.-

Maybe a dedicated permission for BLE permission?  Requiring location service completely defeats the purpose of the "Low Energy" part of the BLE feature.

Hello,

We are working on an app which scans and reports BLE tags.  As required, we have enabled the location services in the device, even though we don't use the same.  We are facing strange behavior that the device doesn't report BLE tags where the location data seems to be unstable (inside high rise buildings/ bunkers).  The device responds well in detecting the tags when we try at other locations, typically open area/buildings with open access/minimal floors.   How can we overcome this difficulty?

Hi, as user and developer I must say this is at least ethically questionable, the "mean" of low energy is broken here, for example I have an app that uses a pulsometer with my phone, I'm low battery on this, I think no problem, because it is low energy, you know, but surprise, I need to turn on my GPS (and maintain it) because otherwise the app will not connect to my pulsometer. As #43 says, i rate with 1 start the app, but is not the developer fault, is yours. So, do you have plans to fix this?

As a developer and a user I believe this is very silly also unnecessary enforcement. I want to use bluetooth scan for my work, why do I need to ask permission from user and make them enable it for bluetooth scan? This is the most nonsense thing I've ever heard on Android platform.

As a developer and a user, fix this, it is a bug. This enables and encourages location tracking by any and every application that I want to use bluetooth with. That is unacceptable and makes the bluetooth ecosystem completely useless for your entire OS for anyone who does not want their location tracked. The granularity of having it be when the app is 'open' does not solve this problem for things that then go to the background and then lose connectivity on the next round. This is a ridiculous requirement that is not present in your main competitor's product, so it is a solvable issue. I do not understand your reasoning, and the cavalier 'will not fix' answer is not sufficient.

This has recently gotten worse, not better. I'll direct you to this comment on a similar thread from 2016, where the issue is pointed out as solved by Apple, again. https://issuetracker.google.com/issues/37074104

> Coming from an iOS background, Apple very cleanly decoupled their beacon/location API from bluetooth entirely. I understand that obtaining the MAC address of a device in itself can be a privacy concern, one could do proximity tracking. That being said however, for applications that don't have any location use case shouldn't have to demand the user grant location, and have location services enabled.

That statement still is completely valid 3 years later.  Do we need to open a new issue on this so someone will look at it again?

Won't Fix == FOAD, apparently.
Just because the behavior is intentional does not mean it is right or smart.

Please fix. This is a bad designand flies against the principles of least privilege.

This also ties a communication scheme engineered primarily for low energy consumption to one of the biggest battery eaters on any average smartphone. Leaving GPS running constantly basically converts my phone into a hand warmer that lasts only a couple hours. It also broadcasts all of my location history to whoever is buying my data.
There is no convincing reason these should be tied. Period.
I encourage every developer that is not bought by Big Data to complain to Google about this. Saying that this $hitty design is "Intended Behavior" does not change the fact that it is a bad design. Anything powered by a battery needs to be designed with the understanding that the customer probably doesn't want to be stuck at a battery charger or constantly replacing dead batteries.
This is the kind of crap that has me looking at any alternatives to Android.

Maybe in Android 13 they change this behavior because as of now they are too incompetent/lazy to think of a proper solution.

Switzerland's whole official COVID Tracing app is unable to run on Android in Battery saver mode. In other words, the whole battery saver mode is not usable anymore if you decide to run our SwissCovid Bluetooth Tracing App.

This is NOT acceptable and NOT COVID-friendly at all. Please, allow us to do contact tracing and change this NOW! Thanks.

https://github.com/DP-3T/dp3t-app-android-ch/issues/61

Are you kidding me!

We have just spent considerable manpower trying to solve customer complaints that were caused by this ridiculous behaviour. After a while we were lucky enough to find a device where we could reproduce it and track it down with the logcat output.

/BluetoothUtils: Permission denial: Location is off.  

So to summarize: We declare in the manifest that we need Bluetooth, we ask the user for the runtime permission "coarse/fine location" (we even explain this to the user upfront) and after all of this we are ****** not allowed to do a Bluetooth scan because the user has l?

And there is absolutely 0 documentation on this? And no documented way to handle this? No feedback to the user?

Quote from the API docs: https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#startDiscovery()

"If Bluetooth state is not STATE_ON, this API will return false. After turning on Bluetooth, wait for ACTION_STATE_CHANGED with STATE_ON to get the updated value.
Requires Manifest.permission.BLUETOOTH_ADMIN"

Intended behaviour??? I don't think so

It’s a shame that Android have stuck to Location permissions for classic Bluetooth scanning.
It’s also annoying that with location services turned off you can use Android OS to scan Bluetooth devices. :(
I agree it needs to be re-looked at but we are now on Android 12 with no sign of change

We got a rejection because we requested to use a Location Service and the app can't be published. Android team, please take care of this and manage this with the review team/algorithms which requested some descriptions which are not verified at your side.

some signs of change in Android 12?
https://youtu.be/D2cU_itNDAI?t=1286

please what is the definitive solution about this topic? there is a way to scan ble devices without requierd turn on Gps in android 8,9,10, and 11?

There is no option. As per https://issuetracker.google.com/issues/148429135 this was finally implemented in Android 12, but it will not be ported / patched into previous versions.