The “Assembling the Android army” series of posts is where I provide completely unsolicited advice to Google and the Open Handset Alliance on strategies and tactics for growing the base of Android developers, to better cement Android’s place in the mobile platform marketplace. In the previous post, I argue that Android needs a culture of “we” if collaborative development is to take off on improving the open source platform.
As with the soft keyboard request, another topic of recent debate is having Android applications be installable to removable media, such as SD-style card media found in the T-Mobile G1. Since the G1 has very limited on-board flash memory, one can quickly run out of room for installed programs. Being able to install applications to removable media would greatly extend the number and size of applications one could have.
This is tricky to implement, as it is possible a user could eject the card with card-installed programs still running. How to deal with that case and related cases — what happens if you try to launch a program whose card is not installed, for example — takes deep understanding of the Android internals, from the installation process through the security model to the media-handling logic.
At the tactical level, we are fortunate that the core Android team has indicated that they are indeed pondering how to implement this, and there have been some design discussions held on the android-platform Google Group.
At the strategic level, though, perhaps the community needs an implementation less than it needs the knowledge of how to implement it. After all, the core Android team has indicated that somebody else could write an apps-on-SD-card implementation and, if it passed muster, would get incorporated into Android itself.
There’s just one small problem: it is unclear how anyone outside the core Android team would have a clue how to implement it correctly.
While writing this blog post, I attempted to figure out where in Android one might put this code. And while I am far from an expert at low-level device development, it is readily apparent that newcomers to Android will have quite the challenge jut to determine what is what.
Case in point: would apps-on-SD-card logic go in…kernel/? frameworks/? system/? While the kernel is fairly well-documented, most of the documentation is for the Linux kernel; Android-isms may be documented, but it is not obvious where. The other areas have little documentation that I can see, outside of the documentation for the SDK and details about the Dalvik virtual machine that powers the SDK. The Android platform Web site’s documentation page links to four videos, instructions for downloading the source, a coding style guide, various version control documents…and nothing about what is actually in the source, how to find where things reside, how the pieces plug together, etc.
Now, this is par for the course for an initial open source release. Documentation frequently lags. Open source projects with a culture of “we” can get past this by helping to educate new developers. For example, rather than implement the whole of apps-on-SD-card itself, the core Android team can help break the work into discrete chunks and try to recruit community members to work on some of the chunks. This would minimize the amount of documentation needed to get this feature implemented, plus it gets more knowledge into a few more heads who, in turn, might elect to write more documentation or work to help educate other community members.
Without a culture of “we” — if development is either by the core Android team or by “outsiders” but not collaboratively — then the pressure is all on the documentation, as that becomes the primary source for bulk knowledge transfer. If the Android source code is inadequately documented, it permits fewer developers to contribute. Only those with the skill and patience to wade through reams of source code would have a shot at learning independently how to do what needs to be done.
An open source community can be a force multiplier, amplifying what the core Android team can get accomplished by contributing lots of small improvements. The community can only do that, though, if it knows how. It can only know how if it is told how, whether on the fly in the context of collaboratively developing some feature or en masse via more formal documentation.
Without the knowledge, the community can only stand by, watch, and hope.
