Afaik, the way permissions work on Android is that each application is its own user, and each permission is a group. If you have a rooted device, you can simply log in and remove the user from the group to un-grant that permission.
I doubt it will help you though, because it will most likely cause some function somewhere to throw an exception which will in turn cause the app to crash.
I doubt it will help you though, because it will most likely cause some function somewhere to throw an exception which will in turn cause the app to crash.
That's why I blame the Android platform and not just the apps. If Android made it clear from the start that permissions are optional, and that requests for them can be rejected, applications would be written to cope with that. It would also force developers to explain why they need a certain permission.
You're absolutely right. Not having a distinction between required permissions (e.g. a music player is pretty useless without the permission to read the SD card) and optional ones (e.g. a Twitter app can attach your location to your tweets if you want it to, but it doesn't have to) is the biggest problem with Android's permissions system.
Ironically, it is more of a social problem than a technical one. If people were expected to gracefully handle the exceptions thrown when permissions are denied, we'd be 80% of the way there, I think.
I think a lot of app crashes are due to the fact that app developers simply don't know what to expect. This is a direct result of shoddy documentation.
For example, the Android API has a tendency to return null from functions even when the documentation doesn't say it will (i.e. WifiManager.getScanResults and friends), or simply doesn't document return values at all (i.e. ConnectionManager.getActiveNetworkInfo). The Google guys aren't real stars when it comes to documenting what exceptions may be thrown either.
You can't blame app developers for not gracefully handling exceptions and return values that are not documented.
Apparently I was only partly right. Each app is its own user, and certain permissions such as sockets and files are enforced using groups.
However, when the functionality that is being protected is implemented in a system service (which runs in a different process), it's the responsibility of the callee to check the permissions of the caller using Android's own 'permissions validation mechanism'.
I doubt it will help you though, because it will most likely cause some function somewhere to throw an exception which will in turn cause the app to crash.