« previous 1 2

Android versus Linux - Business as usual?

Some wakelock code was submitted back in January 2009 and was not well received and according to LWN.net attracted comments that said it "can't be used properly" and calling the code "hacked up". Google believe that the pm_qos (power management quality of service) API in the mainline kernel doesn't meet their needs and so the code was left in limbo. No progress was made in the months following, and much of the code sat outside the mainline kernel and staging area. The nature of the wakelock code meant it was used by Android drivers and other code, which meant that without wakelocks being implemented, Android drivers could not be easily upstreamed into the kernel.

Another, though lesser, issue in the Android code is "binder", an interprocess communications (IPC) implemented as a driver, which is used by Android programs to communicate between the window manager, applications and services. The Android developers incorporated binder back in 2005, while D-Bus, Linux's preferred IPC system, was still in early development. Other components use of D-Bus means that Android supports both D-Bus and binder, but generally Android code tends to make use of binder. The Linux developers would prefer only one IPC mechanism to maintain and that would be D-Bus.

These lines of contention and lack of progress towards a resolution eventually led to removal of the device driver from the tree in December 2009; the binder code and wakelock code exist only in Google's own tree for Android. This makes the Android Linux kernel a de-facto fork of Linux.

Google can spend engineering time maintaining their own fork of the Linux kernel with changes like this; the code is already deployed in millions of Android phones and they have experience in doing so. Some might assume that the GPL would require that Google have to commit their changes to the mainline kernel, but this isn't so. The GPL requires that Google publish their code and changes, which they have, but doesn't require those changes to be incorporated into the original code or project. It is still possible that Google could work on engineering code into the mainline which would in turn allow them to synchronise with the mainline kernel, but this will require months of engineering effort to rework and a level of risk of regressions for Android. As it stands, if Android OEMs want a fix from the mainline kernel, they have to backport the fix to the Android kernel or wait for Google to backport it or rebase.

That said, discussions are already taking place on LWN.net and in mailing lists which are seeking to bring the two kernel trees back together by implementing replacements for wakelocks and possibly, binder, with an eye on maintaining the power consumption of Google's current Android kernel. Whether these efforts will come to anything is yet to be seen. Linux has survived forking in the past and will no doubt do so again, though how long before a reunification between Android's kernel and mainline Linux occurs has yet to be seen. Android application developers are isolated from all of this by Google's use of the Dalvik virtual machine, so for them, it's business as usual.

« previous 1 2