March 22, 2012 8:16 AM PDT
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.
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 merge of Google's Android Linux work with the "mainline" Linux kernel project.  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.
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. 
       Originally posted at  Deep Tech
 
 
 
 






 
No comments:
Post a Comment