This flaw in their design is caused by a flaw in Google's design for distribution of apps.
There is no reasonable way, that does not impose an unacceptable burden on users, to distribute an app that makes use of third party functionality like this that should live in its own .apk. And even if there were -- it does not solve the problem -- it just associates it with the third-party app. And that's bad, actually. It gives the user the option of not including that app, which makes things MORE complex for the user, and opens up the possibility of leading to broken situations. It also introduces the equivalent of DLL hell. Please tell me you don't want to go there! I don't have a solution, mind you. I really do think that optional permissions, which are requested IN THE CONTEXT OF THE NEED are very much the way to go. They are simpler for users to understand. This is how Apple does it, and while it does have its drawbacks, it is far less mysterious. Still, the focus on the user experience, and the search for ways to structure things in safe ways that don't require sledgehammer permissions, is very much a worthwhile effort. But the current situation is not where we want to be! On Aug 29, 12:11 pm, Dianne Hackborn <hack...@android.com> wrote: > On Sun, Aug 29, 2010 at 5:31 AM, Zsolt Vasvari <zvasv...@gmail.com> wrote: > > On a somewhat related note, I decided I would try to integrate the > > Bump functionality into my app -- some users asked for ways to > > exchange transactions between phones in the family, and this seemed > > pretty good. > > > But then I opened the docs and here it what it says: > > > Add > > > <uses-permission > > android:name="android.permission.ACCESS_FINE_LOCATION" /> > > <uses-permission > > android:name="android.permission.ACCESS_COARSE_LOCATION" /> > > <uses-permission android:name="android.permission.INTERNET" /> > > <uses-permission android:name="android.permission.VIBRATE" /> > > <uses-permission android:name="android.permission.READ_PHONE_STATE" /> > > > No freaking way I will pollute my permission requirements with that > > stuff. If I saw a personal fianance app ask for those permissions, > > I'd hit cancel so fast, it wouldn't know what happened. > > > I don't know what the solution is, but this is just wrong. > > This is a flaw in their design (and in the design of current ad servers as > well). By having you link their code into your app, you are required to > take responsibility for their permissions. Yet it is their code, you don't > have control over it, so why should you? > > A solution is for the other party's code to be in its own .apk, which your > app uses if it is there. (And you can prompt the user, sending them to > market, to make this functionality available.) This way the permissions are > clearly separated between apps, and the user can associate them with the > responsible parties and decide who they want to trust. > > That said, there is an implicit responsibility of the app delivering > functionality to other apps this way to not leak the permissions it is > using. (As there is for every app.) An extreme example would be an app > that use permission for GPS, and a service that lets others get the current > location. That kind of thing is a security hole, and should be taken down > from Market if it is discovered. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
