In a recent talk with Froogloid via Twitter they said "fragmentation is here! We'll have to write special rules in every app to handle different phone models, not just firmware. uhg". In this article we will talk more about this matter. Chris Fagan explains to us that Froogloid is having some problems in running their applications as expected in different Android phones with different firmware versions and manufacture customized ROMs. Chris explains:

 

"In addition to the ROM's, Google is supporting 3 active firmwares simultaneously; 1.5, 1.6, and 2.0.  Each time a new firmware version is released we inevitably find bugs and spend a lot of time troubleshooting without much documentation from google.  We usually have to rely on dev forums to find our answers or luck out and figure it out ourselves!  Also, the fact that there are three firmwares available means we have to write custom code on each to support each firmware version.  That in itself becomes a nightmare to manage!"

 

Nearly a year ago the T-Mobile G1/HTC Dream was the only Android device available, but Android is growing very fast and today we have several devices with different firmware versions (1.5, 1.6 and 2.0). Also, each manufacter is trying to standout from the rest by adding custom user interfaces like HTC Sense UI, Motorola MotoBlur and the recently announced Rachael UI from Sony Ericsson. We have different hardware too, like phones with/without camera flash, the lack of physical buttons in some equipments like the Home, Back or Search, different screen resolutions and so on. Once again Chris Fagan shares their view:

"To top it off, you may build an app that works perfectly with all three firmwares, but then when you run it on carriers ROM it completely blows up!  So then we find ourselves having to create apps that are compatible with multiple firmwares, multiple ROM's, and multiple devices leveraging different hardware (for example some phones have cameras with a flash)"

In a developer perpective, we can see that it's getting harder for developers to maintain their applications. Chirs Fagan from Froogloid told us that for example, running one of their application, a2b, in Sprint HTC Hero launches the wrong settings. Instead of launching GPS settings it launches the "screen unlock pattern" settings which is in the same main settings area "security and location" on other android phones, but for some reason location is not listed when settings are brought up. It appears "security" and "location" may be 2 different settings areas.

Another aspect is the short time between the release of the SDK and the official firmware. Developers have to rebuild their code to work in the new firmware and sometimes this passage is not so straightforward. Applications built fo 1.5 and 1.6 can have problems running on 2.0 or can't run at all and some of them will have to be changed and use new APIs provided by 2.0.

So, what can be done in the future to avoid fragmentation? Applications have a big role in the growth of a platform, so, can the Android fragmentation be a drawback in Android growth? Can we expect that in a near feature developers start to develop applications that are compatible with only some devices or firmware versions?

In a video published before Android was even released as open source, Dan Morrill describes how google intends to prevent fragmentation of the platform. He says "traditionally the industry has tried to enforce compatibility by a contractual or stick approach", that he describes as "we're gonna give you the source code but only if you agree to follow there rules we set out", or "we're gonna give you the source code but only if you follow a particular test compatibility".

He goes on to explain that Google wants to take a different approach, "what we wanna do is set the bar really high, we wanna make sure this is a device the end users love, and when the end users love they will tell their carriers that they love this device", "by doing it that way people won't have an incentive to fragment the platform ... basically why would they take a successful platform and remove some of the key ingredients that made it successful in the first place".

The type of fragmentation referred by Dan Morrill may not seem to be directly related with the compatibility issues being reported by developers, since the problem is not that "key ingredients" are being removed from the platform, but that those compatibility issues are unintended consequences of the manufacturer's ROM customizations.

According to ZDNet.co.uk, in November 2007 Google confirmed that all the OHA (Open Handset Alliance) members had signed a non-fragmentation agreement stating they wouldn't modify the code in non-compatible ways, although the results don't seem to be the expected ones. Should Google intervene and have a more active role in the way manufacters customize their ROMs? Shouldn't it be the manufacturer's responsibility to assure that it's customized ROMs maintain application compatibility?

Since the community plays a big role in the android platform development, wouldn't we be able to develop a solution for this problem? Like what is happening with the JavaScript implementation testing in web browsers, there could be one or more community driven compatibility test suites in which developers create test cases that exercise a specific standard functionality or expose a specific problem in some ROM.

The test suites could then be run by developers and users in all the variety of ROM and device combinations, and the results made available online, helping manufacturer awareness of the compatibility issues in their ROMs. The manufacturers would still be responsible for pushing ROM updates to users, freeing developers from maintaining workarounds in their code.

Note: Post of Chris regarding the issue of Android fragmentation.