This was an interesting read.
But I wonder how overstated the fracturing issue is, especially for game development. I remember seeing something from one of the big Java game developers (might have been princec or Mario Zechner?) saying that they never worry about it and just target the biggest device and scale down. That’s what I’ve been doing for the few little Android games I’ve made.
I suppose it’s a bigger deal for apps that have thousands of downloads or that have more sophisticated GUIs than a game, but for most people I wonder if worrying about this is a form of premature optimization?
Information like this is only useful for guessing what you want to target. I think the unity folks are gathering similar information…which is potentially more useful.
Android variation is nothing compared to desktop variation. If you’ve figured out the sorts of things you need to do for desktop, Android is a breeze. You’ve got pretty much the same disparity in screen aspect ratios and resolutions to content with, the same variation in CPU and GPU performance, the same sorts of variation in available RAM.
Cas 
That’s a good point, Cas. People talk about Android fragmentation like it’s this big scary monster that nobody knows how to deal with, as if developers haven’t been dealing with it since the first monitor was invented.
Actually I suppose people were dealing with this even before monitors: I wonder how many people complained about “printer fragmentation”, haha.
I think the point really is in comparing Android to ios. I find that people coming from an IPhone to a comparable Android phone are always complaining about how quickly their apps run. Since the phone’s have fairly identical specs and the actual OSs run without a hiccup, I’ve always concluded that it is because a lot of Android apps cannot be optimized to the same degree as their equivalents on ios.
So yes we can deal with it, doesn’t make it the best outcome (purely in terms of final product, I think the pros outweigh the cons in this case).
Well you could always go NDK if you really cared about squeezing out performance.
Largely due to the crappy Dalvik JIT VM. ART should mitigate that as it matures (AOT FTW). More acronyms later.
Cas
When you start AOT compiling a dynamic language…you should know things are FUBAR.
To be fair they left out the truly dynamic aspects of Java “the runtime” and only kept the syntax and basics of the libraries. Works for me. I really like JET too.
Cas
fragmentation leads to either develop for the smallest common denominator. (weakest devices with a big enough market share)
or much higher portation costs.
also testing costs jump up.
Thats what drove off smaller developers from JavaME back in the days.
oops, sorry that thread was older than I thought