3 ms·

I think there is a middle ground. Certainly, there are going to be some permissions an app can't function without (e.g. you can't have a phone dialer work that

I think there is a middle ground. Certainly, there are going to be some permissions an app can't function without (e.g. you can't have a phone dialer work that doesn't have access to the phone). On the other hand, there are permissions that are purely optional to an application (such as the afore-mentioned SMS). It would be better to specify "required permissions" and "enhanced feature permissions". I require the phone permission to run. I can use the SMS feature to make your experience better.

drivebyacct2 16y ago
I'm not saying it is a bad idea. I really like it in fact. I really don't think it will work as smoothly as (apparently everyone) seems to think. Android wasn't built to have this feature... and I'm not sure that even this middle ground could be done in a way that doesn't break many existing applications.
- wzdd 16y ago
  I don't think it would work either. Take an app that needs, say, wake locks, Internet access, and SMS access. Say further than none of them is strictly required. Now imagine that users can deny this access on a per-permission basis. Now instead of having one app to test, you have 2 ^ 3. It's not as easy as using existing error codes, because some of these things normally don't break -- in which case it would be excusable to have fairly basic error handling. Displaying a message and allowing the user to restart the app is a fair distance (in terms of app complexity) from being required to produce an app that not only keeps running but does "the right thing" for all possible degradations of required permissions. EDIT: I don't meant to sound pessimistic. I do really like the idea, but it seems like it would make the dev / test cycle a lot longer.
  - SoftwareMaven 16y ago
    I agree it would take longer. I disagree that it would be 2^3 times longer (I don't actually believe you meant that, but it could be inferred from your comment). The app would have to be written such that "is feature X available", not "is permission X available." Then, if I don't actually have all of the permissions I need for feature X, the whole feature isn't available, rather than trying to code for each permission. It is really no different than having a web app continue to work as JavaScript capabilities degrade from "Chrome" to "IE 6" to "NoScript".
- SoftwareMaven 16y ago
  I disagree. Apps already need to be able to handle some of these situations (as some parent post mentioned), but you don't even have to alter any existing app as all existing permissions requests default to "required". I don't buy the argument that "it would make testing the app too difficult." It just isn't that hard to put feature-placed guards in place. Web apps do that all the time today for JavaScript capabilities and they survive just fine. I have a lot of apps on my iPhone that I don't give location permissions to that continue to work fine as well. I don't know the details of the underlying OS change, but I would imagine it isn't that large of a change, either (if any change at all). The system has to have the ability to check if an app has permission to perform an operation today so people can't lie about the permissions they are using. It would just do the same thing it does today. So we are down to adding a flag to the permissions requested (required versus requested), adding a description field to the flag, and altering the presentation of the permissions at install time.
  - drivebyacct2 16y ago
    Why am I bothering replying if no one will take the time of day to explain why they're crucifying all of my comments here when I'm voicing a completely legitimate claim about denying apps that have been guaranteed permissions access to those features... I never said it would make testing the app hard. I never said it would be hard to change Android permission model to accomodate for deniable permissions when they are needed. I'm saying that it would break every application in existence that is expected to have guaranteed access to whatever permissions they've declared in their manifest. Android apps aren't written to handle AT ALL cases where they simply aren't given permission to do whatever, and they would surely crash as a result. I've never been more disappointed in how comments were voted on than I am on this thread. --- edit: If you're implying that NEW apps could mark permissions as OPTIONAL and then manually request them and handle being granted them or not in code..., then I'm 100% in support. I think it's a BRILLIANT idea and I have no idea why it's not being worked on. edit2: Surely I'm not out of line for assuming that "just return an error code and act like it's broken" was supposed to mean that users could deny permissions to existing/legacy apps that had declared the permissions in their manifest. If we've been talking this entire time about a new schema for new optional permissions in NEW applications, while still preserving legacy required permissions... well, I sure wish someone would have had the decency to point that out instead of just downvoting. edit3: I'm almost positive he editted that comment to add that last paragraph. Or else I'm an idiot and missed it. Either way, I apparently misunderstood what he was talking about, unless that's what we've been discussing this entire time. Either way, I don't know why it didn't occur to me.

drivebyacct2 16y ago

I'm not saying it is a bad idea. I really like it in fact. I really don't think it will work as smoothly as (apparently everyone) seems to think. Android wasn't built to have this feature... and I'm not sure that even this middle ground could be done in a way that doesn't break many existing applications.

wzdd 16y ago
I don't think it would work either. Take an app that needs, say, wake locks, Internet access, and SMS access. Say further than none of them is strictly required. Now imagine that users can deny this access on a per-permission basis. Now instead of having one app to test, you have 2 ^ 3. It's not as easy as using existing error codes, because some of these things normally don't break -- in which case it would be excusable to have fairly basic error handling. Displaying a message and allowing the user to restart the app is a fair distance (in terms of app complexity) from being required to produce an app that not only keeps running but does "the right thing" for all possible degradations of required permissions. EDIT: I don't meant to sound pessimistic. I do really like the idea, but it seems like it would make the dev / test cycle a lot longer.
- SoftwareMaven 16y ago
  I agree it would take longer. I disagree that it would be 2^3 times longer (I don't actually believe you meant that, but it could be inferred from your comment). The app would have to be written such that "is feature X available", not "is permission X available." Then, if I don't actually have all of the permissions I need for feature X, the whole feature isn't available, rather than trying to code for each permission. It is really no different than having a web app continue to work as JavaScript capabilities degrade from "Chrome" to "IE 6" to "NoScript".
SoftwareMaven 16y ago
I disagree. Apps already need to be able to handle some of these situations (as some parent post mentioned), but you don't even have to alter any existing app as all existing permissions requests default to "required". I don't buy the argument that "it would make testing the app too difficult." It just isn't that hard to put feature-placed guards in place. Web apps do that all the time today for JavaScript capabilities and they survive just fine. I have a lot of apps on my iPhone that I don't give location permissions to that continue to work fine as well. I don't know the details of the underlying OS change, but I would imagine it isn't that large of a change, either (if any change at all). The system has to have the ability to check if an app has permission to perform an operation today so people can't lie about the permissions they are using. It would just do the same thing it does today. So we are down to adding a flag to the permissions requested (required versus requested), adding a description field to the flag, and altering the presentation of the permissions at install time.
- drivebyacct2 16y ago
  Why am I bothering replying if no one will take the time of day to explain why they're crucifying all of my comments here when I'm voicing a completely legitimate claim about denying apps that have been guaranteed permissions access to those features... I never said it would make testing the app hard. I never said it would be hard to change Android permission model to accomodate for deniable permissions when they are needed. I'm saying that it would break every application in existence that is expected to have guaranteed access to whatever permissions they've declared in their manifest. Android apps aren't written to handle AT ALL cases where they simply aren't given permission to do whatever, and they would surely crash as a result. I've never been more disappointed in how comments were voted on than I am on this thread. --- edit: If you're implying that NEW apps could mark permissions as OPTIONAL and then manually request them and handle being granted them or not in code..., then I'm 100% in support. I think it's a BRILLIANT idea and I have no idea why it's not being worked on. edit2: Surely I'm not out of line for assuming that "just return an error code and act like it's broken" was supposed to mean that users could deny permissions to existing/legacy apps that had declared the permissions in their manifest. If we've been talking this entire time about a new schema for new optional permissions in NEW applications, while still preserving legacy required permissions... well, I sure wish someone would have had the decency to point that out instead of just downvoting. edit3: I'm almost positive he editted that comment to add that last paragraph. Or else I'm an idiot and missed it. Either way, I apparently misunderstood what he was talking about, unless that's what we've been discussing this entire time. Either way, I don't know why it didn't occur to me.