AOSP - In Need of Love at Both Ends
After spending some time trying to build a firmware I’ve seen some things which have opened my eyes as to why the Android Open Source Project may not be seeing the kind of community contributions that would be expected of such a high profile project.
Other people have shown an interest in knowing my thoughts so I’m going to throw out my top 3 for discussion which will hopefully help to improve things;
1. Lack of a device-runnable build of the latest Android version
Everyone likes to show off what they can do, but with Android firmware that’s a no go. There are a few code ninjas who have their builds of eclair running, but the chances of a developer checking out the android code, making a few tweaks, building a firmware, putting that firmware onto a device, and showing it off at a developers meeting are close to non-existant.
To me this is a huge barrier. How many times (recently) have you seen someone talk about their latest Android app and then say “hold up, let me get my laptop and fire up the emulator”?, possibly 1 or 2. Almost every time you’ll see their app running on a device they installed it on prior to coming to the meeting so you can get a feel for it in the context in which it’s going to be used, and the same should be true of the OS.
Imagine someone turning up at an Android meeting with an Android 2.1 device running a firmware with a built in, OS level, website blocker that could make the browser kiddie safe. That would turn a few heads wouldn’t it?, unfortunately with the AOSP as it currently is you’re only going to see this from companies who can invest a lot of time and money getting a build to work.
If someone wants to add a codec, try out a new scheduling algorithm, or implement a new OS level security protocol then people are going to want to see it on the device, not running in an emulator which may or may not show the same performance characteristics as an actual Android device.
The reason this is number 1 to me is because this is something I’m talking from first hand experience of. I showed an early version of a system level app to a few people on the emulator and there were a few nice comments. I showed it to a couple of people with it running on an ADP1 under 1.6 and there were a few jaw drops and people wanted to discuss venture capital investment.
That’s how game changing it can be to show off OS level changes on a real device (and yes, I tried to get it running on a 2.1 build on a Nexus 1, but I firmly failed to get a built-from-source 2.1 firmware that ran well on the device)
So, in my view, there needs to be a device which developers can build the latest firmware for. It would be nice if it was the Nexus 1, but I suspect there are a number of developers who’d be happy to start working on any device with a buildable, maintained latest version of Android, and a number of developers who’d buy the device just for that level of firmware customisation.
2. The Android 2.x release process
The biggest fear I have about my project right now is another 2.x release.
Traditionally 2.x releases have gone like this;
- Rumours spread a new version is coming.
- Device ships.
- SDK ships.
- “Open source” code made available.
which has a big problem; If you’re developing firmware based code you can be pretty sure that by the time the rumours start circulating the internal Google code tree has been frozen and you have no idea of which revision it was frozen at.
This leaves you with two choices;
- Continue to work on a tree you know is obselete
- Halt development until you get access to the tree for the new version.
As you can see, neither is a good option, and if you’ve been creating changes to the repository after Google froze their code then you may find all the code you’ve written may need to be redone, or worse still, that the functionality it provides is included in the new release using code from another source, thus making your code useless for future releases.
This means that volunteer community coders have to either run the risk that they may get caught by their changes being to an obsolete branch, or may face the prospect of their work being a waste of time because the latest version doesn’t need it, and neither of these situations is going to be appealing to an unpaid community developer working in their spare time.
3. Repo & Git
The nicest thing I can say about this combination is that an anagram of them is “Get Piro” which is amusing to me as I play Team Fortress 2 now and again (and yes, I know the proper spelling is pyro), the normal things I say when using them would make parents cover their childrens' ears.
I’m no stranger to source code revision systems, I’ve actually used more than I can remember; SVN, CVS, RCS, MS SourceSafe, Perforce, the filesystem on a VAX server (yup, I am serious), and plenty of others, so I’m not unfamiliar with source code control concepts, but the repo & git combo left me feeling like we’d taken a number of steps back along the evolutionary line.
If you want to experience it for yourself try doing the following;
- Create a local mirror of the android repository.
- Make a change to one of the files.
- Check that back in to your local repository.
- Check everything out into a different directory including your change.
These 4 simple steps took me half a day to master, and when you do master them you’ll start to grasp some of the problems involved in having your own local repository, making local changes, syncing between multiple machines, and keeping your build up to date.
Using them has helped me to understand why it takes so long for changes to go from Googles repository to the open source one, but there is a big problem here; these are suppose to be tools and every developer who wants to work on AOSP must master them.
They’re not core to Android, they’re not core to the concepts of the OS, they’re suppose to be helping us develop code, but when a required tool is this painful to use it can only result in one thing; voulenteer developers giving up and moving on.
So that’s my top 3 reasons why the AOSP is in need of some love from Google & the OHA to make it more developer friendly, and why it’s in need of some love from developers if they want to work on the code. I’d be interested to hear other peoples experiences, comments, helpful tips, etc. (but please keep the “You git n00b” comments to yourself).