[oshepherd]

So I have an application which can attach location information to posts made from it. It requests access to location data (as is necessary) when installed, then lets you turn that feature on or off from an internal setting.

The request for location data implies the usage of the location feature, so the Android package manager won't let you install it on devices without a coarse location provider.

Therefore, like most Android apps which lookup location information, it just assumed that it could do location lookups. No point testing for a feature which will always be present, right?

Now guess what would happen if you used AppOps to turn location off? That's right, it would crash.

Not exactly acceptable user experience.

Now, what Google should do is probably: * For apps targetting Android 4.5+, certain features with privacy implications will default to OPTIONAL rather than REQUIRED when implied by a permission request. * AppOps is then able to toggle access to features which are declared optional, which apps must handle the absence of anyway.

[fooqux]

Any programmer worth their salt should, whenever doing any sort of IO (regardless of hardware, cloud, or otherwise) should be making sure they get a sane result/object back. Purely anecdotal here, but I run XPrivacy and have the vast majority of my apps blocked from location. You'd think my phone would barely work, but it actually works fine. I don't think I've ever had an application crash from lack of GPS.

Part of why they don't crash is the multi-threaded nature of how the location API works in Android. High level: you basically of instantiate the location object at the start of your thread, and give it a call back function to call once it has a location for you. You don't know when/if you will ever get a callback, so you have to put some checks in.