we...@gmail.com  <we...@gmail.com>  #1 Oct 8, 2015 11:52AM
Reported Issue
Android version:6.0
Device: Nexus 6

I have used  'BluetoothLeScanner.startScan' to scan BLE devices, and I haven't got any callback in 'onScanResult' and 'onBatchScanResults'.

The app was granted the 'location' permission 'ACCESS_COARSE_LOCATION'.

But after my testing, if I enabled Location Service, it worked.

I think that not all BLE devices identify a location information, if I want to detect them, I have no need to open Location Service in Android.

Why do I scan BLE needing Location Service?
Is it really a bug in Android?

kf...@gmail.com  <kf...@gmail.com>  #2 Oct 12, 2015 04:40PM
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?
mw...@gmail.com  <mw...@gmail.com>  #3 Oct 14, 2015 05:05PM
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.
di...@gmail.com  <di...@gmail.com>  #4 Oct 15, 2015 01:02AM
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.
dn...@google.com  <dn...@google.com> Oct 15, 2015 06:28AM
Assigned to dn...@google.com
dn...@google.com  <dn...@google.com>  #5 Oct 20, 2015 10:50AM
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.
di...@entwicklung.eq-3.de  <di...@entwicklung.eq-3.de>  #6 Oct 22, 2015 06:42AM
I'm having the same issue with the Deprecated BluetoothAdapter.startLeScan on several Nexus 5 running Android 6.0
ze...@gmail.com  <ze...@gmail.com>  #7 Oct 23, 2015 04:59AM
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
[Deleted User]  <[Deleted User]>  #10 Dec 7, 2015 02:33PM
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!
ss...@google.com  <ss...@google.com>  #11 Dec 8, 2015 05:38AM
#11:please raise another AOSP issue,it is easy to track.

Thanks.
[Deleted User]  <[Deleted User]>  #12 Dec 8, 2015 10:23AM
#12: I raised another AOSP here: https://code.google.com/p/android/issues/detail?id=196485
pa...@google.com  <pa...@google.com>  #15 Dec 8, 2015 12:04PM
I have merged all the Issues in one thread so that its easy to track.
pa...@google.com  <pa...@google.com>  #16 Dec 8, 2015 12:07PM
Status: Won't Fix (Intended Behavior)
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
pe...@gmail.com  <pe...@gmail.com>  #17 Dec 8, 2015 12:11PM
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..
jj...@gmail.com  <jj...@gmail.com>  #18 Dec 8, 2015 12:35PM
Of course it works as intended in the Android documentation, but not as intended in the final user mind..
[Deleted User]  <[Deleted User]>  #19 Dec 8, 2015 01:34PM
#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?
[Deleted User]  <[Deleted User]>  #20 Dec 8, 2015 01:47PM
#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."?
[Deleted User]  <[Deleted User]>  #22 Dec 8, 2015 02:29PM
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
my...@gmail.com  <my...@gmail.com>  #23 Dec 8, 2015 03:04PM
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.
pe...@gmail.com  <pe...@gmail.com>  #24 Dec 8, 2015 03:27PM
#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
[Deleted User]  <[Deleted User]>  #25 Dec 8, 2015 03:41PM
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.
[Deleted User]  <[Deleted User]>  #26 Dec 8, 2015 03:41PM
[Comment deleted]
[Deleted User]  <[Deleted User]>  #27 Dec 8, 2015 03:42PM
[Comment deleted]
[Deleted User]  <[Deleted User]>  #28 Dec 8, 2015 03:46PM
#27: How do you perform "classic" search on Android 6.0 that don't require location services?
[Deleted User]  <[Deleted User]>  #29 Dec 8, 2015 03:49PM
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".
[Deleted User]  <[Deleted User]>  #30 Dec 8, 2015 03:50PM
#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.
[Deleted User]  <[Deleted User]>  #31 Dec 8, 2015 03:56PM
#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?
[Deleted User]  <[Deleted User]>  #32 Dec 8, 2015 04:00PM
#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.
[Deleted User]  <[Deleted User]>  #33 Dec 8, 2015 04:07PM
#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.
jj...@gmail.com  <jj...@gmail.com>  #34 Dec 8, 2015 06:35PM
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.
[Deleted User]  <[Deleted User]>  #35 Dec 9, 2015 03:31PM
#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.
pe...@gmail.com  <pe...@gmail.com>  #36 Dec 9, 2015 03:40PM
Just tested this and I can confirm startDiscovery() also requires the ACCESS_COARSE_LOCATION permission at least on Nexus 5 Android M
do...@gmail.com  <do...@gmail.com>  #37 Dec 9, 2015 03:40PM
#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.
do...@gmail.com  <do...@gmail.com>  #38 Dec 9, 2015 03:53PM
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.
do...@gmail.com  <do...@gmail.com>  #39 Dec 9, 2015 04:07PM
#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.
pr...@gmail.com  <pr...@gmail.com>  #40 Dec 18, 2015 08:18AM
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.
pl...@gmail.com  <pl...@gmail.com>  #41 Dec 18, 2015 10:47AM
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!
pe...@gmail.com  <pe...@gmail.com>  #42 Dec 18, 2015 10:53AM
[Comment deleted]
pe...@gmail.com  <pe...@gmail.com>  #43 Dec 18, 2015 10:55AM
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..
pr...@gmail.com  <pr...@gmail.com>  #44 Dec 21, 2015 01:34AM
[Comment deleted]
pr...@gmail.com  <pr...@gmail.com>  #45 Dec 21, 2015 02:07AM
#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.
ju...@gmail.com  <ju...@gmail.com>  #46 Mar 11, 2016 01:34AM
[Comment deleted]
ju...@gmail.com  <ju...@gmail.com>  #47 Mar 11, 2016 01:40AM
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
ho...@gmail.com  <ho...@gmail.com>  #48 Mar 11, 2016 11:18AM
Egg pain !!! scan BLE  need enable location Service .
dk...@gmail.com  <dk...@gmail.com>  #49 Apr 27, 2016 10:00PM
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!
su...@gmail.com  <su...@gmail.com>  #50 May 6, 2016 09:28AM
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..
ro...@gmail.com  <ro...@gmail.com>  #51 May 19, 2016 01:14PM
i agree this design is bad what!Google what where you thinking?
ka...@gmail.com  <ka...@gmail.com>  #52 Jun 2, 2016 04:34PM
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.
ri...@q42.nl  <ri...@q42.nl>  #53 Jun 21, 2016 09:05AM
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.
iv...@gmail.com  <iv...@gmail.com>  #54 Jun 21, 2016 11:01AM
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.
re...@zoom.us  <re...@zoom.us>  #55 Jun 22, 2016 02:19AM
Why does startDiscovery() also require the ACCESS_COARSE_LOCATION permission?
ed...@gmail.com  <ed...@gmail.com>  #56 Sep 29, 2016 05:09PM
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.
da...@gmail.com  <da...@gmail.com>  #57 Sep 29, 2016 05:29PM
#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?
am...@gmail.com  <am...@gmail.com>  #58 Oct 11, 2016 09:22PM
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"
an...@gmail.com  <an...@gmail.com>  #59 Oct 13, 2016 10:26AM
Just set targetSdkVersion 22
and it will work
ba...@gmail.com  <ba...@gmail.com>  #60 Dec 15, 2016 11:25PM
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.

