Lowering the threshold, part one

Android is a modern, capable, perhaps even "sexy", mobile operating system. However, you can say the same thing about iPhone and Palm's upcoming WebOS. What distinguishes Android from those two is being open source. In theory, Android should be able to add more capabilities more quickly via having more people contributing to its development.

In practice, contributing to Android is far from easy. The simple things (e.g., contributing to documentation) are hard, and the hard things (e.g., overhauling built-in applications like the media player) are byzantine.

The "Lowering the threhold" series will be where I brainstorm ways to help make it easier for people to figure out what needs to be done and how best to do them. Most of these ideas could be implemented by anyone in the Android community — they are certainly not something solely the core Android team can accomplish.

And, since I'm a book author and publisher, let's start with a book.

We need more documentation on how to contribute to Android. This could come in the form of articles, or AndMob wiki pages, or blog posts. However, I suspect there is more than enough material to warrant a book, covering topics like:

• The Life and Times of Patches: Make a patch to Java code, and to C code, and walk through every step of the process, from initial concept to Gerrit submission to review and acceptance or rejection.

• Explain how best to work on changes to built-in applications like the media player: how can you use Eclipse? How can you package your changes for local testing? How can you make substantial changes yet still wind up with a series of bite-sized patches that might get approved?

• Describe the minimum set of steps necessary to contribute documentation changes. In all likelihood, the "minimum set of steps" will still be pretty nasty for somebody who is not a developer — more ideas on how to address that little issue in a future article in this series.

• How can you "hook into" the overall review and contribution system if you are a specialist, such as a tester, or a translator, or a security expert?

• How can you contribute changes to things that are not part of the firmware itself, such as development tools?

• What are the tools that the core Android team uses (e.g., code coverage) that those contributing code should also use? How do you use those tools for the Android code?

• If your contributions are tied to new hardware, such as new drivers, or ports to new chipsets, how does the contribution process change? In other words, how do you port Android and get the port to "stick" as part of the Android source code, versus forevermore being a set of patches you need to apply on each Android release?

• If you are creating custom firmware, such as an Android "remix" blending the Android OS and other applications, how best do you package up such a thing? How might you distribute it, either to customers or to the public?

• How best does one build firmware images, for emulators or devices, out of specific branches in the repository?

The Android source code site is very sparse on all of those things, and more. Their focus is on the bits and bytes of contributing changes (e.g., what are the proper command options to give to repo). We need to document more of the human side of contributing, to go along with the technical details. In the end, we need people to feel comfortable and confident in their ability to navigate the contribution process. The simpler we can make contributions, the more we will likely get, the more powerful Android can be.

I do not claim any proprietary rights in the book concept outlined above. If some author and some publisher wish to create such a title, more power to them. For anyone interested in potentially collaborating on such a book, though, drop me a line (mmurphy \at\ commonsware \dot\ com).

• Wireless / Mobile
• Android
• android development
• android firmware
• android programming