Andreas Constantinou analyzed the Android OS fragmentation earlier this year on VisionMobile. Essentially stating 3 dimensions of Android fragmentation: codebase fragmentation, release fragmentation and profile fragmentation. While this is true, there are a bit more aspects to Android’s fragmentation. I’d like to review these in this post.

-

Google and Android are affected by 5 types of fragmentation, which in turn affect the speed of innovation and support of Android, and cause problems to users, handset and non-handset vendors, operators and Google itself:

1. Release fragmentation

With so many versions coming out for Android a year, there are bound to be multiple versions of Android co-existing in the market. These offer different API sets to developers and provide different levels of user experience.

Current Android devices used on the market (source: Google)

Users cannot use the latest applications for their devices, as they are still employing older Android OS versions, which in turn causes frustration.

Handset vendors are expected to upgrade their older devices to the newer OS versions, which doesn’t happen fast enough.

Operators have to control the upgrade process itself, which adds an additional delay to the process.

Google releases more OS versions to improve Android and innovate on it, but this innovation comes at a cost, as the ecosystem around Android fails to maintain the same speed.

2. Implementation fragmentation

Different vendors implement some of the functionalities and APIs differently. And while Google’s CTS is aimed at reducing such differences, it is impossible to ensure 100% compatibility across all devices and all vendors – especially at the speed in which new OS versions are introduced.

Users bump into applications that behave differently on different devices, causing frustration.

Developers need to test their applications on a large and growing number of devices, modifying them to run different code when devices act differently.

Handset vendors need to adapt faster for newer versions of Android OS, and in ways that implement new APIs and fix old API implementations. At the same time, they need to upgrade their older devices, bringing more strain on their development teams.

Non-handset vendors need to build common API sets not covered by Google’s CTS to roll out new devices that enable the use of specialized third party applications for new product categories.

3. User experience fragmentation

Different vendors have created different UIs on their devices to differentiate from one another. Out of the top 5 handset OEMs who use Android, 4 have developed their own UI on top of Android: HTC (Sense UI), Sony Ericsson (Rachel UI), Motorola (MotoBlur) and Samsung (TouchWiz).

By introducing new UI layers on top of Android, these vendors are implementing the developer APIs slightly differently. As an example, on a Samsung Galaxy S device, trying to replace the default keyboard provided by Samsung to the AnysoftKeyboard which is found on the Android Market is impossible without a bit of hacking on the user’s part.

Users are left to their own when customizing default behavior and UI of Android using 3rd party applications that not always work.

Handset vendors who try to differentiate themselves from the pack through UI changes need to work harder to make sure third party applications work well.

Google will be trying to homogenize the UI of Android with its Gingerbread release which is expected later this year. This might reduce the amount of differentiation OEMs put on top of Android to some extent. It might also solve the issue of running different screen resolutions for Android to fit it into non-handset devices.

4. Form factor fragmentation

As Android is being adopted for other product categories, these will require optimizations to the codebase of Android in order to support them properly.

• In-car systems will need to deal with multiple displays to the same “device”.
• Set-top boxes and televisions will need higher resolutions
• DECT phones will need hard keys support

In addition to such fragmentation, there will be a need to add and remove API sets to cater these different devices.

Users will need a way to find applications that fit the API set implemented by the product they are using not only based on the OS version they have but also by the product category their device belongs to.

Application developers will need to decide which API sets to use in order to be able to run their applications on devices in different categories.

OESF and Google will be working on standardizing these new flavors of product categories, at times interacting with each other.

5. Codebase fragmentation

As Android is an open source operating system, most of its codebase is publicly available. With all of its success, this means vendors might fork out of the basic offering of Android and come up with their own flavors of Android.

With all the popularity of Android, codebase fragmentation is inevitable.

Borqs has done just that, forking Android on behalf of China Mobile as OPhone. While this is the first major fork, other examples exist – People of Lava’s television uses a specialized Android version. In it, you can see fragmentation of the user experience, product category and codebase.

OESF works actively to fork Android by defining new API sets for new functionality. This in turn works as a counter-measure to Google’s increasing control on the Android public codebase.

Operators in Europe have recently been contemplating an OS of their own for mobile devices. By forking Android they might reach such a goal faster, coming up with a different codebase and API set.

Is fragmentation bad?

Fragmentation is not necessarily a bad thing for the Android ecosystem. It shows the strength of the platform and its huge acceptance, which brings with it a large and growing set of requirements that Google cannot handle so fast. It also goes to show that the platform itself can be modified to fit different needs.

On the other hand, fragmentation is hurting the Android ecosystem. One of the main reasons for the adoption of Android is the promise of an application store, where third party developers build applications for the device. Fragmentation hinders the ability to leverage existing applications and makes it much harder for developers to introduce applications that run on multiple devices, especially cross-category ones. This in turn reduces the allure of Android to third party developers.

What will happen in the embedded space? Will Google pick up the challenge that device manufacturers are putting at its doorstep and move faster to cater their needs or will we see the emergence of industry groups like the OESF pushing for Android standardization in these areas instead?