> "Since the Android app requires location permissions to use the hardware device"
God because Blutooth LE devices need location permission on Android? How is that still a thing, I remember being outraged about that a decade ago or something.
God because Blutooth LE devices need location permission on Android? How is that still a thing, I remember being outraged about that a decade ago or something.
It's a tricky problem. As a more technical user, I'd love it if they were separate permissions and the Bluetooth permission included an extra "your location can be determined from bluetooth alone" warning. But for the average user that's just going to confuse them.
On Android apps that don't use Bluetooth to derive location, and assert that they don't, will not prompt the user for a location permission. But this app is requesting `ACCESS_FINE_LOCATION` in its manifest. It could be doing that because they're acknowledging they are using Bluetooth to derive location, but I don't think they are. I suspect what's actually going on is that they're requesting that permission just so they can show your location inside an embedded map view. In which case the permission is not related to its Bluetooth usage.
> I suspect what's actually going on is that they're requesting that permission just so they can show your location inside an embedded map view.
Does the embedded map do some processing in the cloud first? Because the lat/lng is sent over the same API request that includes the battery voltages as well as the BLE address of your handset. I really think none of this is essential to a simple app that reads a battery voltage on your screen.
Of course they neglect to say they will also use the permission to collect your GPS co-ordinates.
Then the AMap location services SDK goes further collects MNC, MCC, LAC and CELL IDs (CGI) and Wifi SSIDs. Here I think the battery app developer does not even know this is happening, they use AMap SDK to obtain the GPS data only. It took me quite some time to figure this out (documented in part 2[1]).
Will also note the manifest has CAMERA, IMAGE_CAPTURE, ACTION_VIDEO_CAPTURE, RECORD_AUDIO and MODIFY_AUDIO_SETTINGS. I have not seen where/how they are used (yet). The code that included strings requesting various permissions (In the AMap SDK code) uses string obfuscation to conceal what it is doing. Likely to trick automated static code analysis tooling.
Note:
> Alibaba state “in 2018, Amap became the first Chinese maps service to navigate a path to 100 million daily users”. [2]
How are Google allowing this SDK to be used in developer's applications?
[1] https://doubleagent.net/2023/05/22/a-car-battery-monitor-tra...
This seems like the problem? And it explains why the app can upload your GPS coordinates directly after querying the Android location APIs.
According to the developer docs, Bluetooth apps should only request ACCESS_FINE_LOCATION "if your app uses Bluetooth scan results to derive physical location". And if they assert that they don't use BT to derive location then the user won't be prompted with a location permission dialogue, just a bluetooth one.
This app isn't deriving location from Bluetooth alone? But I'm guessing it has an embedded map inside that shows your location, and that's why it needs ACCESS_FINE_LOCATION. Meaning it's unrelated to Bluetooth. From reading the docs linked by the GP it seems that for Bluetooth communication only purposes an app shouldn't request that permission.
I wonder how many other apps on the Google Play store do this.
We can't expect the every day user to read and comprehend Google's developer documentation.
You have to wonder how long this app never got taken down. Permissions declared in the manifest do not always equate to them being used.
Google could cross reference the privacy statement that the developer published against the manifest. That would have got it flagged.
The actual code that calls android.content.Context.checkCallingOrSelfPermission() obfuscates the permission strings in many places - bypassing static code analysis checks.
Bluetooth, it to require locations because if you passed by a beacon and an app is registered to the OS to watch it, that that is the same as reporting your location.
Your phone said “hey, app that the user installed, you know that BLE device you told me to watch for? Saw it just now!”
So it’s not it doesn’t make sense. Bluetooth low energy can be used to determine your location so you should have to give it permission.
The problem is… No one knows this.
It’s not even like there’s a solvable problem, because you don’t have to be using the Bluetooth low energy beacon format for this, you just need to be able to scan for advertising BLE devices which the OS does all time. Remember the rush to turn Covid Tracking on (Covid is over, but those changes aren’t going away).
This is how Tile and the Apple Tags that killed them work. Those are just roaming beacons.
Tons of apps that you install for major retailers, Home Depot, Target, Walmart, Best Buy all know exactly when you walk in the store if you have their app on an location services given into it.
Don’t install apps. Not unless you have to. Then questionable permissions aren’t an issue.