Interesting debate. And from a technical perspective I really like the simplicity of delegating responsibility and permissions to separate apks that have discretely defined scope. I'm just not sure how practical it is.
If you look at the permissions that are most contentious in combination : internet and read_contacts. I have avoided several apps that appear outwardly to be perfecty ok because I could see no good reason for the app to have this combo. But internet is often required for one of these (legitimite) reasons: 1) to report use statistics (eg Flurry) 2) to request and present ads 3) to otherwise hit an external server In an apps description if (3) is required you generally get told about it. But use of (1) or (2) is typically omitted because either its an instant sale killer or the target audience won't understand. The solution that you are proposing Dianne, would be for separate apks for options (1) and (2) and to have an app be able to convince a user that it is worthwhile the hassle of downloading (and dealing with upgrades) of those apps just to let the current app run. I know that if I was presented with that, then unless the app was a real beauty I would probably bail about then. The upside is that once the lbrary apk did get installed, the next app that required it would not have the same drama. However, while any of us could create an AdServer apk in the full light of everyone else, only one person can upload it to market. That person would then have the opportunity of warping the AdServer apk to funnel whatever amount of that Ad revenue into their own account. So if we were to collaborate on such a reusable component we would need a trusted owner. This one is close to my heart, because living in Australia, unless I get a buddy in the states who is willing to collect any sale revenue for me, my only real source of income from Android is via Ad revenue or donates. At the moment, innovation in some types of apps is being stifled because a good portion of the world can't make any income from them. William On Aug 30, 3:55 pm, Dianne Hackborn <hack...@android.com> wrote: > On Sun, Aug 29, 2010 at 5:17 PM, Bob Kerns <r...@acm.org> wrote: > > 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. > > How is bump's functionality as a separate .apk an unacceptable burden? It > does mean the user would need to install a separate app if they want to use > that functionality... but it should be very easy for the original app to > explain it needs this (when they want to use the functionality), clearly > associates that functionality with the bump developer (who btw gets some > nice branding there), and also allows bump to upgrade their client code > without having to get all of their app authors to update each app. > > > 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! > > We have been avoiding standard general shared library support partly because > we don't want to have DLL hell. (Also because the security implications are > nasty.) > > However, when you implement things as separate .apks, I think this is much > less an issue. If you aren't doing something extremely loosely coupled like > intent protocols, I think the interaction you will have between the two > pieces of code will by nature be much less tightly bound than with shared > libraries. It just doesn't lend itself to a large surface area API with a > lot of subtleties in interaction. It's more like client/server interaction > like APIs published by Facebook and other web services. (A corollary is > that this approach is not going to work for every case where you use shared > libraries... but what I have been observing is that in a lot of the cases > where some third party is providing a piece of functionality that is not > core to the app using it, this can work quite nicely.) > > > 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. > > I'm curious, what is this example of how Apple does it? Yes there is the > location thing, which as I've said is probably an exception that should have > per-app control for the user. What else? Having apps ask you to enter your > password to log in as admin in MacOS X? > > > But the current situation is not where we want to be! > > The current approach is I believe a strong improvement over what has gone > before. Things can always be improved more. The question is how that > should be done, and what are all of the repercussions (especially unintended > ones) that fall out from it. > > -- > 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
