[This post is by Jean-Baptiste Queru, who moves truck-loads of source code in and out of the Googleplex. — Tim Bray]
Today is one of those days that has my heart racing; we’ve just released the source code for Android 2.2. This is a big step forward for the entire Android ecosystem. Please don’t melt the servers down again while trying to download that latest source code.
This blog typically talks about developing Android applications using the SDK and NDK. However, the skills of a platform contributor aren’t fundamentally different from those of an application developer. Those are simply different roles using the same skill set. I’m providing an update here to the experienced Android programmers all around the world on some of the recent developments in the Android Open-Source Project.
For Google engineers working on Android, releases are mostly known by their code names which are chosen alphabetically after tasty treats. I’ll call Android 2.2 “Froyo” throughout this post, since that was its code name. Raw version numbers don’t make me salivate as much as the thought of a cold dessert in the California summer.
Let’s have a look at some cool aspects of the new Froyo source, and let’s then take a few steps back to look at other noteworthy aspects of the Android Open-Source Project.
I had been increasingly involved in all previous open-source releases of Android, from testing the initial code drop to doing all the open-source-related git-level work in Eclair. Following that path, Froyo is the first release where my primary focus has been the Android Open-Source Project from start to finish. I thank the entire Android team for helping me all along with much of that work. Here are some aspects of Froyo that I am proud of, and that kept me busy for the last few months:
Hundreds of platform changes that people everywhere uploaded to the Android Open-Source Project were accepted and merged into Froyo. That process is now a well-oiled machine and will translate well to future contributions.
The open-source release happened in a single step. The whole source tree for the entire Android 2.2 platform is now available, with its full change history. That will accelerate everyone’s migration to Froyo from older releases. It is also already fully merged into the open-source master tree. Consequently, we can immediately review and accept platform contributions based on Froyo. That will therefore reduce the risk of merge conflicts between contributions to the open-source tree and changes in Google’s internal master tree where those contributions are meant to end up.
In order to make it easier for device manufacturers and custom system builders to use Froyo, we’ve restructured our source tree to better separate closed-source modules from open-source ones. We’ve made many changes to the open-source code itself to remove unintentional dependencies on closed-source software. We’ve also incorporated into the core platform all the configuration files necessary to build the source code of Android Open-Source Project on its own. You can now build and boot a fully open-source system image out of the box, for the emulator, as well as for Dream (ADP1), Sapphire (ADP2), and Passion (Nexus One).
Speaking of device support, we also open-sourced several additional hardware-related libraries that had been closed-source in previous releases, which will open the door to more contributions. Some examples are the recovery UI code for Dream, Sapphire and Passion, and the interface between the media framework and Qualcomm chipsets.
Besides the Froyo source code release, I wanted to mention several other improvements in the Android Open-Source Project:
We’ve been receiving contributions from more than twenty different companies, and many individuals. We have close to 4,000 registered users on the Gerrit code review server, with an average of 2 contributions per user. Those contributions have been in all areas of the system, from the depth of the C library all the way to the UI of the lock screen. They’ve covered the full range of complexities, from fixing typos in the documentation or reformatting code to adding developer-visible APIs or user-visible features. I want to thank everyone who got involved for their work and patience.
We’re now responding to platform contributions faster, with most changes currently getting looked at within a few business days of being uploaded, and few changes staying inactive for more than a few weeks at a time. We’re trying to review early and review often. As I’m typing this, only about a dozen platform contributions haven’t been looked at yet, with the oldest of those being 3 days old. More than 90% of contributions to the platform code itself have been actively looked at during the last 2 weeks. I hope that the speedy process will lead to more interactivity during the code reviews. I realize nevertheless that time differences around the world can make real-time communication a challenge.
Over the last 2 months, we’ve reached a final decision on more than 1,000 changes that were uploaded to our public Gerrit server. That means that those changes were either accepted or rejected after being reviewed. The high quality of the contributions we’ve been receiving throughout the history of the Android Open-Source Project has allowed us to steadily merge about 80% of them into the main repository, from where they migrate to official releases. That means that an average of 20 changes have been accepted through the Android Open-Source Project into the public git repositories every business day over those last 2 months.
We recently created two new official Google Groups related to the Android Open-Source Project. Android-building is meant to specifically discuss build issues (be sure to search the archives thoroughly before posting). Android-contrib is used to discuss actual contributions (don’t post if you don’t really intend to contribute and follow through on the review process, and if you haven’t already spent an hour or two researching things on your own).
We’re developing the developer tools directly in the open-source project, with no work in those areas happening behind closed doors. This covers the Eclipse plug-in and the emulator, and more than a dozen other SDK-related tools.
Once a platform version is open-sourced, all improvements to the Compatibility Test Suite related to that version are made directly to the open-source tree. In fact, release 2 of the 2.1 CTS was done 100% that way, with the development, testing and release process all happening straight in the open-source tree. This is now true for Froyo as well, and we are now accepting contributions into the Froyo branch of the CTS project.
I believe that those last two aspects are important to application developers. If you’re an application developer and you’d like to improve the tools that you and your fellow developers use, the process to make changes in that area is now a lot more transparent. Similarly, if during application development you find incompatibilities between devices and believe that those incompatibilities aren’t within the letter or the spirit of Android compatibility, you can help improve the situation by contributing a CTS test for that area.
With Android 2.2 now being available to the open-source world, and with the review process working smoothly, I’m looking forward to seeing a lot more high-quality contributions that will be used to build future versions of Android. My sweetest dream, which is also my worst nightmare, is to have so many contributions that I can’t keep up with them. Please don’t wake me up.