Difference between revisions of "Android Versions"

From eLinux.org
Jump to: navigation, search
(Versions: add major features list to table)
(Add link to wikipedia page for Android version history)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Versions ==
 
== Versions ==
 +
For a lot more detail, you should see the [http://en.wikipedia.org/wiki/Android_version_history wikipedia page for Android version history]
 +
 
The following different Android versions have been released:
 
The following different Android versions have been released:
  
Line 8: Line 10:
 
|-
 
|-
 
|1.1||''unknown''||2
 
|1.1||''unknown''||2
|The base release, with Android system, Google search, contacts, calendar, cloud synchronization, etc.
+
|The base release, with Android system, phone, camera, webkit-based browser, Google search, contacts, calendar, cloud synchronization, android market, etc.
 
|-
 
|-
 
|1.5||Cupcake||3
 
|1.5||Cupcake||3
Line 21: Line 23:
 
|2.2||Froyo||8
 
|2.2||Froyo||8
 
|Dalvik JIT, USB tethering, voice dialing, V8 and javascript, adobe flash support
 
|Dalvik JIT, USB tethering, voice dialing, V8 and javascript, adobe flash support
 +
|-
 +
|4.4||KitKat||19
 +
|Low RAM improvements, sensor batching, full-screen UI, ART experimental test
 
|}
 
|}
  
Line 30: Line 35:
 
=== Version 1.5 (cupcake) ===
 
=== Version 1.5 (cupcake) ===
 
SDK released April, 2009
 
SDK released April, 2009
 +
 +
Kernel version: 2.6.27
  
 
=== Version 1.6 (donut) ===
 
=== Version 1.6 (donut) ===
 
SDK released September, 2009
 
SDK released September, 2009
 +
 +
Kernel version: 2.6.29
  
 
=== Version 2.1 (eclair) ===
 
=== Version 2.1 (eclair) ===
 
SDK released October, 2009
 
SDK released October, 2009
 +
 +
Kernel version: 2.6.29
  
 
=== Version 2.2 (froyo) ===
 
=== Version 2.2 (froyo) ===
 
SDK release May, 2010
 
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 ==
 
== Fragmentation ==
Line 48: Line 81:
 
=== Need to support multiple versions ===
 
=== Need to support multiple versions ===
 
Dianne Hackborn had this to say about fragmentation, after a developer complained about having to
 
Dianne Hackborn had this to say about fragmentation, after a developer complained about having to
support different version of Android:
+
support different versions of Android:
  
 
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
 
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
 
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.
 
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 ever 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.
+
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.
 
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.
Line 65: Line 98:
 
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.
 
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.
 
</div>
 
</div>
 +
 +
[[Category:Android]]

Latest revision as of 22:13, 11 November 2013

Versions

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

The following different Android versions have been released:

Version number code name API Level Main features
1.1 unknown 2 The base release, with Android system, phone, camera, webkit-based browser, Google search, contacts, calendar, cloud synchronization, android market, etc.
1.5 Cupcake 3 camcorder mode, video and picture upload to net, auto bluetooth connect, animated screen transitions
1.6 Donut 4 voice search
2.1 Eclair 7 more screen resolutions, live wallpaper, MS exchange support, UI revamp
2.2 Froyo 8 Dalvik JIT, USB tethering, voice dialing, V8 and javascript, adobe flash support
4.4 KitKat 19 Low RAM improvements, sensor batching, full-screen UI, ART experimental test

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

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.