The Android OS Update Problem

The reasons that Android phones are either slow to get system updates, or fail to get them entirely are pretty clear. The process of getting an update ready to push to a handset is decidedly non-trivial:

  1. Google creates, tests and releases a system update.
  2. Handset manufacturers take the system update and apply their vendo-specific tweaks to it (MotoBlur, HTC Sense, etc.), then test it on their various devices.
  3. Carriers then test the update, certify it, and push it out to the handsets.

Mix in the fact that the average Android handset manufacturer seems to release 5-10 devices over a 12-24 month period and you can start to imagine the logistics involved in this process. We can clearly see an ecosystem that simply cannot properly provide long-term support for system updates to Android handsets (as it currently exists). It’s not due to malice, it’s just not practical.

I’ve been using a Droid 2 (R2-D2) with Android 2.2.x (Froyo) for about 5 months now1. The R2-D2 part is of particular note here, because while I have an Android device that is one of the most widely adopted handsets, it also means I have a different system OS than the stock Droid 2. While the stock Droid 2 received a system update last fall, the Droid 2 (R2-D2) has not received any updates since it was released.

So What? Or perhaps better phrased, why does this matter?

Geeks like to have the latest and greatest. We want the new, the better, the shiny. I certainly fall into that camp. However, I don’t really feel like I’m missing anything by not having Android 2.3 (Gingerbread). My 2.2 device does the things I need it to do, apps work, it’s stable… I actually don’t have any particular desire to upgrade to 2.3. Consumers are not terribly hurt (currently) by not being able to update their Android OS.

And that is the crux of the problem.

The lack of OS updates to active devices is creating a huge burden on the Android app ecosystem.

Developers have to support too many OS versions and devices. The testing matrix involved in supporting multiple OS versions, multiple vendor-specific extensions, multiple hardware configurations (differences in physical screen size and resolution, with or without a hardware keyboard, BlackBerry style keyboard vs. slide-out landscape keyboard, etc.). How to you optimize for user experience across that many variants? How do you effectively test your apps across them all?

This burden is heavy on the entire ecosystem. As it increases, it hinders the ecosystem’s ability to move forward until it eventually grinds to a halt. Stuck, unable to move under it’s own bloat. That is when it becomes a problem for consumers.

Smartphones in the post iPhone era are still in their infancy. This is a time in their evolution where they need to be nimble, able to quickly change and adapt, to constantly improve. The fragmentation of the Android platform is becoming a devastating impediment to that progress.

I experienced this on a small scale with my WordPress plugins and themes. Trying to maintain backwards compatibility was too much effort. It was taking longer to thoroughly test the new versions on various WP versions than it was to code, package and release them. It was hampering my ability to release. I eventually gave up backward compatibility as a feature and now test them exclusively on the latest release of WordPress as a matter of policy.

In stark contrast to the problems Android is seeing, Apple is cruising along nicely. They continue to push forward with their OS features and developer tools while fully supporting the last 2-3 hardware devices at the same time. Their 3rd party developers need only to buy one new device a year and the developer community is constantly keeping an eye out for when they can drop support for older OS versions. The result of this is twofold. Developers are able to invest their time building features and less on OS version and device testing, and the smaller device testing matrix means that both Apple upgrades and 3rd party apps are better tested on all of the iOS devices.

It’s clear to me which of these options is more attractive as a developer. If things go on as they are, it will become clear to consumers as well. The problem? I like choice. Though I plan to make the move to an iPhone 5 this summer, I don’t want my hardware options to be perpetually limited to Apple’s whims. I want Android to be competitive with iOS, but the current state of core OS + vendor extensions + carrier testing + developer burden won’t be able keep up. Something’s gotta give.

  1. With a brief interruption to go back to a BlackBerry. This didn’t take due to battery life issues on the BlackBerry with OS 6. [back]