On Android

The source code to Android 4.0, nicknamed Ice Cream Sandwich, was made available last Monday. For developers of Android ROMs like my Blandroid project, these source code releases enable us to release our own modified versions of Android to users that prefer to use our software on their phones. The source code to the previous major version, Android 3.0, was not made available¹ and was only given to certain tablet manufacturers like Motorola.

While many complained about the lack of source code to a supposedly open source project, Google's "excuse" was that the code was not suitable for release. They rushed and hacked together version 3.0 to add a tablet-compatible interface to its then-current version, 2.3, nicknamed Gingerbread, so that tablet manufacturers could push out rushed and hacked-together tablets to compete with the iPad. Google told everyone to wait for Android 4.0 which would combine the tablet interface changes of 3.0 but still work on smaller screens like phones.

I put "excuse" in scare quotes because Google doesn't really need to justify their decision to anyone. Android is their product, they are free to do whatever they want with it, and any source code they release to anyone that isn't a partnering hardware vendor is a gift. That's not how they would like it to appear, though, and to most it would seem that anyone can just download and compile the code like any other open source project. To many people familiar with the term, "open source" is used for a project that is developed in the open, releasing changes as they are made, taking in patches and input from the community along the way before releases are finalized. Developers participate in the project, contributing code and project direction, releases are made, and developers and users use the software. Users sometimes become developers by fixing bugs in the software, which get merged in and pushed back out in future releases.

Android is sort of developed this way, except that the developers are Google employees and the users are the hardware vendors and "enthusiast" developers like myself of 3rd party ROMs like Blandroid. Google develops a new version of Android internally without any external input (other than possibly from partnering device manufacturers) until a release is ready. The source code is released to device manufacturers who add their proprietary hardware drivers and then build and test the release on their devices.

Android Open Source Project

Once hardware vendors have pushed out their new phones or released an over-the-air update to their existing customers, the new version of Android is "thrown over the wall", so to speak, to the Android Open Source Project (AOSP). The AOSP consists of Google-hosted mailing lists related to building and porting Android, and the git servers which host the source code. A handful of Google employees monitor the mailing lists and help out where they can, explaining why things won't compile or why such-and-such decision was made in the source code months ago. A small group of outside developers work with that new source code, merging in their own changes, tweaking things, and packaging up releases to work on existing hardware. This is how many 3rd party ROMs like CyanogenMod and Blandroid are developed. Occasionally outside developers find bugs in Android and submit patches to Google, who then merge the fixes into their in-house Android trees and distribute them to hardware vendors as necessary. This cycle repeats at somewhat lengthy intervals, with Google working on Android internally, preparing it for a new release, pushing it to vendors, and then pushing it to AOSP.

3rd Party ROMs

While the market is currently flooded with dozens of different Android phones, there have been only five phones released by Google. These "Google Experience" phones are the Android Developer Phone 1, the Developer Phone 2 (I had the T-Mobile-branded version which was not exactly the same), the Nexus One, Nexus S, and the Galaxy Nexus. For each of these phones, Google has partnered closely with a particular hardware vendor (HTC for the ADP1, ADP2 and Nexus One, Samsung for the Nexus S and Galaxy Nexus) to develop its new major version of Android and presumably instructed the hardware vendor to build the device with certain hardware features to show off the new software features of Android (such as the NFC chip in the Nexus S). When each of those phones was released, it was the only phone available with the new version of Android and it came directly from Google without any bloatware or UI changes often made by cellphone carriers before releasing new Android phones on their networks.

For Android enthusiasts, these phones are popular for two particular reasons. First, that new major release of Android that has just been pushed out to the AOSP servers includes the complete build configuration for that new phone. This includes the pre-built Linux kernel, the list of required packages and libraries, and most importantly, the hardware drivers needed to control critical parts of the phone like the touchscreen, wireless radio, GPS chip, and others. Without those drivers, the phone does not work properly. Having all of those components available means it's possible to compile a new version of Android and have the same functionality as the version of Android that the phone shipped with. The other major reason why the Nexus phones are popular among enthusiasts is that the phones come with bootloaders that can be freely unlocked, which means that the new Android release just compiled can actually be flashed onto the phone and used.

