It's always interesting to see how the talk-back section reacts to things like this. And the article in general isn't terribly forgiving toward this perceived problem.
Though I question the amount of credibility given to Rovio as an authority on how fragmented the Android eco-system is, I suppose they have the most vocal feedback from the end-users out there because of the volume of units they've sold. However, it should be noted that the development and distribution of one application does not make them an expert. Without insight into their code's quality or their ability to anticipate conflicts when targeting multiple platforms, it's hard to say if the problem is with Android itself, or their development approach.
(Update 1/7/2010 - A bit of proof that Rovio is not infallible in their platform ports. Seems their recent Mac port neglected to lock up their application against piracy via Apple's documented procedure.)
All in all, the article is a good summarization of the concerns. However, if you ask Google's Andy Rubin, he will say it's "differentiation", not fragmentation. This is further solidified by today's announcement of Honeycomb, and how it's requirements differ to pander to the strengths of tablets.
Why doesn't Google just handle this??
To truly answer this question, you have to ask.. Where in Android's distribution does Google benefit the most? Since they make it available for free, there's no licensing income from the operating system itself (though some proprietary applications such as the Marketplace and Maps applications are rumored to be available to OEMs on the base install for a small royalty).
Simply put, Google benefits less from the operating system itself more than the services that are consumed on it. So, from their point of view, it's easy to hide behind how "open" the operating system is, and do whatever they can to encourage manufacturers to embrace the platform so they can distribute their services. Even if it means touting the ability of the manufacturer to put their own thumb-print on it at perhaps the expense of compatibility of applications not written by Google.
And since Google's proprietary Android apps are very transactional and "business-like" in nature around Google's web-based services, the likelihood of incompatibility for these base-line compatible applications is very slim.
I hate to say they're sort of hanging us out to dry... but... Hey.. it's free. You can ask for your money back.
Some might suggest that Google should lock down the ability to customize the OS. However, this contradicts the very nature of it's "openness", and creates some issues around how it's licensed. Simply put, the license in place allows for customization at just about every level.
For arguments sake, lets say they could do so without creating these issues (such as changing the license agreement). Enforcement isn't something that a company can do for free. Follow up for compliance and certification can eat into the budget of an OS that's technically not making any money, and certainly not scoring any revenue for chasing down consistency. And furthermore, it's a legal management nightmare for OEMs to juggle what parts of the system are modifiable and what parts aren't. At that point, the return on investment starts to decline, and an OEM might decide to go another way (such as licensing Windows Phone 7 or Symbian). Also, closing the source in certain areas invites the temptation of software patents. And speaking of patents, Apple and Microsoft have already sued a few handset manufacturers over violations within Android software. Google certainly doesn't want to be named as a defendant if they're forcing an OEM into an actionable position due to some arbitrary compliance rule.
Android is like Silverlight
Before you get riled up, I'm not comparing it to Silverlight in terms of capability or even drawing parallels to measures of success.
However, I am talking about how it's marketed. Lately, Silverlight is the prefix buzzword to a bunch of differing development platforms at Microsoft. You have Silverlight for Windows, Silverlight for Mac, Silverlight for Windows Phone 7, Silverlight for Symbian, Silverlight for Embedded, Silverlight the Flame thrower, Silverlight the T-Shirt, Silverlight the Toilet paper.. etc., etc. etc. Merchandising! Merchandising!
While these products all bear the name Silverlight, and all have the same goal of being an application platform for various devices, each and every one of them are not 100% compatible with the other.
Google has taken this same approach with Android, but for a different reason. Whereas Microsoft's "fragmentation" of Silverlight is often due to hardware differences or where they wish to invest their resources, Google's approach is to make the platform compelling to OEMs by allowing them to modify it enough to "differentiate" (there's that word again) themselves from other manufacturer's products. Though it appears that Honeycomb will also introduce the hardware reasoning as well.
First of all, repeat after me... Android is a marketing term and a baseline specification. It's not the device itself. And once the OS has been tweaked, it's not even pure Android anymore, but rather a slight mutation of it. Barnes and Noble's Nook Color is a good example of a device that differentiates itself without relying on the Android brand for marketing and creating confusion. Under the plastic, it's powered by Android Eclair, but the marketing materials surrounding it downplay that fact quite bit.
The baseline Android OS merely implies that the porting effort for applications is probably going to be less across the various "Android powered" devices. In other words, unless you're making very simple apps (i.e. not graphically/input intensive like games), it's going to be a roll of the dice if it works on every device. The sooner you accept that, the happier you will be. You need to think of each manufacturers device, despite the fact it's "Android powered", to be as different as HTML5 is across various browsers (in other words, a common API with varying degrees of compatible behavior). You may get lucky and the application may work without any modification. But if you don't expect that, you will be happier when it does.
Unless you have tested on any particular handset, you can't be certain that it works.
Currently, the Android marketplace gives no filter by particular device, so unless a developer has expressly said so, you have to consider an app on any particular device is "use at your own risk" in terms of it's functionality on any untested device. Unfortunately for those that wish to monetize applications outside of in-application advertisement (i.e. charge for it), this isn't a very appealing model. To fairly service your customer in this scenario, you must provide a trial version with the appropriate disclaimer that it may or may not work on that customer's device and they should use the trial as a litmus test to see if it works.
If you're a bigger company with some money to burn, there are various services out there that will let you test your application on various devices. Perfecto mobile is an example. Not endorsing or have even used this service to offer any real opinion of it, but it's an example of how one can test a number of devices without physically owning any of them.
Not a big company? Then you need to network. Due to the "open" nature of the Android community, there are plenty of people out there with various handsets who might be willing to try your trial application and evaluate it for you. Surprisingly, many end users (especially those excited about your product) will happily provide free beta testing for you just for the privilege of seeing it run "behind closed doors" and having exclusive access to it. Worried about having your code out in the wild? Network locally. Between myself, family and co-workers, I have access to about a half dozen different Android handsets. Assuming they would trust installing an app I have written on their phone, I would be able to see it run on a physical handset for free (or the cost of lunch). Local Android user/developer groups might also be an avenue of access to disparate hardware.
And lastly, snoop around a bit. Along with the standard emulator that comes with the Android SDK from Google. The Android Virtual Devices (AVDs) specific to certain devices are sometimes published. (For example, here's where you can get the Nook Color AVD and the Samsung Galaxy tablet AVD.)
So what COULD be done..
Ok, so Google isn't terribly invested in the success of your application. Not because they hate you, or because they are evil. They are just following their philosophy and guiding principles. (which incidentally says nothing about ensuring your application runs on Android nor even admits being a software company, but DOES say they make money off of advertising and providing information services) And if they have published such principles, you can hardly blame them for doing something they've not promised to do.
However, as at least one discussion participant at ZDNet pointed out, Google will likely get the blame for the "differentiation". And articles such as this obviously won't help the cause. Perception is everything. And this is something that Google's basement computer geek mentality has a hard time comprehending. It doesn't matter if you're actually not to blame if everyone thinks you are. "Free" goes both ways in this case. Allowing a brand you own to be the forefront of marketing on mobile devices in the way Windows is on PCs tends to make the consumers expect a similar consistent experience. The price of that freedom could very well be Google's reputation on how it chooses to handle (or not handle) the mess.
So what should they do? Obviously the phones that have their proprietary applications on them got there through a relationship with the OEM. In those situations, Google should encourage the OEMs to make official Android Virtual Devices and make them available and easy to find for the development community so applications can be tested. Perhaps even making this a requirement in order to use the Android name in the marketing would be a good way to handle it. Odds are, the OEMs have these virtual devices available to their internal engineers anyway. This would level the playing field for those that can't afford the testing services, and would give a very feasible way for the development community to manage the "differentiation" between devices. And if Google won't step up to do it, the development community should. Email campaigns work wonders if done in significant numbers and if the emails find their way into the inbox of the right entity.
Another thing Google could do is discourage and minimize deep modification by abstracting the areas that the OEMs like to change the most. OEMs would appreciate this because it would require them to do less modification to make their handset/tablet look different. Letting them just modify the surface areas of the OS would bode well for application compatibility across devices.
Google has done a rotten job at properly conveying it's vision for Android properly. To be fair, they've never said it was going to be a consistent experience like Windows, iOS or OSX across devices. But also to be fair, they haven't went out of their way to say it isn't, and have been coasting on that false perception to build it's success. Android is actually closer to the Linux roots it's based upon. And like other Linux distros, common roots do not guarantee compatibility.