Required Manifest Permissions For GPS Operation?
1,647 views
Skip to first unread message
Away Team
Nov 13, 2014, 11:19:32 AM11/13/14
to gpstest...@googlegroups.com
I recently came across your open source GPSTest app, which I have been analysing. I understand that this is a reference for Android GPS users and developers, and wondered whether you could advise on some questions regarding required permissions in the Manifest file for GPS operation.
I'm currently porting an existing Java ME app to Android and am trying to understand which Manifest permissions are necessary, and which are not, from a GPS standpoint. I should stress that our app does not use the Maps API, and I'm therefore keen to avoid including any such irrelevant permissions, c.f. GPSTest Manifest excerpt below.
Our app uses GPS only (i.e. just LocationManager.GPS_PROVIDER, not LocationManager.NETWORK_PROVIDER) to calculate the user's location, so android.permission.ACCESS_FINE_LOCATION seems essential and this is confirmed by the comments in LocationManager.java. However, I'd also like to take advantage of Assisted GPS (A-GPS), if it's available to the device, and don't want to omit permissions which would preclude this. Sadly, I have been unable to find any documentation describing A-GPS operation on Android.
1. The 'assistance' information for A-GPS can include an approximate user location, such as the current cell id, which may require android.permission.ACCESS_COARSE_LOCATION. Can you confirm my understanding, and whether this permission is required or not? I have been unable to find any documentation which clarifies this.
2. The 'assistance' information may also be transmitted via a network, either Wifi or Mobile Data, which may require android.permission.INTERNET or other permissions. Again, can you confirm my understanding, and whether such permissions are required or not?
3. I notice that GPSTest v2.1.3 includes both android.permission.ACCESS_FINE_LOCATION and android.permission.ACCESS_COARSE_LOCATION. Why is this necessary? Does FINE permission not also include COARSE permission? Or it presented in this way to clarify the permissions required for the Maps API? Please explain.
4. Does android.permission.ACCESS_LOCATION_EXTRA_COMMANDS implicitly allow A-GPS, in addition to accessing the Location.setExtras/getExtras interface? This seems unlikely, but worth confirming.
To date, I have been unable to verify (or control) whether our Android app is using A-GPS or not, making it impossible for me to test this empirically. That said, the time to first fix varies from a few seconds to many minutes, even long after the previous ephemeris data should have expired, which is puzzling. The demarkation on Java ME is far clearer and more controllable, as the 'assisted' GPRS (not GPS) data call is shown on Nokia phones when A-GPS is used. Any advice you could offer would be very welcome, and I look forward to hearing from you soon.
Rob Smith
Away Team Software Ltd
GPSTest (v2.1.3) Manifest permissions excerpt follows:
I'm currently porting an existing Java ME app to Android and am trying to understand which Manifest permissions are necessary, and which are not, from a GPS standpoint. I should stress that our app does not use the Maps API, and I'm therefore keen to avoid including any such irrelevant permissions, c.f. GPSTest Manifest excerpt below.
Our app uses GPS only (i.e. just LocationManager.GPS_PROVIDER, not LocationManager.NETWORK_PROVIDER) to calculate the user's location, so android.permission.ACCESS_FINE_LOCATION seems essential and this is confirmed by the comments in LocationManager.java. However, I'd also like to take advantage of Assisted GPS (A-GPS), if it's available to the device, and don't want to omit permissions which would preclude this. Sadly, I have been unable to find any documentation describing A-GPS operation on Android.
1. The 'assistance' information for A-GPS can include an approximate user location, such as the current cell id, which may require android.permission.ACCESS_COARSE_LOCATION. Can you confirm my understanding, and whether this permission is required or not? I have been unable to find any documentation which clarifies this.
2. The 'assistance' information may also be transmitted via a network, either Wifi or Mobile Data, which may require android.permission.INTERNET or other permissions. Again, can you confirm my understanding, and whether such permissions are required or not?
3. I notice that GPSTest v2.1.3 includes both android.permission.ACCESS_FINE_LOCATION and android.permission.ACCESS_COARSE_LOCATION. Why is this necessary? Does FINE permission not also include COARSE permission? Or it presented in this way to clarify the permissions required for the Maps API? Please explain.
4. Does android.permission.ACCESS_LOCATION_EXTRA_COMMANDS implicitly allow A-GPS, in addition to accessing the Location.setExtras/getExtras interface? This seems unlikely, but worth confirming.
To date, I have been unable to verify (or control) whether our Android app is using A-GPS or not, making it impossible for me to test this empirically. That said, the time to first fix varies from a few seconds to many minutes, even long after the previous ephemeris data should have expired, which is puzzling. The demarkation on Java ME is far clearer and more controllable, as the 'assisted' GPRS (not GPS) data call is shown on Nokia phones when A-GPS is used. Any advice you could offer would be very welcome, and I look forward to hearing from you soon.
Rob Smith
Away Team Software Ltd
GPSTest (v2.1.3) Manifest permissions excerpt follows:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS"/>
<uses-permission android:name="android.permission.INTERNET"/>
<!-- Android Maps API V2 -->
<permission
android:name="com.android.gpstest.permission.MAPS_RECEIVE"
android:protectionLevel="signature"/>
<uses-permission android:name="com.android.gpstest.permission.MAPS_RECEIVE"/>
<uses-permission android:name="com.google.android.providers.gsf.permission.READ_GSERVICES"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<!-- The following permission is not required to use
Google Maps Android API v2, but is recommended. -->
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
Sean Barbeau
Nov 14, 2014, 12:18:40 AM11/14/14
to Away Team, gpstest...@googlegroups.com
Whoops, I accidentally dropped the list from my response - resending to all:
Sure, I'd be happy to share what I know based on my experience. I originally came from the Java ME location world as well, and I know that the transition is a bit strange due to all the differences between the two platforms.
Our app uses GPS only (i.e. just LocationManager.GPS_PROVIDER, not LocationManager.NETWORK_PROVIDER) to calculate the user's location, so android.permission.ACCESS_FINE_LOCATION seems essential and this is confirmed by the comments in LocationManager.java. However, I'd also like to take advantage of Assisted GPS (A-GPS), if it's available to the device, and don't want to omit permissions which would preclude this. Sadly, I have been unable to find any documentation describing A-GPS operation on Android.
Short answer: You should be fine with just the "android.permission.ACCESS_FINE_LOCATION" permission, as specified here - http://developer.android.com/reference/android/location/LocationManager.html#GPS_PROVIDERLong answer: A-GPS works a bit differently on Android than Java ME. To my knowledge, Android devices still use gpsOneXTRA (https://www.qualcomm.com/news/releases/2007/02/12/qualcomm-introduces-gpsonextra-assistance-expand-capabilities-standalone), or something similar, for A-GPS. The platform handles the periodic fetching of predictive ephemeris and almanac data from a remote server, usually around every 48hrs, although its technically good for up to 7 days. This differs from Java ME, since these phones were tightly integrated with the cell network via communication with a PDE, and required frequent updating of live ephemeris data. Slide 10 of this presentation starts with some of the differences between traditional A-GPS seen on Java ME and the assisted GPS seen on Android devices (and slide 13 starts with gpsOneXTRA):This should all be handled by the platform by default, so you shouldn't need to mess with the assistance data manually yourself. So, when you see "GPS" in the context of Android, it really means the type of assisted GPS defined by gpsOneXTRA. Unless your device has been out of network coverage for a long time (over a week), the GPS fix you get in your app from the GPS_PROVIDER will essentially be a type of assisted fix.(a historical aside, which you're probably aware of - carriers have always been very protective of allowing developers access to the JSR179 Location API and A-GPS because of the communication required with their PDE, and fear of overloading it or the network with requests. gpsOneXTRA was created largely to fit with the Android open API model, since it avoids the carrier integration and just goes over HTTP to a web server.)
1. The 'assistance' information for A-GPS can include an approximate user location, such as the current cell id, which may require android.permission.ACCESS_COARSE_LOCATION. Can you confirm my understanding, and whether this permission is required or not? I have been unable to find any documentation which clarifies this.
Assuming my info from a few years ago is still good, as mentioned above, Android doesn't use traditional A-GPS, but instead gpsOneXTRA. As a result, you shouldn't need the ACCESS_COARSE_LOCATION permission, unless you're using the NETWORK_PROVIDER.
2. The 'assistance' information may also be transmitted via a network, either Wifi or Mobile Data, which may require android.permission.INTERNET or other permissions. Again, can you confirm my understanding, and whether such permissions are required or not?
Your app isn't actually the one doing the communication with the assistance server (instead, the platform is doing it), so you shouldn't need android.permission.INTERNET.
3. I notice that GPSTest v2.1.3 includes both android.permission.ACCESS_FINE_LOCATION and android.permission.ACCESS_COARSE_LOCATION. Why is this necessary? Does FINE permission not also include COARSE permission? Or it presented in this way to clarify the permissions required for the Maps API? Please explain.
In GPSTest, I included android.permission.ACCESS_COARSE_LOCATION since it was recommended for the Maps API v2. You shouldn't need this for the GPS_PROVIDER.
4. Does android.permission.ACCESS_LOCATION_EXTRA_COMMANDS implicitly allow A-GPS, in addition to accessing the Location.setExtras/getExtras interface? This seems unlikely, but worth confirming.
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS is required to use the method LocationManager.sendExtraCommand():http://developer.android.com/reference/android/location/LocationManager.html#sendExtraCommand(java.lang.String, java.lang.String, android.os.Bundle)You can see this in action in GPSTest here:This is the only control your app has over the assistance data - you can do the following:
- Inject Time Data - Injects Time assistance data for GPS into the platform, using the Network Time Protocol (NTP) server defined in system file system/etc/gps.conf. Command input for method is "force_time_injection"
- Inject XTRA Data - Injects XTRA assistance data for GPS into the platform, using the gpsOneXTRA server defined in system file system/etc/gps.conf (e.g., http://xtra3.gpsonextra.net/xtra.bin). Command input for method is "force_xtra_injection"
- Clear Assist Data - Clears all aiding data used for GPS. Command input for method is "delete_aiding_data"
If the LocationManager.sendExtraCommand() method returns true for any of these commands, then it means that they have succeeded (although, I know of at least one phone in the past that did not take any action for these commands, but still returned "true".I wouldn't suggest using these commands this in your app unless your app has failed to get a GPS fix over an extended amount of time, and you can confirm that you have an internet connection, since unexpected things could happen. That being said, I know that a large number of users primarily use GPSTest for the "clear" and two "inject" commands to reset their GPS when they can't get a fix.
To date, I have been unable to verify (or control) whether our Android app is using A-GPS or not, making it impossible for me to test this empirically. That said, the time to first fix varies from a few seconds to many minutes, even long after the previous ephemeris data should have expired, which is puzzling. The demarkation on Java ME is far clearer and more controllable, as the 'assisted' GPRS (not GPS) data call is shown on Nokia phones when A-GPS is used. Any advice you could offer would be very welcome, and I look forward to hearing from you soon.
Hopefully the above text explaining the difference between the A-GPS used in Java ME phones and gpsOneXTRA helps. If you can't get a fix and you think you should have already gotten one, you can try injecting the time and XTRA data (either via your app, or GPSTest - the assistance data is global for all apps). The only way I've truly confirmed that these commands were doing something was to hook the phone up to Logcat and search for terms like ntp, xtra, or a known URL for XTRA data such as http://xtra3.gpsonextra.net/xtra.bin. If you see these pop up in the log just after injecting the data, then you know you have fresh predictive time/ephemeris data.Hopefully this helps! I've also always felt that Android was a bit lacking in all these details, especially coming from Java ME originally myself. Feel free to ask any additional questions if I didn't cover something.Sean
Away Team
Nov 14, 2014, 7:54:45 AM11/14/14
to gpstest...@googlegroups.com, awayteam...@gmail.com
Sean,
Many thanks for your swift and detailed response. I think that clarifies the situation a lot.
From what you say, I believe that the platform (i.e. Android) has authority and is responsible for maintaining the 'assistance' information for A-GPS, hence the app itself does not need explicit permissions. I can understand this for calculating the user's location, as the app has a passive role. However, it raises a question over permissions for actively using LocationManager.sendExtraCommands.
1. Am I right in thinking that android.permission.ACCESS_LOCATION_EXTRA_COMMANDS is only permission to request the result, rather than to necessarily achieve it? For example, if there is a web connection, sendExtraCommands can successfully complete a 'force_xtra_injection' request via http and return true. Conversely, if there is no web connection, sendExtraCommands returns false and makes no attempt to enable web access. Assuming I've understood correctly so far, how can we discriminate between failure because the command is not supported by the device and failure because a required underlying feature is disabled, e.g. no web connection?
2. Usage of android.permission.ACCESS_LOCATION_EXTRA_COMMANDS seems very poorly documented. Google's documentation of the LocationManager (http://developer.android.com/reference/android/location/LocationManager.html) fails to mention it at all, despite its necessity for using LocationManager.sendExtraCommands without (presumably) raising a security exception.
3. Thanks for the additional details on the 3 extra commands: force_time_injection, force_xtra_injection and delete_aiding_data. I had identified these during my analysis of GPSTest, but where are they documented - officially or otherwise? And are there any other such commands available, e.g. force_supl_injection?
I look forward to hearing from you.
Many thanks for your swift and detailed response. I think that clarifies the situation a lot.
From what you say, I believe that the platform (i.e. Android) has authority and is responsible for maintaining the 'assistance' information for A-GPS, hence the app itself does not need explicit permissions. I can understand this for calculating the user's location, as the app has a passive role. However, it raises a question over permissions for actively using LocationManager.sendExtraCommands.
1. Am I right in thinking that android.permission.ACCESS_LOCATION_EXTRA_COMMANDS is only permission to request the result, rather than to necessarily achieve it? For example, if there is a web connection, sendExtraCommands can successfully complete a 'force_xtra_injection' request via http and return true. Conversely, if there is no web connection, sendExtraCommands returns false and makes no attempt to enable web access. Assuming I've understood correctly so far, how can we discriminate between failure because the command is not supported by the device and failure because a required underlying feature is disabled, e.g. no web connection?
2. Usage of android.permission.ACCESS_LOCATION_EXTRA_COMMANDS seems very poorly documented. Google's documentation of the LocationManager (http://developer.android.com/reference/android/location/LocationManager.html) fails to mention it at all, despite its necessity for using LocationManager.sendExtraCommands without (presumably) raising a security exception.
3. Thanks for the additional details on the 3 extra commands: force_time_injection, force_xtra_injection and delete_aiding_data. I had identified these during my analysis of GPSTest, but where are they documented - officially or otherwise? And are there any other such commands available, e.g. force_supl_injection?
I look forward to hearing from you.
Rob Smith
Away Team Software Ltd
Reply all
Reply to author
Forward
0 new messages