AndroidManifest.xml implied vs explicit permission

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?

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.