From: eLinux.org

Android Versions

Contents

• 1 Versions
  • 1.1 Version 1.1
  • 1.2 Version 1.5 (cupcake)
  • 1.3 Version 1.6 (donut)
  • 1.4 Version 2.1 (eclair)
  • 1.5 Version 2.2 (froyo)
  • 1.6 Version 4.4 (kitkat)
• 2 Fragmentation
  • 2.1 Dealing with API levels
  • 2.2 Need to support multiple versions

Versions

For a lot more detail, you should see the wikipedia page for Android version history

The following different Android versions have been released:

See the wikipedia article for some good information about different versions.

Version 1.1

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

Version 4.4 (kitkat)

SDK release October 31, 2013

Kernel version: 3.10?

Links to Android 4.4 information

• Official Android Blog post:
  • http://officialandroid.blogspot.com/2013/10/android-for-all-and-new-nexus-5.html
• Consumer facing highlights:
  • http://www.android.com/versions/kit-kat-4-4/
• Platform highlights:
  • http://developer.android.com/about/versions/kitkat.html
• Android Developers Blog post:
  • http://android-developers.blogspot.com/2013/10/android-44-kitkat-and-updated-developer.html
• API highlights:
  • http://developer.android.com/about/versions/android-4.4.html
• SDK updates:
  • http://developer.android.com/tools/revisions/platforms.html

Fragmentation

Dealing with API levels

Developers should specify which API level their application requires or is known to work with.

See http://developer.android.com/guide/appendix/api-levels.html

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.

Category:

• Android