Hacker News Reader

Comment by Larrikin | Hacker News Reader

This is no longer the case https://developer.android.com/guide/topics/connectivity/blue... There is actually a lot more review in the Play Store now as well, they will kick you out the store if they detect you're lying about the permission.

View on HN

> They will kick you out the store if they detect you're lying about the permission

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.

It seems like permissions should be part of the app manifest and there should be no way to lie about it.

The manifest has ACCESS_FINE_LOCATION. When you run the application, the developer actually displays a popup saying to grant the permission so it can do BLE scanning to connect to the hardware device.

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...

[2] https://www.alibabacloud.com/customers/autonavi

> The manifest has ACCESS_FINE_LOCATION.

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.

Thanks for this: I've updated the post with a note on 'if your app uses Bluetooth scan results to derive physical location'. I highly doubt this is why they use ACCESS_FINE_LOCATION for this purpose. Rather it's an opportunistic way to get users to accept the permission - they tell users to accept it to get Bluetooth working when the app is first installed.

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.

It always has been part of the manifest (Bluetooth permissions before, location permissions these days). However, even with the permission in the manifest, modern Android release don't just grant that permission on install; you need to ask the user for permission, and then ask them again for things like background permissions, and then display a continuous notification if your app is running in the background.

To determine if they are lying or not is logistically impossible, even for Google.

Reply on news.ycombinator.com