I have some permissions in my app such as
so, for instance, if I took out two out of three of those commands, all of my A-GPS related calls will still work the exact same way?
Well, two out of those three permissions should not be necessary. ACCESS_MOCK_LOCATION
has nothing to do with GPS, but with your own mock location provider. To quote Cyril Mottier:
Please guys, remove the ACCESS_MOCK_LOCATION permission from your manifest prior publishing your app. Forgetting makes you an amateur.
And normal SDK apps cannot hold CONTROL_LOCATION_UPDATES
-- that is only available to apps signed with the firmware's signing key or installed in the firmware itself.
Hence, a normal SDK app can remove both of those for production, and can remove CONTROL_LOCATION_UPDATES
for development. If you are not using mock location providers in your app, you can remove ACCESS_MOCK_LOCATION
in development too. Most likely, you should have never added those two permissions to your app in the first place.
None of this has anything to do with <uses-feature>
though.
I can use conditionally logic within the app to allow some features to execute.
Absolutely. You can use hasSystemFeature()
on PackageManager
to see if you have android.hardware.location
, before bothering dealing with LocationManager
.
But my main problem is that android.hardware.location covers SO many of the features.
The verb "cover" makes no sense here to me, or to the extent it does, you have the direction reversed. <uses-permission>
elements may imply <uses-feature>
elements, but not the reverse.
if I took out two out of three of those uses-permissions, would all of my A-GPS related calls will still work the exact same way as if I had all of those individual permissions set?
See above.
I have seen android.hardware.location.NETWORK
You may have seen android.hardware.location.network
.
I have seen android.hardware.location.NETWORK
In the documentation for <uses-feature>
: http://developer.android.com/guide/topics/manifest/uses-feature-element.html