A Tangent on Bootloaders

A bootloader in the context of an Android phone is a small piece of software that gets executed by the phone when it initially powers up and passes execution to the Linux kernel stored in a boot image. While doing this, it verifies the boot image to ensure that it hasn't been modified. If the bootloader can guarantee that the boot image is secure, then every link down the chain should also be able to guarantee that it is secure, since it could only have been started by a secure component before it. While many will say that the only reason to use a trusted boot mechanism like this is so that device manufacturers and carriers can restrict what customers can run on their phones and limit their upgrade options (and to some degree they are right), there is a very legitimate reason to use it: the user of the phone can ensure that the software running on it is verified and secure. Just as I cannot flash a new version of Android to a phone with a locked bootloader, neither can someone trying to steal my data from the phone. Without a locked bootloader, it would be like protecting a computer with a login password but an attacker can just boot the computer to a USB drive with a different operating system on it and read the contents of the computer's hard drive. If the bootloader of a phone is unlocked at the request of the user, the bootloader forcibly deletes all data on the phone in preparation for loading a new operating system.

The Google Nexus phones come with the ability to easily unlock and relock the bootloader, which means that the bootloader will allow the user to flash a different boot image. For Android enthusiasts compiling their own versions of Android, this is how those new versions get uploaded to the phone and used. Unfortunately, most phones that consumers buy do not have a bootloader that can be unlocked, so new versions of Android that don't come from Google or the carrier cannot be uploaded and used.

Since there are many devices that have 3rd party Android ROMs for them but don't have unlockable bootloaders, one might wonder how that is possible. The answer is that the developers of those ROMs have to exploit a bug in the version of Android that came on the device in order to gain full access ("root") to it. This is just like the ongoing battle between Apple and iPhone enthusiasts to "jailbreak" the iPhone's iOS operating system to be able to run custom software on it. Once a flaw is found in iOS that can be used to jailbreak it, Apple fixes the bug (as any self-respecting company would, since it also represents a software vulnerability that can be exploited by malware) and releases a new version of iOS. Since device manufacturers and carriers push out so many Android phones every year and don't often provide software updates for their older devices, those security holes rarely get fixed. For the average consumer, that's quite sad. However, for anyone willing and able to flash a 3rd party Android ROM to it, these security flaws give them a way to do it, and once a newer 3rd party ROM is flashed, it will contain a fix for that security bug, and continue to provide updates for future security problems.

Legality of Redistribution

Now that developers have a way to flash their custom ROM to many devices, they must build a custom ROM specific to each of them by including different hardware drivers and modifying software features to accommodate the particular hardware features of each device. Unfortunately, what many ROM developers are doing is not technically legal. Every device that is shipped with Android contains proprietary, binary-only hardware drivers and firmware written by the device manufacturer or its vendors. Those files are not allowed to be redistributed, even to users that already own the hardware and have received the drivers on their phone to begin with. As an OpenBSD developer, I am all too familiar with the problems of redistributing firmware files. At first glance, it seems silly: why would a hardware vendor care if anyone gives out a driver or firmware blob that only works on that vendor's hardware, to users that already own the hardware which came with those same files? Well, sometimes those files contain things that the vendors got from their vendors and even if they don't mind users redistributing those files, the other vendors might, so they don't have the legal authority to permit it. Many just don't care enough to go through the trouble of clearing the licensing for their firmware files and offer them for download.

For the Google Nexus phones, Google makes available most, if not all, of the proprietary driver and firmware blobs for them. Presumably their legal department has cleared it with each hardware vendor and they are given permission to distribute them to users. However, just because Google is given permission to redistribute them, 3rd party ROM developers are not. When a developer downloads those drivers, they have to agree to a lengthy license agreement before extracting the actual files.

