The following different Android versions have been released:
||The base release, with Android system, phone, camera, webkit-based browser, Google search, contacts, calendar, cloud synchronization, android market, etc.
||camcorder mode, video and picture upload to net, auto bluetooth connect, animated screen transitions
||more screen resolutions, live wallpaper, MS exchange support, UI revamp
See the wikipedia article for some good information about different versions.
SDK released February, 2009
Version 1.5 (cupcake)
SDK released April, 2009
Kernel version: 2.6.27
Version 1.6 (donut)
SDK released September, 2009
Kernel version: 2.6.29
Version 2.1 (eclair)
SDK released October, 2009
Kernel version: 2.6.29
Version 2.2 (froyo)
SDK release May, 2010
Kernel version: 2.6.32
Dealing with API levels
Developers should specify which API level their application requires or is known to work with.
Need to support multiple versions
Dianne Hackborn had this to say about fragmentation, after a developer complained about having to
support different versions of Android:
Developers will never be able to rely on there only being one version to target. Never. Please drop that from your mind. This is not the case on Windows, it is not the case on MacOS X, it is not the case on any platform that is not uber-tightly controlled.
That would mean that every user, of every Android device, would be delivered free updates as long as they are using the device. This would completely prevent very interesting Android devices like the Dell Streak (which due to its interesting design requires some customizations to the platform), and would significantly limit the ability of manufacturers to push Android into other interesting places.
This would also very greatly slow down the development of the platform. Every release of Android would need to be extensively QAed on every existing Android device before it could go out to any of them. There are currently > 50 such devices, and that number is growing exponentially. Android just can't scale if that final productization and QA phase is not spread out to the manufacturers. A core part of what makes our Android model work is that most products are owned by their manufacturer.
Here's a very small example: you say that manufacturers would be responsible for the kernel. Obviously, that is required because the kernel needs to talk with whatever their hardware is. However, pretty much every release of the platform has snapped up to a more recent version of the Linux kernel. The QA for that version of the platform is done against that kernel on a small set of specific devices. For what you propose, it would either need to be QAed across all possible kernels, or require that all manufacturers upgrade to the newer kernel before it can go out to any devices.
I honestly think that developers who are demanding there be only one version they need to think about are living in a strange fantasy world. Windows developers have always needed to think about 3 or so active versions of windows. From the stats I have seen there are regularly two very active versions of MacOS X that users run. Heck, if you are a web developer you need to consider different browsers and different versions implementing different versions of web standards.
I can more understand the issues from users, who want to be able to upgrade their current device to a newer version. Even there, though, if you compare us against another company that say releases a major platform update every year... we're not that bad. Look at the devices that have been out... how many at this point haven't received a significant platform update in the year since they came out? I think not many -- very few of them have been around for more than a year, and at this point the bulk of those have received at least one update. The main difference is that Android has gone through 3-4 significant updates in a year... so sure, not every one of those goes to every device, but I do think the manufacturers are showing that they are going to do some work to snap their devices to a more recent version, and I also think that as they are learning about Android and going through this upgrade experience the first few times they are learning how to better handle it.
At the end of the day Android is not a single monolithic uniform environment. That isn't what Android is intended to be, and honestly I think that this is something that should be pretty clear from day one. I consider that one of Android's strengths.