By Google? Highly unlikely that we'd ever do that. We're pretty heavily invested in the Linux kernel and it's been working well for us in Android.
By some other entity? Could happen, but the mid and lower layers of the Android stack depend pretty heavily on running on a Linux kernel. It'd be a bunch of work for questionable gain.
Non-carrier-operated app store? Danger Hiptop, 2003. Been there, done that, got (more than one) t-shirt.
Well, it wasn't easy to develop for until about year after launch, since they had no SDK at launch. Excellent spit and polish though on the software and hardware. Apple always nails that last 10%.
Yes, the ICS tree that will be released to AOSP is the same code used to do the build for Galaxy Nexus (among other products).
Instructions on building for Galaxy Nexus will likely end up here (alongside Nexus S):
http://source.android.com/source/building-devices.html
The handful of closed source userspace pieces necessary (some firmware, the hardware opengl libraries, samsung radio library, etc) will end up here:
http://code.google.com/android/nexus/drivers.html
(please disregard the unfortunate use of "drivers" here -- all the kernel drivers are GPLv2, none are closed source)
What's not included is the Google Mobile Apps (gmail, gcalendar, gtalk, maps, etc). These are proprietary Google applications, not part of the core Android platform (which consists of the lower level libraries, dalvik vm, framework libraries, services, core apps like phone, contacts, launcher, settings, etc, etc).
The closed bits on Galaxy Nexus are pretty similar to Nexus S (though the orientation sensor no longer requires a closed library -- one is provided that "adds extra value" but the system works fine without it).
There are remarkably few binary blobs in Android lead devices (some OEMs add more proprietary goop to their own phones though).
http://source.android.com/source/building-devices.html
Nexus S, for example, requires these pieces above and beyond the available open source userspace and kernel code:
- opengl userspace libraries (ImaginationTech)
- radio interface library (Samsung) -- glue between the Android Telephony stack and the Radio
- firmware for bt/wifi chip (Broadcom)
- GPS userspace library (Broadcom)
- NFC firmware / loader library (NXP)
- auto-calibration library for orientation sensor (AKM)
The closed pieces are available here, under a license that allows you to use them in your own builds, and even to redistribute (non-commercially) entire flashable OS images including them.
We continue to work to reduce the number of closed binaries needed on the lead Android devices. We have *never* shipped a lead device that includes any non-gpl/bsd kernel code.
Seems pretty absurd to me. They just launched an Android-based platform with Amazon-customized UI, their apps already run on Android devices (of which there are quite a few out there), and they have their shiny new cloud-assisted browser, built on Android and EC2. What do they need WebOS for? How are they a "fitting home" for it?
There actually are relatively few closed pieces necessary to make something like Nexus S go. For the most part they're firmware, not actual "drivers", though the opengl libraries fall into a middle ground -- the SGX kernel driver is GPLv2, the userspace opengl libraries are closed. We've been working with vendors to make the closed pieces available under a license that allows them to be included in builds and distributed non-commercially (commercial distributors tend to be OEMs which have direct relationships and licenses with these vendors already):
http://code.google.com/android/nexus/drivers.html
I'd use the term "proprietary components" rather than "drivers" (the above URL is unfortunately named), personally, since at least for lead devices that Google works on, all the kernel drivers are GPLv2 and readily available:
http://android.git.kernel.org/?p=kernel/common.git;a=shortlog;h=refs/heads/android-3.0
(kernel/common is code common to all variants, SoC-specific work is under kernel/omap, kernel/msm, etc)
Keep in mind that the *any* device that supports USB Host mode can be an Accessory. There's a full open source reference implementation for Arduino, but the protocols are documented and open and you can implement it on any hardware you like.
Docs and Specs: http://accessories.android.com/
Google IO Talk: http://www.youtube.com/watch?v=s7szcpXf2rE
I have often thought we would have avoided a lot of headaches if we started with NetBSD instead of Linux....
The reality is that in 2005, Linux had the most momentum with the silicon vendors, the largest base of developers (if you're looking to hire systems folks with experience with the kernel), and was easier to explain to carriers, OEMs, silicon vendors, investors, etc. The hardware platform was no longer highly constrained: at Danger in 2000, we started with a 24MHz ARM7, with no MMU, 8K unified cache, 16MB ram, 4MB flash -- at Android in 2005, a 200MHz 64MB ARM9 based system was the baseline -- we had a MMU! luxury! -- Linux no longer seemed like overkill for the hardware at hand.
Linux also draws a bright line between kernel and userspace with the explicit carve-out in the COPYING file declaring that userspace code need to be GPL to interface with the kernel. Explaining that "kernel is GPLv2, userspace is Apache2/BSD/MIT" is pretty straightforward. Explaining that everyone benefits from having a better kernel but the kernel is seldom what makes one product win or lose in the market is also pretty straightforward (seriously -- users only know the kernel exists if it's not working, otherwise it's not what they care about at all).
Realistically, it should be under a week's work for somebody to use the NDK (native development kit) to throw together an Xserver that runs inside a SurfaceFlinger (Android's compositor) Surface and then you could run whatever existing X-compatible thing under that. You could build a wrapper/adapter app that would allow "native linux apps" to trivially run this way (basically app xserver/clientlibrary window compositor/windowmanager).
It's not hard to build open source software to run on Android and there are plenty of tools to help you do it, especially on Gingerbread were the NDK provides support for native (C/C++) apps.
Yes, Android is not natively X11/Gtk/whatever, but that certainly didn't stop people from getting this stuff to run on Win32 or OSX...
I'd argue that having an open platform that Google can ship their apps on is extremely important in the huge and quickly growing mobile space.
It would be unfortunate if the only game in town for mobile OSes were a closed platform where only software approved by the platform owner could be installed. How could one defend against such an eventuality? Perhaps one might invest in building a competitive open mobile platform and make it widely available, no strings attached.
The "collecting data" thing is a bit tinfoil hat-ish for me. I see it much more simply as "if it's impossible for users to use your apps because the dominant platforms are controlled by folks who shut the door on you, you're going to have trouble obtaining (or keeping) users."
Android has a HAL for GPU integration (we call it gralloc), Gingerbread brings incremental and concurrent GC in Dalvik, and the Gingerbread NDK provides for all-native development options, among other improvements. You're welcome.
http://android-developers.blogspot.com/2010/12/android-23-platform-and-updated-sdk.html
Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.
