Some surveys and analytics showed that users very often turn down Location Permission request appearing in the mobile app even if this permission is crucial for the app, e.g. the app performs automatic scan for devices in a venue that handle business logic and exchange data with the mobile app. The permission request turn down rate is so high that it becomes problematic for business. Is there any way in Android to avoid this, e.g. to declare some verified devices that can be scanned without permission request? I thought of https://developer.android.com/guide/topics/connectivity/companion-device-pairing but it also means popping up requests for manual work for the user. Is there any way today to do it behind the scenes?
Unfortunately this is not possible for privacy and security reasons. Enabling BLE on Android devices goes hand in hand with the location permission. The only possible workaround for this is potentially if you use classic Bluetooth instead of BLE. I am not 100% sure about this one, but it is mentioned in this article:-
No one can use BLE scan API without having Location Permissions, and,
on most devices, it is useless without active Location Services.
However, Bluetooth Low Energy is an extension to so-called Bluetooth
Classic and interestingly enough Google decided this API does not need
location permissions to be called.
This is an OS requirement which cannot be overcome. You might've already seen this on the Android developer page for BLE:-
In order to use Bluetooth features in your application, you must
declare two permissions. The first of these is BLUETOOTH. You need
this permission to perform any Bluetooth communication, such as
requesting a connection, accepting a connection, and transferring
data.
The other permission that you must declare is ACCESS_FINE_LOCATION.
Your app needs this permission because a Bluetooth scan can be used to
gather information about the location of the user. This information
may come from the user's own devices, as well as Bluetooth beacons in
use at locations such as shops and transit facilities.
You can find more info about this here:-
The Ultimate Guide to Android BLE Development
Location needs to be enabled for BLE on Android
Bluetooth versus Location Permission
Related
I am using the android (org.altbeacon:android-beacon-library:2.19.3) library providing APIs to interact with Beacons
It has required Location & Bluetooth permission.
Permission Requirements:
https://altbeacon.github.io/android-beacon-library/requesting_permission.html
IOS's ibeacon does not require Bluetooth permission, why does android ibeacon need Bluetooth permission?
is there any alternate library for android Ibeacon
Yes, Android requires Bluetooth permission to scan for bluetooth beacons but iOS does not require the same permission to detect iBeacon. The requirement for Android to have Bluetooth permission to scan for beacons is true regardless of the library you use. It is an OS platform restriction.
The reason why Android requires this permission and iOS does not is based on history of how the two platforms evolved. A few points:
Starting with iOS 7, Bluetooth beacons support was added to the CoreLocation API, which used the Location permission, not individual permissions for various sensors like GPS, WiFi, cellular radio, and Bluetooth, all of which can be used for location purposes. Apple clearly made a design decision to put all of the sensors behind a single permission.
Open Source Android has no built-in APIs for detecting beacons at all -- it only has Bluetooth APIs. (Beacon APIs are offered by the Google Play Services add on or the open source Android Beacon Library). So it makes sense that when Bluetooth LE scanning was added in Android 4.3, it was treated as something that must be behind the Bluetooth permission.. These APIs happened to work with Apple's iBeacon invention, but the APIs were not designed for location.
When Android added runtime permissions in Android 6, it tried to protect the privacy of users by making the Location permission a runtime permission, and further, it put Bluetooth scanning behind this same location permission in addition to the Bluetooth permission in an attempt to protect privacy.
On iOS, the Bluetooth LE APIs do require Bluetooth permission, and Apple sandboxed the Bluetooth functionality from iBeacon. In this way, detecting iBeacon must obtain Location permission and does not require Bluetooth permission. On the other side of the coin, non-iBeacon detection is possible with regular Bluetooth permission but Apple filters out any packets that match iBeacon. Android has no equivalent sandboxing, which is one reason both permissions are required.
One important thing to note: Apple not needing Bluetooth permission to detect beacons only applies to the iBeacon format. If you try to detect AltBeacon or Eddystone you actually do need the Bluetooth permission (and not the Location permission for those formats.) This is a "loophole" that is useful for avoiding extra permissions in some cases on iOS devices.
One final note: Starting with Android 12, there is a new BLUETOOTH_SCAN permission that you can use instead of location permission. The idea is to make it so Android no longer requires location permission to scan for regular Bluetooth devices. But there is a big catch: to use this new permission, you must declare in your AndroidManifest.xml that your app does not use Bluetooth for location purposes (e.g. beacons) and Android says it will filter out some scan results in these cases. They don't say explicitly, but that probably means they will filter out any Bluetooth packet matching a known beacon format like iBeacon, AltBeacon or Eddystone.
The working logic of the Android side and the working logic of the ios side are different. On the Android side, we need to get a permission for every action related to the user. This is among google policies. There are different libraries developed for the location, but you need to add permissions in the same way. For example, another package you can use for location: https://github.com/mrmans0n/smart-location-lib
or all : https://android-arsenal.com/tag/55
I googled very hard and still no explanations "why?" these permissions are needed to establish offline(no internet) connection between devices. I have simple app that requires only p2p-star strategy to exchange data between devices in master-slave pattern and I have troubles explaining to my users why my app needs them. "Just because lib said so. That's why".
Official documentation also said nothing to me.
"A primary goal of this API is to provide a platform that is simple, reliable, and performant. Under the hood, the API uses a combination of Bluetooth, BLE, and Wifi hotspots, leveraging the strengths of each while circumventing their respective weaknesses. This effectively abstracts the vagaries of Bluetooth and Wifi across a range of Android OS versions and hardware, allowing developers to focus on the features that matter to their users."
PS: as I know ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION are about GPS
PSS: in case this question will be answered here
https://github.com/android/connectivity-samples/issues/204
Because Bluetooth and WiFi scans can reveal the user's location, either as an approximation ("Family Room TV" was discovered, so you must be home) or in detail (Device A, B, and C were last seen at lat/lng X, so we think you're probably at X).
https://developer.android.com/guide/topics/connectivity/bluetooth-le#permissions
I have an estimote beacon, i want to display a notification, when user comes in beacon range.
I was checking estimote beacon's android integration document, and found out that it requires location permission.
Estomote official app also does not work, if location permission is not granted.
My question is how to make beacon work without asking location permission, or if beacon does not work without location permission then what's the reason of using beacon, or am i missing something very important.
Android 6+ requires an app to obtain either COARSE_LOCATION or FINE_LOCATION permission at runtime in order to detect Bluetooth LE beacons or do Bluetooth LE scans at all. Without the permission, the OS blocks beacon detections. This is not an Estimote-specific issue -- it applies to scanning for any Bluetooth LE device.
This requirement was added to protect the privacy of users. The theory is that a runtime permission dialog makes it clear to a user that the app is accessing the user's location and ensures the user is aware of this and consents to the practice.
BLE scanning faced a remarkable difference Marshmallow onwards with the requirement of location of device to be ON. Technically, I don't see a valid reason why location would be required to scan for BLE devices. Why has this been done by Google?
Q: Why has this been done by Google?
A: Because BLE scanning is commonly used to determine a user's location with Bluetooth LE beacons.
I discussed this with Google engineers at a Q&A session at Google I/O 2015 when the change was still not released. At the time, my concern was having to ask for Bluetooth LE Admin permissions to scan for location beacons. For me, this was a problem because users understood that my app needed to find a user's location, but did not understand why it needed to administer Bluetooth.
The engineers' response was that location permission (and location on) would be needed to do this in Android M to make this clearer to users. Unfortunately, from my perspective Bluetooth Admin permission is still required for historical reasons.
You can certainly disagree with Google's decision. But the reasoning is clear. If an app can scan for Bluetooth devices and can read their MAC addresses or other identifiers, it can also determine a user's location if the app developer knows where some of these scanned devices are located.
Why the same location permission logic does not apply to scanning WiFi or Bluetooth Classic (both of which would allow the same thing) is less clear. Perhaps it is just that Google was preparing to join the Bluetooth LE beacon game with their Eddystone standard.
Correction: Location permission is required for WiFi scans.
I'm in the middle of building a Wear App for an existing phone app.
We plan on targeting API 23 and modifying our phone app's location permissions to work with Android new runtime permission model (https://developer.android.com/training/permissions/index.html)
I was trying to figure out how the Wearable device running Android 5.0 is going to work once we do that. From what I've learnt when asking for locations for the Wearable from https://developer.android.com/training/articles/wear-location-detection.html:
The wearable may or may not have a GPS radio present. For wearables that do not have a radio, the location data comes from the tethered device.
We don’t need to worry about the source of location data – FusedLocationProvider (as part of the Google Play Service) handles this for you behind the scene.
We are responsible for handling the edge case where the wearable does not have GPS hardware (can be checked via hasSystemFeature()) and if the tethering is interrupted (can be detected via WearableListenerService). An example of this would be when the user goes for a run without the phone. In this case, we are expected to degrade the functionality gracefully.
What’s puzzling me is how this will work when we migrate to the new Marshmallow permission model.
Android Wear is not affected if the hardware has on board GPS since no wear devices run Android 6.0 and the old permission model applies. The problem would come about if a wear device with no GPS hardware is tethered to a device running Android 6.0. In this case, if the wear device requests for the location, it would passed on to the phone and the user has not been asked permission/or has disabled the permission, how will this work at all?
I'm imagining that need to hack around this:
On wearable app start, first check if the hardware has a GPS radio
If no, send a message to the phone to ask if holds the permission for requesting location (use the data sync APIs for this)
If the answer comes back false, then show a message to the user on the wearable and ask if they want to resolve it on the phone.
If the user answers “yes”, push a message to the phone to show an activity where it would just prompt for permission.
Is there a better way to do this?