Android will be as fragmented as Java ME unless ...

Blogger: Richard Monson-Haefel

I've been researching Android, Google and friends answer to the mobile phone market, and it looks great until, that is, you read the fine print.  Google says that the members of the Open Handset Alliance (OHA) have all signed an agreement not to fragment the platform, but what does that mean?  It's hard to say without seeing the wording of the actual agreement, but if the API documentation is any indication it doesn't mean much.

According the the documentation the really interesting APIs such as those used for Location (e.g. GPS), 3D, Bluetooth, accelorometer, Wi-Fi, etc. are ... wait for it .... "Optional APIs". In other words, any given implementation of Android can pick and choose to implement whichever optional APIs they want.  This means that there is no guarantee that, for example, an application that uses GPS and BlueTooth is going to work on your mother's  Android compliant mobile phone.  In fact, I'll bet that consistency among handsets with regard to supporting these optional APIs will be poor. 

This should come as no big surprise to folks who do Java ME development because Java ME has exactly the same problem. Different mobile phones may implement the same basic Java ME configuration and profiles (at least CLDC 1.0 and MIDP 1.0) but they can also implement any combination of about two dozen optional Java ME APIs.  This is why Java ME is "fragmented" and its a problem that will occur with the Android platform as well.

The way to avoid fragmentation is to establish different stacks that specify a minimum baseline for Android phones that support optional APIs.  For example, the Android "Complete" stack would support all of the optional APIs.  Android "Advanced" stack would support some subset of the optional APIs. The Android "Basic" stack would support none of them. Once you establish standardized stacks you can minimize the fragmentation somewhat but it's still an issue. Java ME has these types of stacks starting with what is unofficially called GEN-1 (CLDC 1.0 and MIDP 1.0), the JTWI, and most resently the MSA.  With each new stack, or umbrella specification, Java ME gets tighter but vendors are under no obligation to implement these profiles.

If Android is to succeed it should offer only one stack. Otherwise what's the point of using Android over Java ME? Very little as far as I can see - they will both be fragmented and therefor impractical for mass consumer applications.

Of course, Google promises a much more open network but as I argued in a previous post that isn't going to happen unless Google secures the 700 MHz spectrum.  One advantage to Android: There will only be one implementation of the virtual machine and operating system - at least that seems to be the case. However as the Linux kernel on which Android runs is ported to different devices those ports may have small differences in exactly how phones carry out tasks close to the metal. Ports could diverge and inconsistencies may arise from one handset to the next. Another advantage of Android is the capability to change the look & feel (L&F) of the interface itself and to replace any application - even the basic dialer - with a third party application, but that will depend on the network operator. For example, T-Mobile, a member of the OHA, indicated that it will have some type of certification process for android applications running on their networks - you can bet that they are not going to give up L&F branding to third-party developers.

There are a lot of pieces that need to fall together to make Android more successful than Java ME.  Java ME  is shipped on 8 out 10 mobile phones today, but mass consumer applications of any value (beyond simple games) are just not practical.  If Android suffers from the same framentation problem and is far less pervasive than Java ME, then it doesn't offer a very compelling product.

I actually like the Android architecture and have high hopes for the platform, but the reality of mobile application development today in the mass consumer market is pretty discouraging - its hard not to be a skeptic.

UPDATE 11/28: ARCchart has published an article arguing that Android could eliminate fragmentation in the Mobile Linux world. It's a great article and while Android may resolve fragmentation in Mobile Linux it still suffers from fragmentation at the Java API level.