As the Android kernel code is now gone from the Linux kernel, as of the
2.6.33 kernel release, I'm starting to get a lot of questions about what
happened, and what to do next with regards to Android. So here's my
opinion on the whole matter...
First off, let me say that I love the Android phone platform. [Until
last week][^1], I used my developer G1, that I bought, every day. It worked
wonderfully for me, and as a user, I was more than happy.
I'm also very happy about Android from a technical perspective. It's
amazing that Google has taken the Linux kernel, and nothing else from a
"traditional" Linux system, and created a portable and robust phone
platform. It's so different that you can drop in a "real" Linux system
image on top of the Android system, and they both work just fine with no
Android also solves the problem that the phone manufacturers had been
having for many years: a free version of Java, and a unified application
layer that programmers can write to that will work on all phone
platforms that integrate it. Because of this, all of the existing
"Linux Phone Consortium" groups are doomed and will probably close up
silently very soon now, if they haven't already.
So, what happened with the Android kernel code that caused it to be
deleted? In short, no one cared about the code, so it was removed. As
I've stated before, code in the staging tree needs to be worked on to be
merged to the main kernel tree, or it will be deleted.
But there's a much bigger problem here.
The Android kernel code is more than just the few weird drivers that
were in the drivers/staging/android subdirectory in the kernel.
In order to get a working Android system, you need the new lock type
they have created, as well as hooks in the core system for their
In order to write a driver for hardware to work on Android, you need to
properly integrate into this new lock, as well as sometimes the bizarre
security model. Oh, and then there's the totally-different framebuffer
driver infrastructure as well.
This means that any drivers written for Android hardware platforms, can
not get merged into the main kernel tree because they have dependencies
on code that only lives in Google's kernel tree, causing it to fail to
build in the kernel.org tree.
Because of this, Google has now prevented a large chunk of hardware
drivers and platform code from ever getting merged into the main kernel
tree. Effectively creating a kernel branch that a number of different
vendors are now relying on.
Now branches in the Linux kernel source tree are fine and they happen
with every distro release. But this is much worse. Because Google
doesn't have their code merged into the mainline, these companies
creating drivers and platform code are locked out from ever contributing
it back to the kernel community. The kernel community has for years
been telling these companies to get their code merged, so that they can
take advantage of the security fixes, and handle the rapid API churn
automatically. And these companies have listened, as is shown by the
larger number of companies contributing to the kernel every release.
But now they are stuck. Companies with Android-specific platform and
drivers can not contribute upstream, which causes these companies a much
larger maintenance and development cycle.
What would be needed to get the Android core code merged?
When the Android code was merged into the staging tree, a number of
kernel developers reviewed the code and pointed out places that needed
to be cleaned up, and changed, in order for it to be accepted. A number
of these changes will affect the kernel/userspace boundry, so some
changes to the Android userspace logic would also need to be changed if
these kernel changes are made, preventing anyone except a Google
employee from making the changes necessary.
So, what to do?
I really don't know. Google shows no sign of working to get their code
upstream anymore. Some companies are trying to strip the
Android-specific interfaces from their codebase and push that upstream,
but that causes a much larger engineering effort, and is a pain that
just should not be necessary.
I do hold out hope that Google does come around and works to fix their
codebase to get it merged upstream to stop the huge blockage that they
have now caused in a large number of embedded Linux hardware companies.
I've privately offered in the past to help this work get done, and am
doing again here publicly. But I need the help of the Google
developers to make it happen, without them, nothing can change.
The good news is that it looks like all of the kernel/userspace api
changes will have no affect at all on any Android code higher up the
stack (like applications), so all of this work can be done with no
problem in the overall system.
As for me, I think I'll look into getting a Nokia N900. It looks much
more open, with the code mostly all upstream, and a much more active
[^1]: footnote text goes here
posted Thu, 09 Dec 2010 in