With Linux merge, expect Android flowers to bloom
Developers outside Google who want to build on the mobile OS's foundation should be able to stretch out and blossom. That should pay dividends for building a better Android.
Ordinary folks may not notice much right away from the fact that Google's Android programmers are bringing their work back into the Linux kernel fold.
But it's an entirely different situation for a smaller but important group: the programmers who like to experiment with Google's open-source mobile operating system.
So predicts Tim Bird, the Sony programmer who's centrally involved in the. That cooperation took a big step Sunday when Linux leader Linus Torvalds released version 3.3 of the heart of Linux with some fruits of the cooperation.
Android is open-source software, though the months of delays bringing Ice Cream Sandwich-based phones and tablets to market show how difficult it is to adopt that source code once Google is done building a new version behind closed doors. Android has plenty of higher-level components such as the Dalvik virtual machine for running apps and Google's own collection of apps. But down below all that is a Linux kernel that Google has forked from the mainline kernel Torvalds publishes at the Kernel.org Web site.
Google is working to develop at least some of its features along with the mainline kernel now, though, and that should pay dividends for programmers wanting to see what Android offers and how it can be improved.
In Bird's words:
This makes it easier for developers to do 2 things: 1) use Android features in non-Android systems, and 2) experiment with Android user space with a vanilla [mainline] kernel. The first of these is useful to analyze how the Android-specific features might integrate with or leverage other related features in the kernel. There have already been some good discussions on the kernel mailing list and on the Android mainline mailing list with ideas about moving forward.
Google hasn't tried to work in complete isolation, but some attempts to merge Android's Linux code with the mainline kernel didn't' work out well.
"A few previous attempts by Android developers to submit code to mainline resulted in stalemates--disagreements over how to proceed," Bird said. "A few general features (some of them high-profile, like wakelocks) ran into roadblocks and were delayed indefinitely. Some features were never seriously submitted to mainline for consideration."
Wakelocks are a mechanism an app can use to keep a computing device from going into a low-power idle or sleep state.
Bird noted that a lot of Android work for board support--in other words, the software necessary to use various central and supporting processors--has arrived in the mainline kernel already. And there's a good deal more to come after what made it into version 3.3 of the kernel, he said, including power management:
There is a large amount of customization work (particularly in the areas of graphics performance and power management) that is still needed on top of a mainline kernel, to ship a commercial-grade Android product. So people shouldn't assume that what is in 3.3 is sufficient for that. But it's a great start, and having a base that works in mainline makes it much easier to initiate a project with the Linux kernel and Android.
Bird already has seen programmers demonstrating the higher-level AOSP components running unmodified atop a mainline kernel with "a very small number of patches" to get it working. That bodes well for those trying to see what Android can do without clinging to Google's skirts.
In particular, it should be useful for those working on other Linux-based mobile devices.
And given that Google's browser programmers also have been working more closely with the WebKit browser engine project from which Google Chrome got its start, perhaps the company is convinced it's now missing out on benefits to sharing its code more constructively.