On Thursday, May 26, 2011 3:16:07 PM UTC-4, Dianne Hackborn wrote: > > > But again, these have little do to with whether android has "legs" which > was the original point of discussion. >
A point which I tacked away from in my first post in this thread. I'm not worried about the future of android, but I was disappointed in its past. The whole lack of "legs" argument is pretty much irrelevant, because a derivative of android can become whatever it needs to for a future application. Even a derivative which no longer really deserves to be called "android" can still leverage a lot from the ecosystem. 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. > Rather obviously, there are embedded platforms which do have this capability, and android's lack of it has hurt its viability in some markets. Equally obviously, those markets are not the largest ones. That said, this is something we would 99% positively never just open up, > because it would have many negative impacts across the platform. > And that's where official builds of Android present a major step backwards in flexibility. What's missing is the ability to authorize "unusual" things without rebuilding the distribution - in effect, you've tried to build an operating system without a traditional administrator interface. And that's pretty limiting when you go beyond everyday functionality. But fortunately, this is a limitation of some android distributions - not of the ecosystem as a whole. 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.) > You have to have a mechanism to differentiate between the "I just want it to work" user and the "I want to really customize it or do something odd" user, which brings with it an expectation that things may break. Exploiting a security bug to gain full access and install a custom build is a pretty suboptimal such mechanism, but it's the mechanism available today. Yes, the devices actually sold by Google itself are better in this regard, as are some of the more recent tablets - but those are not the devices in wide distribution. > 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. > A simpler and ultimately more flexible option is for the O/S to abdicate responsibility to the extension. This is not without its downsides when unsophisticated users install questionable extensions, but it is ultimately the way almost everything else ends up working, even if it was not designed to - and that includes alternative android builds. 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. > Not designing android to be able to fully leverage its inner "pocket linux box"-ness was IMHO the major limitation on the range of creative uses to which the platform could initially be put, and step backwards in comparison to previous mobile frameworks based on that kernel. Fortunately, it is one which the increased native APIs and the ability to create custom builds are starting to overcome. Likely you feel that the decisions which were made were necessary to establish a critical mass in the marketplace - personally I disagree, and think that the opportunity was ripe for the introduction of something with a powerful backer sufficiently invested in it, almost regardless of its technical details. But that's now water under the bridge: practically everyone is now shipping their version of something that isn't quite what I wish it was, but can in enough cases be customized to be what is needed, in order to accomplish applications far beyond those for which it was envisioned. -- 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