However, starting with Android 4.0, there are software features that require proprietary drivers and the operating system will not work without them. This means it is no longer possible to legally distribute a working 3rd party Android 4.0 ROM for any phone or tablet, even if one omits drivers for "extra" hardware like a wireless radio or GPS device. While it's unlikely that any hardware vendor will complain about a small subset of its customers redistributing its hardware drivers to another small subset of its customers, it is technically illegal and it is possible that CyanogenMod or my Blandroid project could be forced to stop. Distributing an Android ROM without working hardware drivers would make it much more difficult for end users to use it. Extracting the drivers from the user's stock ROM before upgrading is a legal solution, but since each phone may have different versions of drivers depending on when they were manufactured, this can lead to stability problems due to incompatible versions.

Proprietary Google Applications

Along with the hardware drivers, there are a number of Google-authored software packages that come on every Android phone. These packages such as Google Maps, Android Market, the new Face Unlock feature of Android 4, and the framework for communicating with a user's Google account are proprietary, closed-source applications that are not a part of AOSP, and are not freely distributed by Google. Hardware vendors must obtain a license from Google to distribute those applications on their devices, which means going through compatibility testing. However, Google states that they will not license those applications to software vendors, so no 3rd party ROM vendor can redistribute those Google applications even if they passed the compatibility testing. It is, of course, possible to use Android without those Google applications, but for many users, not even having the Android Market available makes it extremely difficult and unsafe to install the many 3rd party applications which make Android so popular.

CyanogenMod used to include these Google applications with its ROM until its lead developer was served with a cease and desist order and told to stop. The way CyanogenMod and Blandroid users obtain these proprietary applications is a bit murky now; instead of including the files directly in the ROMs, the projects link to a (poorly named) external site and tell users to download and install the package themselves. Just like differing hardware drivers, this action causes software compatibility problems and users often complain about not being able to use Google applications properly.

Android 4.0

As each new major version of Android is released with more features, the hardware needed to run it must be more powerful. The first Google phone, the ADP1, had a 528 MHz processor, 256 MB of RAM, and a 320x480 pixel screen. The current Google phone, the Galaxy Nexus, has a dual-core 1.2 GHz processor, 1 GB of RAM, and a 720x1280 pixel screen. With Android 2.3, Google stated that the ADP1 was no longer supported and stopped releasing drivers for it. With Android 4.0, Google has stated that they are no longer supporting the Nexus One. They have not released any proprietary driver files for the Nexus S, though a Google employee has stated that Android 4.0 is still being ported back to the Nexus S and its release date is not known.

The Galaxy Nexus

I went to Best Buy yesterday and spent some time wandering around the cellphone department. There are hardly any phones being sold there anymore that aren't smartphones, and probably 70% of those run some version of Android. It's easy to distinguish the newer Android phones from those 6 and 12 months old because the newer phones all have huge screens, not high resolution screens like an iPhone, but just comically large screens. Here is a good comparison of the Nexus One (left) which is about the same size as the iPhone, next to the Nexus S and the new Galaxy Nexus. The iPhone 4S is 2.3x4.5", the Galaxy Nexus is 2.6x5.3", and some phones I saw at Best Buy looked to be 3 inches wide.

The footprint of the Galaxy Nexus is much too large for my liking and, combined with some other poor design changes like removing USB storage support on Mac OS, not releasing a T-Mobile GSM version, and continuing the trend of small storage capacity (16gb) without any SD card expansion, make it a largely unattractive upgrade option for my current Nexus S.

The Future of Blandroid

Many Blandroid users choose to use it over other 3rd party ROMs like CyanogenMod because stability is Blandroid's highest priority. That stability comes largely from using the same kernel and hardware driver components that Google has released on its consumer devices that are known to be stable. I will not compromise that stability by releasing versions with unreliable components, which unfortunately means that since Google is dropping support for the Nexus One and I will not have a Galaxy Nexus to develop and test with, Blandroid will not see a 4.0 release for either of those phones. With the huge increase in build infrastructure needed to build Android 4 and the lack of any timeline for the release of Google's port to the Nexus S, it will be quite a while before Blandroid 4.0 is available for the Nexus S and Nexus S 4G.