There is no doubt that the patch situation is going to be interesting. We (Google) don't expect that any project upstream from us would accept giant code dumps from us, just like we probably wouldn't accept giant code dumps from someone downstream from us. The way Android has been developed so far definitely creates some challenges in the way we'll be able to interact with code maintainers upstream from us, we're aware of those challenges and don't expect them to be overcome without some significant and lengthy effort from our side.
Just like anyone contributing to upstream open-source projects, we totally expect that project maintainers upstream from us will want to see cleanly separated patches that each implement a single additional functionality, and they'll want each of those patches to come with documentation, code reviews, additional tests, and test results that are consistent with the standards set by those projects. And we will expect the same from people downstream from us who want to contribute back to us. None of that is fundamentally specific to Android being open-source, and such process constraints can be expected in any well-run software project, whether Google's or not, whether open-source or not. Going further, we don't, can't, and shouldn't believe that every single one of the changes that we made is going to be suitable for inclusion upstream. I fully expect some of our changes to be fundamentally specific to Android, and fully expect that we will decide that we prefer Android to have those changes while the code maintainers upstream would rather not have those changes in their code. There's nothing wrong with that, and it won't prevent us from collaborating with projects upstream from us in order to avoid drifting and forking. The same is true for projects downstream from us. And if drifting and forking turns out to be the both options, we'll do it or we'll let it happen downstream from us. There are a few differences between Android (and in fact most cell phone environments) and desktop environments. As an example, tasks that involve cooperation between multiple applications on the desktop typically involve copy-paste, drag-and-drop, or files that have to be explicitly saved and re-opened. On a mobile phone, it's usually considered more natural to create stacks of "screens" (the Android Activities). Also, desktop frameworks aren't necessarily prepared for the notion that there might not really be enough memory to hold multiple application processes in RAM, or (worse) for the fact that there might not even be enough RAM to hold all the screens of a single application at the same time. It is definitely correct for desktop frameworks to assume that there is enough RAM for most situations, and that the presence of a hard drive (and therefore of a swap file) will allow performance to degrade gracefully when memory utilization increases; in a vast majority of cases it is enough to let the OS (and by that I mean the kernel) take care of managing the system's RAM on its own. In a mobile environment, those assumptions don't really hold: there's not enough RAM, you can't assume that there's a lot of mass storage (and if there is you have to assume that it's either slow and prone to wearing out, like flash, or so power-hungry that you can't have it available at all times, like a hard drive); because of that, desktop software running in mobile environment tends to me more likely to corner itself into tight memory situations and to not degrade very gracefully when conditions get tight. In those two cases, I believe that we felt that it made little sense to try to reconcile the two approaches: we believe that both are quite correct given their constraints, but that they are too different to be both embodied in a single unified framework. You'll also notice some other differences between Android and typical desktop environments, though I won't claim that they're fundamental (but they're more consistent with the way mobile phones typically work): -applications running within Android are quite protected from one another, more than you typically find in desktop environments. -Android prefers to hide the fact that there's a hierarchical filesystem and prefers to manage lists of media files regardless of their location. In the end, we'll all have learned something. Maybe we'll see memory sizes on cell phones grow so dramatically that traditional approaches to memory management become practical on a mobile device. Maybe we'll find that preventing applications from deleting one another's settings is in fact a good thing to have on the desktop and expand that approach out of Android into other environments. Like you said, it's going to be interesting. Very interesting. I'm personally excited. Very excited. JBQ 2008/3/29 Stone Mirror <[EMAIL PROTECTED]>: > On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <[EMAIL PROTECTED]> wrote: > > > > > > > > > 2008/3/29 Stone Mirror <[EMAIL PROTECTED]>: > > > > > > > > > > > > > Well, good luck with that. Which "upstream teams" do you think will be > taking on Surface Manager, Binder, Dalvik and the remainder of the > never-before-seen portions of the platform (i.e. almost all of it), I > wonder... > > > > > > Er... we don't expect anyone to; we will maintain them ourselves. > > Well, that's realistic, anyway. > > > > > > > > Android consists of several totally new components such as those you > listed, and some patches for existing upstream projects (such as Apache > Harmony.) Our engineering teams will maintain our original components going > forward; we don't expect any third parties to assume ownership of these. > When I said that we're sad about having to sit on a large backlog of > upstream patches, I was referring to those projects whose software we've > used in Android. > > Aha. Well, as I said, best of luck with getting those accepted, hope the > effort doesn't make you any sadder. It did Nokia, and all they had were > 50,000 lines of actual improvements to GTK... Like I said, projects hate > code dumps, even worthwhile ones. > > > > > > > > Android 1.0 is the beginning, not the end, for our engineers. > > From the sound of things, and how! > > > > > > > > > > > > > > > There's a finite number of folks working on open source platform > development today, that's a simple fact. > > > > > > Finite, but constantly changing. Once we've cleaned up the source and > "push the button" to release it, that number will jump upward by the size of > our engineering teams. We aren't expecting to poach developers from other > projects. We intend to grow the open-source community in every sense. > > That's good to hear, too, even if it does guarantee a fairly inward-looking, > insular, community, at least for a while. > > > > > > > > > > > > > > So, why couldn't Google provide just the missing, un-free pieces, for > the benefit of existing projects, and work with the community to make > improvements where Google felt they were needed, with the community. Why the > necessity to come out with a whole new platform to go along with them? > > > > > > An excellent question! This is a technical question, though, not an > open-source one. The short version is that we think desktop-based > environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of > building applications, and Android's framework is designed explicitly for > mobile applications. > > Hm. I guess efforts like GNOME Mobile, Ubuntu Mobile, Moblin, GPE Phone > Edition, the LiMo Foundation platform, Maemo, OpenMoko and a variety of > others are just kidding themselves. They're all using GTK+, and I'd thought > they were managing pretty well with it. > > Perhaps you're confusing GTK+, an interaction stack, with GNOME, a desktop > program, or with the various window managers it can utilize. There's nothing > specifically "desktop-based" about GTK that I'm aware of (although the > widget libraries need work for smaller screens, something that's again, > already being addressed in the open source community). It works quite well > for mobile devices with a window manager (also open source) like matchbox. > > Can you be more specific about the technical issues you saw? If nothing > else, they'd be excellent feedback for the GTK+ community. (I.e., I wouldn't > mind hearing the "long version".) > > > > > > > > In other words, Android has two goals: First, to be an excellent mobile > platform on its merits, and second, to be open and open-source. We decided > the existing efforts didn't meet our needs, so we designed one that does. > > Again, no one seems to be clear on just why "existing efforts didn't meet > [your] need". "Fighting fragmentation" by introducing a whole different > fragment seems a little odd. > > > > > > > > > > > > > > > > Also, does this suggest that, for instance, Nuance (for instance) is > going to be somehow giving away their speech recognition software for free > to the world at large, turning what's now proprietary into an open source > project? > > > > > > That is correct: Nuance's speech-recognition engine will be open-sourced. > I believe that's one of the things that will be Apache 2.0 licensed. > > Now, that's interesting. Is Google going to acquire Nuance or something? > While I'm sure companies like Samsung, who are paying license fees for the > use of that software now, will be gratified to save the money, I don't see > how that leaves much of a business model for Nuance. Maybe I missed > something. > > Is the TAT framework going to be open sourced as well? And Esmertec's Java > VM? Sounds like serious money savings in store for the mobile industry at > large, if so, but it'd seem to throw the futures of the companies making > their livings with those technologies into some doubt... > > > > > > > > > > > > > > > > > Does it mean that Google is going to somehow pay the patent and > licensing fees on behalf of the rest of the world to be able to provide > "free" video codecs...? (If the latter is true, I'm sure the Open Media Now! > Foundation, for starts, would be happy to hear about it...) > > > > > > Also correct: the source will be released for the media framework, and the > codecs. As you say, in some cases there are patent licenses that need to be > acquired. I am not involved in the business side of the project, so I don't > know what the situation there is, but the traditional industry model in > these cases is that the manufacturer, carrier, or retailer pays the license > on a per-unit basis. > > Indeed. And passes that cost along to the end user in some way or other. But > you seem to contradict yourself: if Google's acquiring the patents and > releasing source for the codecs, why would anyone need to pay a license > anymore....? Maybe I missed something in there. > > Of course, one of the big questions is that, given the non-reciprocal nature > of the Apache license, what's to keep anyone from incorporating any > improvements they might find in Surface Manager into GTK, or re-purposing > those now-free (maybe?) codecs for use with Gstreamer, or getting the > now-libre Nuance voice recognition integrated into, say, the LiMo > platform...? It'll be dandy for all those projects I mentioned previously, > maybe not so helpful for Android: there are a lot more developers working on > GNOME-related technologies than Google's likely to be donating to the > community to support Android per se... Maybe Google doesn't mind if that > happens... > > Gonna be interesting. > > -- > 鏡石 > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Internals" 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-internals?hl=en -~----------~----~----~----~------~----~------~--~---
