Exactly. I do this with XPrivacy for every single application I download: deny access to contacts, Google/Facebook Account, Phone Serial Number, deny access to network if the application doesn't need it.
I've never had an application refuse to run because of it, and I'll never use a phone without XPrivacy again (it's scary what some apps request).
In web development there is this notion of Progressive Enhancement [1]. It basically means that if certain functionality is not available you either disable the features that make use of it or you implement an alternative means of making the functionality work.
I understand that permissions are a little bit different but I believe that a similar approach would work with permissions as well assuming that Android would supply a new advanced permissions sub system. With this, if an app isn't granted a specific permission it can either disable the feature (maybe making clear to the user that this is the case) or implement some other alternative functionality.
E.g. an app hasn't been given the permission to read a user's current geo-location. In that scenario the app could ask the user to manually enter a location (e.g. by selecting a position on a map).
Within the current permissions system you could only doing with mocking, as you stated, which I personally find a bit of a hack and probably very confusion to the user.
That could have negative consequences. Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear.
Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures?
If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life.
Just seems like you're likely to create situations that are confusing/suboptimal for users. Let the app know what's going on. If the app doesn't behave well in that circumstance it should be removed from the store or punished by users with poor reviews.
True, it could have negative consequences. But aren't the negative consequences of the current system even worse?
Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear.
So the phone uses more CPU and battery. It's not that big of a deal.
Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures?
Yes, Android can tell the app that there are no photos.
If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life.
We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?
"Give apps everything" and "lie to apps" is not a binary choice. There is a third option, the one iOS takes. Inform the program they don't have access to that information.
> So the phone uses more CPU and battery. It's not that big of a deal.
Battery life is very important in a phone.
> Yes, Android can tell the app that there are no photos.
It could also tell the app "You have been denied the GPS permission."
> We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?
Really? I'm not. And what if turning off GPS was accidental? I'm used to apps telling me "X won't work because GPS access has been disabled." Just breaking the experience with no way of notifying the user why their run logger stopped logging runs is not acceptable design.
It's not an all-or-nothing choice. You could easily have a 3-way toggle between "Allow - Refuse Permission - Send Mock Permission". By default you refuse any permissions you don't want the app to have. If it starts behaving badly, you send the mock permission.
Plus, as others have said, there's nothing wrong with giving users the option.
(I.e. stub the api, have it return mock data.)