na...@pax.com  <na...@pax.com>  #61 Jan 26, 2017 10:55PM
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
jt...@andromer.com  <jt...@andromer.com>  #62 Apr 13, 2017 07:29AM
[Comment deleted]
jt...@andromer.com  <jt...@andromer.com>  #63 Apr 13, 2017 07:31AM
[Comment deleted]
jt...@andromer.com  <jt...@andromer.com>  #64 Apr 13, 2017 07:34AM
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.
na...@pax.com  <na...@pax.com>  #65 Jun 16, 2017 10:50PM
@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.
ra...@gmail.com  <ra...@gmail.com>  #66 Jun 23, 2017 01:53PM
Exists any full code that implement all this fixes?? I'm not able to get work it well with a Marshmallow device. Thx!!
ch...@gmail.com  <ch...@gmail.com>  #67 Aug 10, 2017 07:28PM
Dumb. Android should at least match iOS in terms of developer experience for this.
ru...@gmail.com  <ru...@gmail.com>  #68 Oct 13, 2017 09:26AM
Google, you must change this. People do not want to get location tracked, when connecting to their BT Devices. Get yourself sorted!
ed...@gmail.com  <ed...@gmail.com>  #69 Oct 25, 2017 08:57PM
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
rb...@gmail.com  <rb...@gmail.com>  #70 Nov 9, 2017 10:33PM
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?
an...@phonepe.com  <an...@phonepe.com>  #71 Nov 16, 2017 03:59PM
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.
ge...@appliedresolution.com.au  <ge...@appliedresolution.com.au>  #72 Jan 3, 2018 05:31AM
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.
re...@orcam.com  <re...@orcam.com>  #73 Jan 22, 2018 08:38AM
Doesn't really making any sense that we will need location enabled to get a ble scan...
fl...@gmail.com  <fl...@gmail.com>  #74 Feb 19, 2018 12:06PM
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?
av...@gmail.com  <av...@gmail.com>  #75 Mar 27, 2018 01:06PM
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.
av...@gmail.com  <av...@gmail.com>  #76 Mar 27, 2018 01:07PM
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.