Sounds like what you need is a "prompt" option for permissions. Give permissions 3 states: allowed, denied, and prompt.
The way I would implement this is to continue specifying permissions in the manifest, but to add a DEFAULT PROMPT STATE option to the uses- permission tag. Upon install, the FULL list of permissions should be shown along with the DEFAULT states. A request for a "full" permission should give the user the option to set it to ALLOWED, DENIED, and PROMPT. A request for a "prompt" permission should give the user the option to set it to DENIED and PROMPT (but not ALLOWED). Permissions not requested should not be shown (as is already the case). Similarly, it should be possible to adjust these permissions when you go in to Settings --> Applications --> Manage Applications. It would also be nice if there was a VISIBLE CLUE provided when the application attempts to use a permission that it does not have. Not a prompt for permission, but a LOG of permission denials. This log should go along with crash reports to the developer's market console -- this would take care of the application developer who failed to consider the possibility of permission denial -- so they can see crashes, associate them with permission denials, and update their code with a try/catch around code that may fail due to permission denial. This was one of the big issues that freaked out GOOGLE regarding permission overrides -- that if an application crashed due to denied permission, it might be blamed on the platform when it is actually a defect in the application. Also, back to Tim's idea of providing fake data... that would definitely help reduce the possibility of crashes based on permission denial. Some other things it won't help with, like receiving invalid data from a web service, but that kind of thing really should be anticipated by the developer and should NOT crash the application since invalid data is always a possibility when dealing with the web. On Jun 25, 3:15 pm, Brad Gies <[email protected]> wrote: > Not to disagree too much with Mark, but here is one scenario (that I > have a need for) : > > My app uses user groups extensively, and when a user first installs my > app, I would have liked to be able to ask them is they want to check to > see if any of their friends are already registered on my site. To do > that, I would read their contacts (once only) and return a list of the > groups their friends are in to see if they also want to join that group. > > I decided to scrap doing that because I didn't want my app to have to > have the READ_CONTACTS permission whether the user uses it or not, and > when they only use it once if they do use it. > > AND I can think of many other times I've run into the same issue. I > really believe this should be added to all Android permissions... even > if it's just a Grant Once type of option, and then hope that developers > don't overuse it :). > > On 25/06/2010 12:03 PM, Mark Murphy wrote: > > > > > On Fri, Jun 25, 2010 at 2:47 PM, Peter Eastman<[email protected]> > > wrote: > > >> I'd like to see more permissions handled implicitly through user > >> actions at runtime. > > > For some fraction of permissions, this makes sense. The fraction is > > very very small. > > >> For > >> example, it's fine for a program to send an SMS message as long as > >> it's done through a standard UI that displays the message and requires > >> the user to click the "Send" button. That shouldn't require any > >> special permissions, and it also should be enough to meet the needs of > >> most programs. Permission would only be required to send SMS without > >> using the standard UI, and that would be an uncommon thing to ask > >> for. That way, it would actually get people's attention if a program > >> asked for that permission. > > > This is already implemented. It is also implemented for placing phone calls. > > > What the core Android team is trying to avoid is a Vista-like > > experience ("the CPU would like to execute an instruction -- allow or > > deny?"). > > >> No security model can stop all malware, and I think Android does a lot > >> better than most OS's, but there's room for improvement. Having a > >> program ask you for special permissions should be the exception, not > >> the rule. > > > Assuming the SMobile Systems survey is accurate, here are the top 5 > > permissions requested: > > > INTERNET > > ACCESS_COARSE_LOCATION > > WRITE_EXTERNAL_STORAGE > > ACCESS_FINE_LOCATION > > READ_CONTACTS > > > None of these have an obvious "user action" that fits your proposed model, > > IMHO. > > > There are certainly ways to improve the user's ability to grok and > > appreciate the permissions screen. However, it is unrealistic to > > expect that applications will just stop requesting permissions. > > -- > Sincerely, > > Brad Gies > ----------------------------------------------------------------------- > Bistro Bot - Bistro > Blurbhttp://www.bgies.comhttp://www.bistroblurb.comhttp://www.ihottonight.com > ----------------------------------------------------------------------- > > Never doubt that a small group of thoughtful, committed people can > change the world. Indeed. It is the only thing that ever has - Margaret Mead -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
