Sunday Editorial: What if Android got forked?

Some of us remember far back enough to the time — around November 2007 — when Android was first somewhat widely available as a software developers kit you could download from Google, and experiment with what might or might not have become a half-decent mobile operating system. I certainly remember downloading the SDK, experimenting with it for awhile, and then deciding that it showed promise – but it wasn’t there yet.

In these early days, Android devices ran Android as Google intended it — from Google’s developers, to our handsets. Early devices such as the HTC Dream (aka G1) and the HTC Magic ran plain, old, vanilla flavoured Android straight out of the box. This was an era before things like Touchwiz, before HTC Sense had left the Windows Mobile platform and come across, there were no different variants of Android, just different versions. The HTC G1 was released running Android 1.0 (codename Astro), and was later upgradeable to Android 1.5 Cupcake. The Magic was released running Android 1.6 Donut, but it was Android.

No skins, nothing.

Slowly but surely, we saw Android change. Donut made way for Android 2.1 Eclair around the same time as the release of the Google Nexus One. Android was becoming a more viable alternative to the dominant smartphones of the time — Windows Mobile, the iPhone, and Blackberry.

Android offered something a little bit different. Android has — as we know — an open-source base. It runs a Linux kernel, and the source code for the entire operating system is available to anyone via the Android Open Source Project. The liberal licensing attached to Android allows anyone to play with it — not just tinkerers and makers of fine custom Android distributions, like CyanogenMod — but also phone manufacturers. They can profit from what they do with Android, as well. They also don’t need to share things back with Android.

When this happens, we can see some pretty big differences between one interpretation of Android and another.

This is where we are today. The big manufacturers — HTC, Samsung, LG, Motorola, to name a few — can, and do, freely take the Android software developed by Google, make changes to it as they see fit, release it on the handsets they see fit, update it (or not) as they see fit, and they don’t really have to make it available for the open-source community to inspect either. Some parts, they do — the Linux kernel is one area where manufacturers are obliged to release any changes they make, though some are slow to do it — but beyond that, there aren’t such requirements.

The things we don’t have a right to see inside of are the things that — largely — make Android phones more accessible, usable and familiar to those who might be familiar with iOS, Windows Mobile or (to a lesser extent, perhaps) Blackberry OS. Touchwiz, Sense, Motoblur.. these are terms that used to upset a few people around Ausdroid, because we despised these things and tried to get rid of them, in search of the vanilla Android experience. As time went on, though, these things went from being mere bolt-on ‘skins’ to being virtually complete re-writes of the underlying Android operating system.

For example, in the early days, HTC Sense was little more than a few included binaries on top of an otherwise fairly unremarkable build of Android, and disabling Sense was as simple as installing a non-Sense launcher from the Android Market (as it then was) and dropping a few AOSP binaries onto your device.

Not so anymore. HTC, Samsung, et al, have spent millions of dollars developing their software, to the extent that their devices really don’t run Android, so much as an Android-based operating system. Let’s take Samsung for example. In the early days, Touchwiz was the same as Sense, in that it was (relatively) easily disabled and hidden. Nowadays, the Samsung Galaxy S III runs a far more sophisticated (and dare I say it, more enjoyable) version of Touchwiz, and many stock Android apps like Calendar, Contacts, Phone, Messaging, and so on have been replaced with completely customised Samsung-developed alternatives. Some of these are even pretty good — I find S-Planner to be far superior to stock Android Calendar, but that’s just me.

No better is this schism in Android exemplified by Amazon’s development of the Kindle Fire and its custom operating system. As we all know, the operating system on the Kindle Fire is vastly different to stock Android — things like the Android Market / Play Store aren’t included, and other features are completely different. The stock Browser is gone, replaced with a completely Amazon developed experience that leverages Amazon’s Cloud offerings to off-load some processing from the device to the cloud, with mixed results.

These modern changes to Android — Touchwiz, Sense, and Amazon’s Kindle Fire operating system — are, I would say, far more than mere skins on operating systems.

Some of us older folks will remember the days of Windows 3.1 and Windows 95 where people could literally download skins to change the appearance of their operating system. Fundamentally, of course, the operating system remained unchanged — it was still Windows, still had all the Windows components, and was still compatible with everything that was compatible with Windows. These things were truly skins.

Contrast with Sense and Touchwiz, which are completely ingrained with the underlying Android operating system they use as a base, components of Android have been completely removed and replaced with proprietary applications, and some things that work on, or come with, Android are not available. Major manufacturers recognise the value of retaining majority compatibility with Android, allowing users to access applications they expect to have, such as the Play Store, Gmail, and other Android staples. However, they don’t have to do this, either. The Kindle Fire is an example where the ecosystem is completely changed.

We see what Amazon did as a completely different operating system, yet people are quick to deny this in the case of Touchwiz or Sense, when the reality is the differences are far fewer than the similarities. It is trite to talk about Android fragmentation, but what we’re really seeing is not the fragmentation of Android as an operating system, but Android as a framework for the development of other operating systems. The time may come when Samsung and HTC go down the Amazon path, and break with the Android ecosystem entirely. I, for one, hope this doesn’t happen, but there really is no reason why they couldn’t.

Fragmentation of a operating system is nothing new — one need only look at what has happened with Linux to see a great example of how this can occur. Fedora and Ubuntu are both Linux, they both have a Linux kernel, and are — for the most part — compatible with each other, but not entirely. Applications designed for one will not easily run on the other unless recompiled.

Android is the same, but worse.

Not only do developers have to contend with different versions of Android between 2.x, 3.x and now 4.x, but not all Androids of the same major version are the same — developers have to contend with OEM customisations and issues as well. For more simple applications this is not a major concern, as they can rely on higher-level API call to work on most devices without significant effort, but for more complex applications that might rely on certain hardware being present, or that might make use of more complex graphical routines, one cannot rely on every handset being able to run their software.

Easy to bemoan if you take the view that all Android is Android, and it should just work, but that view really can’t be sustained much longer. I don’t think we’re at the stage now where there are many applications that will only work on HTC Sense, or that require Touchwiz, but is this really too far removed from reality? I say not, and that it’s likely we will slowly, but surely, see the move to a time where apps may actually work on specific manufacturer’s handsets, and not others, or where apps may be released in two (or more) different versions in order to best work with different hardware / software combinations.

Which way Android goes tomorrow will depend on what people buy today, and the reality is, people are buying the ‘Android-based’ handsets in far greater numbers than they are handsets that run AOSP Android like the Nexus S or the Galaxy Nexus.

I think it’s unavoidable that Android-based handsets will continue to dominate, but I remain hopeful that manufacturers will continue to make devices that can — easily, or not so easily — be modified for those that want to, while still providing awesome hardware and software for those who are content with what the manufacturer sells as-is.

TL;DR? Android has gone past the point at which it’s just one operating system. Android is now more of an ecosystem, made up of a number of Android-based operating systems, and while they mostly are interoperable now, that may not stay the case.

This editorial was inspired by a number of discussions taking place over the last week, especially following our previous editorial on fragmentation, and Amazon’s new Kindle Fire line being announced. We have been ruminating on this for a while and decided it was time. Thanks for reading. -Ed.