Android hardly adds much to fragmentation when there's already Series 60, PalmOS, Windows Mobile, UIQ, Blackberry, J2ME, iPhone, various other Linux-based platforms and Qualcomm's own BREW. Surely what Google is really interested in is portability of "rich" Internet-based applications, which they expect to dominate. Qualcomm is presumably unhappy that BREW hasn't really taken off, but that's their own fault for locking it down so much.

Before IBM standardised the whole world on IBM PC clones there was huge diversity in the types of PC architectures that were available. There was no real OS, so software authors really suffered trying to make software that could run on a reasonable cross section of machines. There was MS-DOS (and others), but you had to bypass MSDOS and do direct hardware access to get anything like reasonable performance. Since all the different machines had diferent hardware, it was very difficult to write apps that worked well on all machines (or even a few common ones). Thus, it was really IBM and not MS that kicked off the "PC revolution".

There are quite a few Linux phone stacks but until one of these emerges ad the de-facto standard it will be hell to write phone apps. Writing for 5 or more different phone environments is just far too impractical. Google is a big enough player to provide a standardising influence. On course, Google could have just endorsed an existing environment but they have added some very interesting stuff in Android.

Yes, there are a lot of mobile platforms out there. However, most of them run a version of J2ME. So, today, if you want to build a cross-platform mobile app, you can do it with Java, as long as your app doesn't require anything that is not part of the J2ME standard API (less and less of a restriction these days as J2ME evolves regularly). Google Maps and Google Mail mobile are perfect examples of this. However, Android changes that because the platform is not compatible with J2ME: it uses a custom JVM, custom API, etc. So in practice, it does fragment the market. Guess why Nokia, who is one of the most active contributors to J2ME, is not part of the Open Handset Alliance?

I think the point is that Google don't want people to write native phone apps, they want native phone apps to fail by virtue of everyone standardising on web based apps written in AJAX or whatever.

So fragmentation of proprietary native platforms leads to standardisation of the application platform which Google is very happy to have, thank you very much because it isn't proprietary.

See Joel Spolsky's article. It worked for MS, it should work for Google.

http://www.joelonsoftware.com/articles/StrategyLetterV.html

Google maps is a severely limited by the fact that there is no GPS access from a MIDlet on the vast majority of handsets. I remember reading that that this resriction contributed to the decision to create android.

Let's not forget that android, while based on Linux at the OS layer, is basically Java SE with bells on. Very much like the Danger Sidekick devices. Writing native code, while possible [1], is not really feasible at the moment [2].

Java ME is too restricted to be useful for most non-gaming applications, there are just too many differences in JVM implementation to make it suitable. As for Java ME evolving regularly... How long has MIDP3 or the location API been in the pipeline?

[1] - http://benno.id.au/blog/2007/11/13/android-native-apps

[2] - The "Developing using C++" thread of the android developer mailing list