Android fragmentation: something to fear?

Fragmentation is often cited as a major challenge for the Linux platform and mobile software ecosystem. The word gets thrown around a lot and tends to be used as a catch-all phrase to describe a wide range of loosely connected issues.

The rapid growth of the Android ecosystem and the significant number of new Android devices that are reaching the market with heavy software customizations has raised some questions about whether Google’s Linux platform is going to succumb to the fragmentation menace. In this article, we’ll take a look at what fragmentation means for mobile Linux and how Google’s operating system addresses some of the biggest challenges.

What is fragmentation?

When used to describe software platforms, the term fragmentation generally refers to the proliferation of diverging variants—a situation in which many custom versions of the software platform emerge and coexist with the original. Platform fragmentation can weaken interoperability because applications that are built for one variant might not work on others.

The Linux platform is particularly susceptible to fragmentation because its modularity and open license make it highly conducive to customization and derivation. Although mainstream Linux distributions are all functionally similar, there are a number of major areas where they diverge. Some examples include package management, preferred desktop environment, default application selection, file system layout, and software version choices.

The lack of consistency makes it difficult to build an application that will integrate properly across the broad spectrum of Linux distributions. This is why packaging, compatibility testing, and certain kinds of platform integration tasks are often done by the distros themselves rather than by upstream application developers.

The challenges are more profound in the mobile space than on the desktop because the degree of fragmentation is compounded by the fundamental differences between different kinds of devices. For example, applications that are built to support a specific form factor, screen resolution, or input mechanism might not be compatible with devices that have different characteristics in those areas.

Another issue that arises in the mobile space is that individual handset makers and mobile carriers will make their own changes in order to differentiate their products from competitors. Such changes can sometimes create additional compatibility pitfalls.

Android’s approach to minimizing fragmentation

Android fragmentation appears to be analogous to conventional desktop Linux fragmentation in some ways, but the Android platform is a very different kind of software ecosystem and consequently demands different solutions.

Unlike major Linux distributions—which each have their own meticulously curated set of package repositories—most Android variants share the same application delivery channel. When an Android device is released with unusual characteristics or a custom version of the platform, there isn’t really a practical way to make sure that the device can run every program in the Android Market. There is obviously no way to patch closed-source, third-party applications that might need to be modified to guarantee compatibility with platform customizations. The distro approach to mitigating fragmentation arguably won’t work for a platform that has a vibrant ecosystem of proprietary commercial software.

Google’s solution is the Android compatibility definition, a document that defines a set of baseline compatibility standards for the platform. Google uses its control over the Android Market to compel device vendors to conform with the compatibility standard. The Market is one of several pieces of the Android platform that is not open and has to be licensed from Google. In order to obtain a license to ship the Market, a device maker has to first demonstrate that its products meet the criteria established in the compatibility definition.

Google’s approach of tying Market access to compliance with the compatibility definition effectively encourages hardware vendors to stay within certain boundaries and not deviate from the default code base to an extent that would make applications incompatible. This is the reason why you see the same standard input model and user experience on virtually all mainstream Android devices.

The parameters of the Android compatibility definition are more restrictive than you might think. For example, the standard says that devices must have a touchscreen, camera, Bluetooth transceiver, and GPS. Any Android product that doesn’t have those hardware components is not in compliance with the compatibility standard and consequently cannot ship the Android Market.

These restrictions effectively ensure that all Android devices that are intended to run third-party applications are basically the same with respect to application compatibility. In addition to mandating some consistent hardware specifications, Google has also taken steps to make the Android software more resilient to fragmentation.

One key example is the extensive use of managed code for userspace applications. Most Android programs are compiled into bytecode that is executed by Google’s specialized Java runtime engine. Taking that approach—instead of using C and compiling to binary—sacrifices a lot of performance in exchange for significant gains in portability (and possibly security). Because the applications are compiled into bytecode, the software can work seamlessly across multiple processor architectures and there are not going to be any binary compatibility issues.

The exception to this rule is software that relies on Google’s Native Development Kit (NDK), which allows some components that are developed in C or C++ to be used in Android through the Java Native Interface (JNI). Mozilla’s Android port of Firefox is one example of an application that uses the NDK.

In order to ensure that applications that use native code will work across devices, the Android compatibility definition requires devices to support the NDK and supply access to certain native libraries and frameworks, including OpenGL ES. The compatibility definition says that the mandatory native libraries shipped on the device must also be binary-compatible with the versions that are included in the Android open source project.

Safely enabling differentiation

As we explained earlier in the article, product differentiation is a common cause of fragmentation. Google has found some practical ways to enable third-party platform customization without having to compromise application compatibility.

One of the most important parts of the puzzle is the Intent system, a mechanism that allows one Android application to invoke another and request specific functionality. When you click an e-mail address, for example, the platform will instruct the default e-mail application to start composing a new message and will automatically set the selected address as the recipient. This feature is facilitated by an Intent.

One of the many advantages of the Intent system is that it makes it easy for third-party applications to serve as drop-in replacements for the default applications. If you want to make your own Android e-mail client and you want to make sure that it doesn’t break all of the other applications that rely on e-mail functionality, you merely have to support the same standard set of Intents as the default e-mail client. You can also similarly replace the Web browser, the calendar, the media player, the addressbook, and many other core applications.

Unsurprisingly, Google’s compatibility standard says that when device makers replace a core application, they must implement support for the same set of standard Intents that is supported by the original application. This approach allows very deep customization in a way that is also respectful of application compatibility.

Version fragmentation

The compatibility standard and the various technical means by which Android discourages fragmentation are relatively effective. That is why Google’s Android compatibility program manager Dan Morrill contends that Android fragmentation is a myth.

“Because it means everything, it actually means nothing, so the term [fragmentation] is useless,” he wrote in a blog entry. “Stories on ‘fragmentation’ are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. ‘Fragmentation’ is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.”

It’s not hard to understand how he arrived at the viewpoint. Much of the public discussion about the fragmentation issue is severely lacking in nuance and is often misdirected. As I have attempted to describe in this article, Android has many mechanisms in place that mitigate a wide range of common fragmentation problems. Although Android’s exposure to fragmentation is much less dire than the critics contend, the platform is also not totally protected.

Android’s rapid pace of development and swift version churn create some very significant challenges. New versions of the platform introduce features and APIs that aren’t accessible in previous versions. The consequence is that software developed specifically for the latest version of Android might not work on older handsets. Google’s own platform version statistics show that more than half of all Android devices that have access to the Market are still using a 1.x version of Android.

The Android SDK defines API “levels” that are associated with each version of the platform. New API levels can introduce additional functionality and potentially deprecate existing functionality. Each application has a manifest file that specifies the minimum and maximum API levels in which the program can operate. The application can only run on devices that are running a version of Android that fits within the boundary of the application’s supported API levels. It’s a bit like the versioning model that Mozilla uses for Firefox add-ons.

By default, the Android Market program will hide applications that aren’t compatible with the user’s device. Obviously, there is some very real fragmentation going on between different Android versions. As we saw at the recent Google I/O conference, development is still moving forward swiftly and new features are going to be arriving in future versions.