On Wed, May 25, 2011 at 9:39 PM, Chris Stratton <[email protected]> wrote:
> On Wednesday, May 25, 2011 6:14:55 PM UTC-4, Dianne Hackborn wrote: > >> I'm still wondering what these "limiting decisions" are. > > I find that surprising, considering the amount of time you spend explaining > to people that the things they want to do are not possible, some because > they are not yet supported and others because your team intentionally chose > to preclude any means for a user to authorize an application to do that. > Frankly I would agree some of the things people want to do are really bad > ideas; but others a quite good ideas - the point is that this is a > subjective decision. Your team made its choices, but a lot of people > disagree with you about what should or shouldn't be allowed or supported, > and Android has not in the past been readily suitable for doing things > outside of it's architects' vision. Fortunately, the theoretical > possibility of producing one's own build is increasingly becoming a > well-organized reality of alternative distributions - changing "one little > thing" no longer means going it alone. Projects that weren't worth doing > when there was no base of devices capable of using them become worth doing > when the installed base of alternative builds grows. > I think you are using "limiting decisions" in a way different than DanH. What you are talking about here a simply policy decisions about what applications will be allowed to do. They are nothing the platform is tied to -- they can always be changed in the next release if there is a compelling reason to do so. (As I said, from a platform maintenance perspective it is *much* easier to remove restrictions on what applications can do than it is to enforce new ones.) The vast majority of limitations on applications (beyond what people coming from desktop operating systems expect) are there either because there is a compelling benefit for the overall platform or ecosystem for them to be there, and/or there has not yet been time to design and implement a facility for apps to use that is robust and maintainable for many years to come. But again, these have little do to with whether android has "legs" which was the original point of discussion. Let's take one of the limitations that comes up -- being able to intercept input events before they go to other applications. If we find ourselves in a situation where another platform has such a facility, and has allowed some developers to write extremely compelling applications that aren't possible on android, and this is threatening android's viability in the market, it would be fairly trivial to add such a facility to android. It was actually much harder to design and implement android to have the restriction than to not have it. That said, this is something we would 99% positively never just open up, because it would have many negative impacts across the platform. And consider it from the other direction -- if your platform already allows applications to freely intercept input events from other apps, and you find this is actually harming your platform, how do you fix it? That's a *really* hard problem, especially if you don't want to break a bunch of third party apps. (And when it comes to third party apps, you will often find them relying on this kind of stuff in places you never think they would have.) In fact this has been an issue for Windows. For example to implement the UAC dialog in a way that it can be sure the user is interacting with it and not some app, one of the things it does is switch to a completely different user environment in which the dialog is run, with a screenshot of the previous screen shown behind it to make it feel more integrated. So Android can actually implement a much cleaner and integrated experience with the user because of this limitation it places on apps. More than that, *apps* themselves can implement such interactions with users. Thus, as not infrequently happens, imposing a limitation on what applications can do actually opens the door for other things. > I think we are coming out of the most limiting period as official builds > are enhanced and alternative builds gain a following on a wide variety of > devices, but a lot of things that we expected would be possible with a > "pocket linux box" have historically not been possible with android devices, > for reasons ranging from the java-apis-first decision to the inability of a > user to alter the security model. > Yes if you want Android to be a "pocket linux box," that is not what it is. That really is a different product, and as the example I give above shows, making such a product is most likely going to be done at the detriment to many good things android provides. > It probably is worth looking at that subject of security for a minute. By > not giving the user any real ability to customize or exert fine grained > control, a given user cannot make their device less secure than the default, > but neither can they make it any more secure than a default they may find > quite inadequate. In an official build, I cannot for example decide that > it's okay for an application to know if I am on the phone, but not okay for > it to be able to discover my phone number. > I certainly agree that this particular permission was poorly done. This is a good example of where giving apps too much access bites us. I think there has been some ongoing work to split those pieces of information apart, because clearly access to personal information is a big and growing concern. These kinds of things have only served to reinforce my feeling that limiting what applications as much as possible should be the first design priority. :) -- Dianne Hackborn Android framework engineer [email protected] 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 [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-developers?hl=en
