Complications looming for Android developers.

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.

By Robert Green on Nov 06

It wasn’t long ago when using an Android phone really just meant using a G1 phone.  In one short year, we’ve seen different models of phones pop up from different carriers all over the world.  This is a great thing for Android as a platform because more users means more apps and hardware choices.  Unfortunately, there are many complications coming.

The G1, MyTouch and Hero phones all use a screen size called HVGA, or Half VGA.  It is 320 pixels wide and 480 pixels tall.  That’s exactly the same number of pixels as the iPhone’s screen.  Up until about 2 months ago, every app developed for Android was developed specifically for that screen size.  That was easy and it worked well.  With the introduction of Android version 1.6, support was added different screen sizes.  The platform does a nice job of letting developers tell the market what size screens their app supports, but that’s only half the story.

Many 2D games are developed for a fixed size screen.  Games that scroll up or sideways don’t really have too much of a problem adapting to new screen sizes but games that use an “arena” have to figure out what to do.  The new screen sizes aren’t just bigger or smaller – if they were, we could simple scale up or down for them.  They are actually wider and narrower as well which is especially difficult to cope with.

Original: http://androidandme.com/2009/11/news/complications-looming-for-android-developers/

Also:

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 perspective, 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 (seen below) 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.