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;

1) Create a local mirror of the android repository.
2) Make a change to one of the files.
3) Check that back in to your local repository.
4) 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).

The comments section is now open….

6 thoughts on “AOSP – in need of love at both ends

Add yours

  1. I totally agree. I’d also like to add

    4. Eclipse. WTF? Netbeans is a million times more responsive, intuitive and stable.

  2. Good post (along with the last one).

    I have few ideas, that the Android team……

    1) Is deliberating delaying the release of the SDK and source codes so that new phones will have a “Wow!” factor when actually released.

    2) Has outgrown its infrastructure and just couldn’t catch-up at all fronts, especially for the AOSP.

    3) Has partially given up on the AOSP because, afterall, it’s HTC, Motorola, Samsung that are actually making the phones and “sell” Android. So they’re catering to the big guys.

    As you may note, the roadmap ( has not been updated for quite some time. But it doesn’t mean that the Android team doesn’t has a newer one. But that only those “in-the-loop” are aware of it.

    Also, at, the majority of the issues are still “New”, which means that they are not yet (officially) reviewed. To Google’s defense, some of the issues should be trivial and not posted there (e.g. device-specific and not related to the AOSP in general). But it’s a mess, if you compare to Chromium’s bugtracker, it’s being managed more actively.

    These being said, Android is still, and probably will continue to, growing fast. But it’s obviously, at its current state, not what some of us expected it to be, and there’s no sign that the status will change anytime soon.

  3. The first two points I think you hit dead-on.

    As for the third, the root of the problem is that you were led to believe that Git is a source code revision system.

    Don’t get me wrong, I think Git is a tremendously powerful developer tool, but if you have any experience with revision control systems and were expecting something similar from Git, you’ll be confused and very frustrated. Seriously, I’ve been down that road myself. It would be like downloading the AOSP code tree and expecting to find a mobile phone.

    If you’re going to use Git, the first thing you should do is (temporarily) forget everything you know about version control. It will just get in your way and trip you up. Approach Git as a developer’s tool that happens to work with versioned code, much in the same way that eclipse happens to provide text editing capabilities. Then pull up a good book, website, or other Git resource of your choice, and learn Git’s object model. No, not the command line options or gui wrappers or anything else, you can come back to those later. Learn how this thing is representing your data. Once you have that down, the rest will all fall into place. Yes, even the revision control uses. As long as it’s a black box that you just hand files to, it’ll always seem weird and behave in ways you don’t expect. But once you see what’s it’s really doing under the surface, even if you still don’t like it, it’ll at least make sense.

    That aside, the problem you describe is still very real, albeit perhaps not quite as high up the list. But the root of it is less about Google choosing this tool than it is about how Git presents itself. Even if Google had the best instructions ever written included in the SDK docs, developers who see it as “another version control system” will skip that chapter and expect to work off of a cheat sheet or something. And trust me, that way only leads to madness.

    1. Maybe the home page of Git ( should change their main title from “Git – the fast version control system” then ? :).

      As for downloading AOSP and expecting to find a mobile ‘phone, well, if the AOSP web pages stated that it was a mobile ‘phone in the title of every page, then yes, I might do, but it doesn’t.

  4. guess you shouldn’t consider yourself a coder. The point of AOSP isnt a DITY home depot project. You have to be CAPABLE of programming to do this or you WILL screw up your phone. But sense you can’t put 1+1 together you failed. Don’t blame google for that or AOSP. Blame yourself and read a few more books before you act like you know it all. It took me about 2 hours AFTER I received my N1 to build from AOSP and install on my phone. I had never programmed in Java before also… only VB/C… so I guess I just have to say you are lacking in skill but you are great complaining about how it didn’t come with a step by step instruction manual… perhaps your first building of OS should be trying to build Linux… its pretty easy only takes 3-4 lines of make statements depending on version. Master that before you complain 1st.

    1. When you comment on a post that’s nearly a year old you need to remember what things were like at the time.

      Sure, you can build it now, but, as the others who commented closer to the post time backed up, at the time the post was made you couldn’t.

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