I have some permissions in my app such as
<uses-permission android:name="android.permission.CONTROL_LOCATION_UPDATES" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
and I am under the suspicion that they aren't actually necessary.
According to the Android documents, they all imply that
<uses-feature
android:name="android.hardware.location"/>
is true and required.
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?
There doesn't really seem to be much literature about this, except for people repeating the android documents.
Ultimately, I think that implying that android:required = true for so many elements of the code is limiting the amount of devices I can access.
<uses-feature
android:name="android.hardware.location" android:required="false"/>
will open up to the app to many more devices, and I can use conditionally logic within the app to allow some features to execute.
But my main problem is that android.hardware.location
covers SO many of the <uses-permission/>
features. There is no android.hardware.location.ACCESS_MOCK_LOCATION
or android.hardware.location.CONTROL_LOCATION_UPDATES
, only android.hardware.location
a couple assumptions here, but the android developer documents really don't elaborate, except reveal that those separate uses-permissions
imply that one single uses-feature
is required. when it necessarily is not intended to be required and I just want to make sure my android sdk calls have permission to run
questions:
1) 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?
2) does android.hardware.location
get more specific? I have seen android.hardware.location.NETWORK
but where can I see what all of the possibilities are?
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: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 removeACCESS_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.Absolutely. You can use
hasSystemFeature()
onPackageManager
to see if you haveandroid.hardware.location
, before bothering dealing withLocationManager
.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.See above.
You may have seen
android.hardware.location.network
.In the documentation for
<uses-feature>
: http://developer.android.com/guide/topics/manifest/uses-feature-element.html