Android Question File references and Bluetooth ocation

[RJB]

Acouple of things came up whilst trying to remove ''dangerous' permissions from an app:

1. the following three versions all work:

 If File.Exists(Filepath, Filename) Then Log("OK")
 If File.Exists(FilepathandFilename, "") Then Log("OK")
 If File.Exists("", FilepathandFilename) Then Log("OK")

so is it OK to assume that any variant can always be used for any type of file reference, file.delete, file.copy, etc. etc.? This would avoid having to split a path/name if it is already combined.

2. BluetoothAdmin adds android.permission.ACCESSCOARSE_LOCATION to the permissions. Why is this, why is it a 'dangerous' permission and can it be avoided?

Thanks

 

[Peter Simpson]

I personally always use fill paths.

If File.Exists(Filepath, Filename) Then Log("OK")

You will find a lot of the time you will need either fine or course (I always use fine) when accessing things like WiFi, Bluetooth etc, they can't be avoided, from SDK 23 and higher google implemented RTP (RunTimePermissions), and from next year Google are basically forcing developers to set their manifest Target SDK to 26, so there's definitely no way to avoid this, well not for the play store anyway...

ACCESS_COARSE_LOCATION
String ACCESS_COARSE_LOCATION
Allows an app to access approximate location. Alternatively, you might want ACCESS_FINE_LOCATION.
Protection level: dangerous
Constant Value: "android.permission.ACCESS_COARSE_LOCATION"

ACCESS_FINE_LOCATION
String ACCESS_FINE_LOCATION
Allows an app to access precise location. Alternatively, you might want ACCESS_COARSE_LOCATION.
Protection level: dangerous
Constant Value: "android.permission.ACCESS_FINE_LOCATION"

 

[RJB]

I personally always use fill paths.

If File.Exists(Filepath, Filename) Then Log("OK")

You will find a lot of the time you will need either fine or course (I always use fine) when accessing things like WiFi, Bluetooth etc, they can't be avoided, from SDK 23 and higher google implemented RTP (RunTimePermissions), and from next year Google are basically forcing developers to set their manifest Target SDK to 26, so there's definitely no way to avoid this, well not for the play store anyway...

ACCESS_COARSE_LOCATION
String ACCESS_COARSE_LOCATION
Allows an app to access approximate location. Alternatively, you might want ACCESS_FINE_LOCATION.
Protection level: dangerous
Constant Value: "android.permission.ACCESS_COARSE_LOCATION"

ACCESS_FINE_LOCATION
String ACCESS_FINE_LOCATION
Allows an app to access precise location. Alternatively, you might want ACCESS_COARSE_LOCATION.
Protection level: dangerous
Constant Value: "android.permission.ACCESS_FINE_LOCATION"

re. paths: yes, that's how it's documented and how I would usually use it but sometimes you have the complete path/name so would have to split it. If the other variants are safe then it saves a step.

re. Coarse location. What I'm really asking is "why does BluetoothAdmin add a 'dangerous' permission at all? And is there any way to use Bluetooth without adding it?" I know we are going to be forced to set the manifest target, hence the question. I don't want unnecessary permissions!

 

[Peter Simpson]

The way that I understand it @RJB is as follows.
If you can read MAC addresses of WiFi or Bluetooth transmitters then in theory you can locate any device. This is how WiFi/Bluetooth location works, you listen for the MAC addresses of transmitters there you have it. This means that any application using Bluetooth and a data connection is theoretically capable of locating your device and sending out the information to unscrupulous developers, so it's classed as dangerous thus needs permission as it could in theory be a security risk to the end user.

 

[RJB]

The way that I understand it @RJB is as follows.
If you can read MAC addresses of WiFi or Bluetooth transmitters then in theory you can locate any device. This is how WiFi/Bluetooth location works, you listen for the MAC addresses of transmitters there you have it. This means that any application using Bluetooth and a data connection is theoretically capable of locating your device and sending out the information to unscrupulous developers, so it's classed as dangerous thus needs permission as it could in theory be a security risk to the end user.

OK thanks.
Regarding RunTimePermissions (which I haven't used yet) that implies, if the target is set above SDK 22 then
a) the App will be allowed to be installed and run as long as it doesn't use try to use Bluetooth (and GPS, etc. ?), even though it might have the capability to do so,
b) if it doesn't ask permission then it is prevented somehow from using Bluetooth/ GPS (whether installed from the playstore or not?),
c) likewise BT/ GPS won't work if permission is asked but denied.
Do you know if those three statements are correct?

Also, presumably, a device running Android of less than SDK 23 installed from the playstore will continue to ask permission at installation and will not be installed if denied? Whereas it will not ask and will be installed and will run if not installed from the playstore?

Thanks

 

[Peter Simpson]

A. Yes, but as Google will be forcing developers to Target SDK >= 26 by late next year (for the play store), you might as well just implement RTP now. It only takes 1 line of code in the manifest and 3 lines of code in your activity.

B. Play store yes, out of play store like a private client then no.

C. That is correct, the same as writing to external storage.

 

[RJB]

OK thanks very much.
I am updating for RTP and have only the Bluetooth/ GPS left to handle. Well actually the Bluetooth is only used for external GPS receivers so just need to handle the one scenario.
Thanks again