Measuring fragmentation in Android(pxldot.com)
pxldot.com
Measuring fragmentation in Android
http://pxldot.com/post/18281312362/android-measuring-stick
8 comments
Is it even worth developing for 1.x with sub 2% market share?
And 2% of 300 million is? Note that the number is not too different than all Windows Phone sales to date!
Android version 1.6 is barely over two years old. In most countries users buy their phones outright upfront, so they tend to be a bit more reluctant to keep upgrading.
Angry Birds for example supports 1.5 onwards IIRC. One of the products I work on is a library to be used in other apps, and hence it is the other developers' choice as to version support (and several support 1.x even for new products).
So commercially there is a good case. Technically it isn't too hard, other than requiring testing time and devices. You can set a filter on the API docs and every one is marked with version information. Obviously you are stuck if you require some newer functionality, but usually you can just make the feature optional if the API level is too old.
Here is the doc about how to handle backwards compatibility:
http://developer.android.com/resources/articles/backward-com...
Google supplies a compatibility library that can help bringing some newer APIs to older versions:
http://developer.android.com/sdk/compatibility-library.html
The upcoming version of the Lint tool also makes it easier to detect unexpected API version function usage:
http://tools.android.com/recent/lintapicheck
The development tools for Android are pretty nice, especially compared to the dross from older platforms.
Android version 1.6 is barely over two years old. In most countries users buy their phones outright upfront, so they tend to be a bit more reluctant to keep upgrading.
Angry Birds for example supports 1.5 onwards IIRC. One of the products I work on is a library to be used in other apps, and hence it is the other developers' choice as to version support (and several support 1.x even for new products).
So commercially there is a good case. Technically it isn't too hard, other than requiring testing time and devices. You can set a filter on the API docs and every one is marked with version information. Obviously you are stuck if you require some newer functionality, but usually you can just make the feature optional if the API level is too old.
Here is the doc about how to handle backwards compatibility:
http://developer.android.com/resources/articles/backward-com...
Google supplies a compatibility library that can help bringing some newer APIs to older versions:
http://developer.android.com/sdk/compatibility-library.html
The upcoming version of the Lint tool also makes it easier to detect unexpected API version function usage:
http://tools.android.com/recent/lintapicheck
The development tools for Android are pretty nice, especially compared to the dross from older platforms.
I developed an app for Android using the NDK (so I programmed it in C, not Java)[https://market.android.com/details?id=com.burnsmod.djpad]. What I found is that Android version fragmentation was much less impactful than differences between different phone models.
For example, /mnt/sdcard might be the internal storage. Or an SD Card. Where's the other mount point? You have to parse /proc/mounts to figure it out. How do you know which are which? I ended up writing a ton of rules like mount the point if (isEXT || isFAT || isFUSE && (not in a list of system mount points like /data)). There's no API (at least on the NDK side).
For example, /mnt/sdcard might be the internal storage. Or an SD Card. Where's the other mount point? You have to parse /proc/mounts to figure it out. How do you know which are which? I ended up writing a ton of rules like mount the point if (isEXT || isFAT || isFUSE && (not in a list of system mount points like /data)). There's no API (at least on the NDK side).
You could have made some initialisation calls in Java to get the various values from Environment and similar and then passed them on to your native code.
Thanks. I will look this up for future versions. Annoying to have to bridge it myself but better than my current solution (which is actually the suggested solution when looking on stack exchange at this exact issue :/ )
Although it is technically possible to implement the entire app in native code, you will find it far easier to use some Java as well.
Using the ports of SDL my app runs the same codebase for WebOS, Android, RIM Playbook and soon Apple iOS. While I already have a few Android-specific shims I'm trying to remain as platform-independent as possible to ease porting.
[deleted]
I never understood why people exaggerate so much Android's fragmentation problem, when the world's most fragmented platform, the Windows PC, has demonstrated it was not an obstacle to market domination...
One thing you missed about Windows is the huge amount of effort put into backwards compatibility. You can download the original VisiCalc for the 1981 IBM PC and it still runs. Note that DOS back then didn't even support directories (they were introduced in DOS version 2).
http://www.bricklin.com/history/vcexecutable.htm
Raymond Chen's blog is full of fantastic stories about Windows and the amount of effort they put in to backwards compatibility. A quote:
"Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messags? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)"
Some random examples:
http://blogs.msdn.com/b/oldnewthing/archive/2004/06/04/14842...
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481...
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...
http://www.bricklin.com/history/vcexecutable.htm
Raymond Chen's blog is full of fantastic stories about Windows and the amount of effort they put in to backwards compatibility. A quote:
"Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messags? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)"
Some random examples:
http://blogs.msdn.com/b/oldnewthing/archive/2004/06/04/14842...
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481...
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...
Actually you are wrong. VisiCalc does not run on Vista and up as Microsoft dropped 16-bit compatibility.
Nonetheless, I agree with your general point that Microsoft puts a lot of effort in backward compatibility. But so does Google with Android! What makes you think the Android API breaks backward compatibility?
I have some (light) experience with Android development (Bluetooth app, basic UI, etc), across Android 1.6, 2.0, 2.1 and 2.2, and I have for example never come across an API that broke backward compatibility. I often hear theoretical arguments like yours being made, but I have never been shown a concrete case, like "they broke X in the new version Y of Android, so I had to do Z to workaround it". In my experience, once an API call is stable and works in a given Android version, it never breaks in subsequent versions. I am sure there are some rare counter examples, but they are so isolated that they don't warrant all "Android fragmentation is a problem" articles I read around. These articles do not represent the opinion of the average Android developer like myself.
Nonetheless, I agree with your general point that Microsoft puts a lot of effort in backward compatibility. But so does Google with Android! What makes you think the Android API breaks backward compatibility?
I have some (light) experience with Android development (Bluetooth app, basic UI, etc), across Android 1.6, 2.0, 2.1 and 2.2, and I have for example never come across an API that broke backward compatibility. I often hear theoretical arguments like yours being made, but I have never been shown a concrete case, like "they broke X in the new version Y of Android, so I had to do Z to workaround it". In my experience, once an API call is stable and works in a given Android version, it never breaks in subsequent versions. I am sure there are some rare counter examples, but they are so isolated that they don't warrant all "Android fragmentation is a problem" articles I read around. These articles do not represent the opinion of the average Android developer like myself.
> ... run on Vista and up as Microsoft dropped 16-bit compatibility
You'd better tell Microsoft about that. They did drop it from the 64 bit versions but not the 32 bit versions.
http://support.microsoft.com/kb/926657
> What makes you think the Android API breaks backward compatibility?
What makes you think I made that claim? I will however make the claim that different Android versions have different bugs and because of that you have to test across all versions. I'm also willing to bet that if you use undocumented APIs and behaviours then you will get bitten on version upgrades - something Microsoft does not do.
And sometimes Google do annoying things. They messed around with the handling of configChanges in the manifest encoding it in non-backwards compatible ways. If you use the admob library you get forced into uses-sdk 13 which then changes your app appearance.
Here is a comment I made about versions if you want to see my opinion:
http://news.ycombinator.com/item?id=3637542
You'd better tell Microsoft about that. They did drop it from the 64 bit versions but not the 32 bit versions.
http://support.microsoft.com/kb/926657
> What makes you think the Android API breaks backward compatibility?
What makes you think I made that claim? I will however make the claim that different Android versions have different bugs and because of that you have to test across all versions. I'm also willing to bet that if you use undocumented APIs and behaviours then you will get bitten on version upgrades - something Microsoft does not do.
And sometimes Google do annoying things. They messed around with the handling of configChanges in the manifest encoding it in non-backwards compatible ways. If you use the admob library you get forced into uses-sdk 13 which then changes your app appearance.
Here is a comment I made about versions if you want to see my opinion:
http://news.ycombinator.com/item?id=3637542
Re 64-bit: you are correct. But this still proves my point that Microsoft sometimes deliberately breaks backward compatibility.
Re bugs across different OS versions: your initial comment implied that, because Microsoft puts so much effort into backward compatibility, that app developers do not have to worry about testing across different Windows versions. This is wrong. Just like on Android, Windows developers generally need to test across different Windows versions for bugs, etc.
In other words, my point is that both Microsoft and Google put a similar amount of energy into maintaining backward compatibility. Therefore, Android development presents a similar challenge to Windows development to developers who care about compatibility. And in both cases, the challenge is not that huge... Case in point: the vast majority of apps written for Android 1.5 will run just fine on 4.0 --this trumps all arguments!
Re bugs across different OS versions: your initial comment implied that, because Microsoft puts so much effort into backward compatibility, that app developers do not have to worry about testing across different Windows versions. This is wrong. Just like on Android, Windows developers generally need to test across different Windows versions for bugs, etc.
In other words, my point is that both Microsoft and Google put a similar amount of energy into maintaining backward compatibility. Therefore, Android development presents a similar challenge to Windows development to developers who care about compatibility. And in both cases, the challenge is not that huge... Case in point: the vast majority of apps written for Android 1.5 will run just fine on 4.0 --this trumps all arguments!
Windows was designed to run on white box PCs. It wasn't up to the PC manufacturer to ensure that Windows ran properly on each different model of their PC.
If I have an HTC phone I have to wait for HTC to prepare the latest Android upgrades, I can't just upgrade it myself.
Fragmentation on Windows wasn't a problem because if you hadn't upgraded to the latest version of Windows it was because you didn't run anything that required it.
If you haven't upgraded to the latest version of Android it's because you can't.
If I have an HTC phone I have to wait for HTC to prepare the latest Android upgrades, I can't just upgrade it myself.
Fragmentation on Windows wasn't a problem because if you hadn't upgraded to the latest version of Windows it was because you didn't run anything that required it.
If you haven't upgraded to the latest version of Android it's because you can't.
You are talking about a different issue (the OS having to support different hardware platforms).
I was talking about developers claiming fragmentation makes it hard to write programs for the OS running on different hardware platforms. My point is that the same level of complexity is involved in writing an Android app running on multiple Android versions and mobiles, and in writing a Windows app running on different Windows versions and PCs. And in both cases, it can be done relatively easily.
I was talking about developers claiming fragmentation makes it hard to write programs for the OS running on different hardware platforms. My point is that the same level of complexity is involved in writing an Android app running on multiple Android versions and mobiles, and in writing a Windows app running on different Windows versions and PCs. And in both cases, it can be done relatively easily.
It's a fundamentally different paradigm. A lot of people who have been in the mobile business a while remember the 'bad old days' of J2ME and horrific compatibility problems.
Don't forget, a new version of Windows comes around every 3, 4, even 5 years. But on mobile, we have new OS versions dropping every year, at least. And these new versions bring substantial new APIs. So it's a very different environment to a traditional desktop OS.
Don't forget, a new version of Windows comes around every 3, 4, even 5 years. But on mobile, we have new OS versions dropping every year, at least. And these new versions bring substantial new APIs. So it's a very different environment to a traditional desktop OS.
I don't think it's an exaggeration. It's not so much a compatibility problem, just as it wasn't for Windows, but instead it's a business problem. Google is increasingly unable to get new features to market in a timely fashion. They can side-step this to some degree releasing applications in the Market but long-term it's going to hurt them quite a lot if they can't get features out there.
You say "Google is increasingly unable to get new features to market in a timely fashion" but one post above yours, someone says effectively that "Google releases new APIs/features way too quickly".
This is exactly what I am talking about. People who claim fragmentation is a problem cannot even agree on what the problem is, concretely.
I believe Google does release new APIs often, but why would that break your application if it was not using this API to start with? Once an API is released (eg. the Bluetooth API in Android 2.0), it stays stable in the subsequent versions of Android.
This is exactly what I am talking about. People who claim fragmentation is a problem cannot even agree on what the problem is, concretely.
I believe Google does release new APIs often, but why would that break your application if it was not using this API to start with? Once an API is released (eg. the Bluetooth API in Android 2.0), it stays stable in the subsequent versions of Android.
Windows is fragmented? I use XP since 2002 and all programs are compatible.
Only very recently there are problems: DirectX10 doesn't work on XP and DOS programs don't work on Windows 7.
But still 99% of games and programs run on XP. Can you run a binary executable from 2002 on Linux or on Mac? How about binaries from 1995? On Windows they run just fine.
Only very recently there are problems: DirectX10 doesn't work on XP and DOS programs don't work on Windows 7.
But still 99% of games and programs run on XP. Can you run a binary executable from 2002 on Linux or on Mac? How about binaries from 1995? On Windows they run just fine.
I don't think you understand what fragmentation is.
Windows is fragmented both at the software layer, with all the different versions of it: 2008 R2, 7, 2008, Vista, 2003, XP, 2000, Me, 98, NT4, etc. And it is fragmented at the hardware layer, with all the different hardware configurations it supports(ed): type and number of processors (64-bit, 32-bit, 16-bit), type of disk (diskless, SAS, SATA, IDE, SCSI), amount of RAM, number and resolution of each monitor, input devices (keyboard, trackpad, mouse, joystick), etc.
The fact that many apps can run on XP proves my point: despite being an extremely fragmented platform, it is possible to write an app that is relatively portable on different Windows versions and PCs.
Windows is fragmented both at the software layer, with all the different versions of it: 2008 R2, 7, 2008, Vista, 2003, XP, 2000, Me, 98, NT4, etc. And it is fragmented at the hardware layer, with all the different hardware configurations it supports(ed): type and number of processors (64-bit, 32-bit, 16-bit), type of disk (diskless, SAS, SATA, IDE, SCSI), amount of RAM, number and resolution of each monitor, input devices (keyboard, trackpad, mouse, joystick), etc.
The fact that many apps can run on XP proves my point: despite being an extremely fragmented platform, it is possible to write an app that is relatively portable on different Windows versions and PCs.
>I never understood why people exaggerate so much Android's fragmentation problem, when the world's most fragmented platform, the Windows PC, has demonstrated it was not an obstacle to market domination...
It's easy to understand. While it is definitely an irritant for developers and users, the most noise about it seems to be coming from the Apple camp, who go out of the way and spend considerable effort in documenting the fragmentation and then escalating it to being the end of the world.
Take the only other blog post on the site linked.
http://pxldot.com/post/17983848516/one
The author talks about why he wants to write for the blog.
>I want to talk about numbers, and design, and Apple, and simplicity, and productivity, and life. Maybe there will be a unifying thread, but it’s entirely possible there there won’t be. The world is too big for me to commit to only a single piece. Even if this sharpens the pain of only being able to faintly cover any given topic, I am the sum of my passions, and what I create should be the same.
And then starts off not by talking about Apple, but how their competition is bad. It's nothing more than an attack piece to feel good about his/her choice. Why else would anyone who is obviously not very interested in Android as a user or a developer go to so much effort?
Not to mention that the fragmentation meme was started by Steve Jobs himself in an Apple earnings call, and all the Apple blog circles picked it up and went from there.
It's easy to understand. While it is definitely an irritant for developers and users, the most noise about it seems to be coming from the Apple camp, who go out of the way and spend considerable effort in documenting the fragmentation and then escalating it to being the end of the world.
Take the only other blog post on the site linked.
http://pxldot.com/post/17983848516/one
The author talks about why he wants to write for the blog.
>I want to talk about numbers, and design, and Apple, and simplicity, and productivity, and life. Maybe there will be a unifying thread, but it’s entirely possible there there won’t be. The world is too big for me to commit to only a single piece. Even if this sharpens the pain of only being able to faintly cover any given topic, I am the sum of my passions, and what I create should be the same.
And then starts off not by talking about Apple, but how their competition is bad. It's nothing more than an attack piece to feel good about his/her choice. Why else would anyone who is obviously not very interested in Android as a user or a developer go to so much effort?
Not to mention that the fragmentation meme was started by Steve Jobs himself in an Apple earnings call, and all the Apple blog circles picked it up and went from there.
I work with app that has about 100k installs across Android and iOS.
Android stats show we gave 375 different combos of device and OS versions. iOS has 75 which is pretty high for a platform with a supposedly unfragmented platform.
Android stats show we gave 375 different combos of device and OS versions. iOS has 75 which is pretty high for a platform with a supposedly unfragmented platform.
...75 device combinations with identical aspect ratios, and very similar hardware. Think about the difference between a Sony X10 Mini (320x240 display) and a Galaxy Nexus (1280x720 display): that sort of drastic hardware/software differentiation isn't there on iOS. Writing an app that works well on both is no easy challenge.
I'm not sure why this was downvoted. It's entirely true.
Think about button sizes. The iOS UI widgets are a specific physical size, optimized for the average human hand, which is then translated into pixels. Because all iOS devices have the exact same "pixel dimensions" (sure, there are four times as many now, but that doesn't matter much), supporting this is not a problem. The distance that the user will have to reach for a button and the dimensions of said button are physically identical on every single iPhone and iPod touch.
Android devices are many different sizes and shapes, so this sort of consistency is practically impossible (although I'd be really impressed if someone pulled it off, surely there's a way to get physical device dimensions in the Android SDK?).
Think about button sizes. The iOS UI widgets are a specific physical size, optimized for the average human hand, which is then translated into pixels. Because all iOS devices have the exact same "pixel dimensions" (sure, there are four times as many now, but that doesn't matter much), supporting this is not a problem. The distance that the user will have to reach for a button and the dimensions of said button are physically identical on every single iPhone and iPod touch.
Android devices are many different sizes and shapes, so this sort of consistency is practically impossible (although I'd be really impressed if someone pulled it off, surely there's a way to get physical device dimensions in the Android SDK?).
> Android devices are many different sizes and shapes, so this sort of consistency is practically impossible
Instead of incorrect speculation, here are some facts:
https://plus.google.com/105051985738280261832/posts/AzwMc3pS...
> surely there's a way to get physical device dimensions in the Android SDK
Since Android 1.0. You get the x and y dpi which can then be multiplied by screen resolution.
http://developer.android.com/reference/android/util/DisplayM...
http://developer.android.com/reference/android/view/Display....
Instead of incorrect speculation, here are some facts:
https://plus.google.com/105051985738280261832/posts/AzwMc3pS...
> surely there's a way to get physical device dimensions in the Android SDK
Since Android 1.0. You get the x and y dpi which can then be multiplied by screen resolution.
http://developer.android.com/reference/android/util/DisplayM...
http://developer.android.com/reference/android/view/Display....
> Android devices are many different sizes and shapes, so this sort of consistency is practically impossible (although I'd be really impressed if someone pulled it off, surely there's a way to get physical device dimensions in the Android SDK?)
If you are interested in how this for Android, the android design sign on metrics has a good overview, particularly the section on 48dp rhythm: http://developer.android.com/design/style/metrics-grids.html
If you are interested in how this for Android, the android design sign on metrics has a good overview, particularly the section on 48dp rhythm: http://developer.android.com/design/style/metrics-grids.html
You'd think BUT...
* SDK calls on different OS/hardware combos behave differently
* Different resolutions mean having to support different image assets etc (same as Android)
* SDK doesn't have built in support for fluid layouts or as good (but complicated) asset support as Android has
* New high resolution/different aspect ratio iOS devices are just around the corner
TL;DR iOS "fragmentation problem" exists and is likely to grow. Android SDK has ground up (but complex) features to tackle this problem
* SDK calls on different OS/hardware combos behave differently
* Different resolutions mean having to support different image assets etc (same as Android)
* SDK doesn't have built in support for fluid layouts or as good (but complicated) asset support as Android has
* New high resolution/different aspect ratio iOS devices are just around the corner
TL;DR iOS "fragmentation problem" exists and is likely to grow. Android SDK has ground up (but complex) features to tackle this problem
> * Different resolutions mean having to support different image assets etc (same as Android)
Far's I know, it only requires having different image asserts (@2x, and even that is optional), what's the etc?
> * SDK doesn't have built in support for fluid layouts or as good (but complicated) asset support as Android has
On the other hand, the need is nowhere as dire as on Android given all devices have the same aspect ratio, and there are only two physical sizes (for two well-defined classes of devices)
> * New high resolution/different aspect ratio iOS devices are just around the corner
There's pretty much no way iOS devices with different aspect ratios will be released (or they'll be a completely different line e.g. AppleTV which will not run iPhone/iPad applications).
Far's I know, it only requires having different image asserts (@2x, and even that is optional), what's the etc?
> * SDK doesn't have built in support for fluid layouts or as good (but complicated) asset support as Android has
On the other hand, the need is nowhere as dire as on Android given all devices have the same aspect ratio, and there are only two physical sizes (for two well-defined classes of devices)
> * New high resolution/different aspect ratio iOS devices are just around the corner
There's pretty much no way iOS devices with different aspect ratios will be released (or they'll be a completely different line e.g. AppleTV which will not run iPhone/iPad applications).
iPads have different ratio to iPhones/iPod right ? New iPad 3 is rumoured to have Retina display...
Totally agree that iOS did not need complexity of the Android SDK due to consistency in Apple product line up but I think they may have dug a bit of a hole for themselves if they want to shake things up in the future.
Totally agree that iOS did not need complexity of the Android SDK due to consistency in Apple product line up but I think they may have dug a bit of a hole for themselves if they want to shake things up in the future.
> iPads have different ratio to iPhones/iPod right ?
Ah yes, 3/2 versus 4/3.
> New iPad 3 is rumoured to have Retina display...
Yes, but it will very likely keep the 4/3 aspect ratio, and like the iPhone will scale "non-retina" images automatically.
Ah yes, 3/2 versus 4/3.
> New iPad 3 is rumoured to have Retina display...
Yes, but it will very likely keep the 4/3 aspect ratio, and like the iPhone will scale "non-retina" images automatically.
> iOS has 75 which
How do you figure that? I find under 60 combinations of OS release and devices total since the AppStore was released:
* 2.0, 2.1 and 2.2 for iPhone, 3G, Touch 1G and 2G (12)
* 3.0 and 3.1 for gens 1-3 of each (12)
* 3.2 for iPad (1)
* 4.0, 4.1 for gens 2-4 of iPhone and Touch (12)
* 4.2 for iPad and gens 2-4 (7)
* 4.3 for iPhone 3GS and 4, Touch G3 and G4 and iPad 1 and 2 (6)
* 5.0 for all above + iPhone 4S (7)
For a total of 57 combinations of devices and OS. As a theoretical maximum (I don't think finding active 2G devices on iPhoneOS 2.0 is very likely).
How did you get to 75?
How do you figure that? I find under 60 combinations of OS release and devices total since the AppStore was released:
* 2.0, 2.1 and 2.2 for iPhone, 3G, Touch 1G and 2G (12)
* 3.0 and 3.1 for gens 1-3 of each (12)
* 3.2 for iPad (1)
* 4.0, 4.1 for gens 2-4 of iPhone and Touch (12)
* 4.2 for iPad and gens 2-4 (7)
* 4.3 for iPhone 3GS and 4, Touch G3 and G4 and iPad 1 and 2 (6)
* 5.0 for all above + iPhone 4S (7)
For a total of 57 combinations of devices and OS. As a theoretical maximum (I don't think finding active 2G devices on iPhoneOS 2.0 is very likely).
How did you get to 75?
All those pesky point versions:
iPhone 4/5.0.1 iPhone 4S/5.0.1 iPhone 3GS/5.0.1 iPad 2G/5.0.1 iPhone 4/4.3.5 iPhone 4/4.3.3 iPod touch 4G/5.0.1 iPhone 3G/4.2.1 iPhone 3GS/4.3.5 iPhone 4/4.3 iPhone 4/5.0 iPhone 4/4.2.1 iPhone 4/4.3.1 iPad 1G/5.0.1 iPhone 3GS/4.3.3 iPhone 4/4.1 iPhone 4/4.3.2 iPhone 3GS/4.2.1 iPad 2G/4.3.5 iPod touch 2G/4.2.1 iPhone 3GS/4.1 iPod touch 3G/5.0.1 iPhone 4S/5.0 iPad 2G/4.3.3 iPhone 4/4.3.4 iPhone 3GS/5.0 iPhone 3GS/4.0 iPhone 4/4.0.2 iPhone 3GS/4.0.1 iPad 2G/5.0 iPhone 3GS/4.3.2 iPhone 3GS/4.3.1 iPhone 3GS/4.3.4 iPod touch 4G/4.3.2 iPad 1G/4.2.1 iPod touch 4G/4.3.5 iPad 1G/4.3.5 iPhone 3GS/4.3 iPhone 3G/4.1 iPad 1G/4.3.3 iPhone 3GS/4.0.2 iPod touch 3G/4.3.5 iPod touch 4G/4.2.1 iPhone 4/5.1 iPod touch 4G/4.3.3 iPhone 4/4.2.10 iPhone 4S/5.1 iPod touch 4G/4.1 iPod touch 3G/4.2.1 iPad 1G/4.3.1 iPad 2G/4.3.1 iPod touch 3G/4.3.2 iPad 2G/4.3.2 iPod touch 4G/4.3.4 iPad 1G/4.3 iPhone 3G/4.0.1 iPhone 4/4.0.1 iPod touch 3G/4.3.3 iPad 1G/4.3.2 iPad 1G/4.3.4 iPad 2G/4.3.4 iPod touch 2G/4.1 iPod touch 4G/5.0 iPod touch 3G/4.3.1 iPhone 4G/5.0.1 iPhone 3G/4.0 iPad 1G/5.0 iPad 2G/4.3 iPod touch 3G/4.1 iPod touch 3G/4.3 iPod touch 4G/4.3.1 iPhone 3G/4.0.2 iPhone 4/4.0 iPod touch 3G/4.3.4 iPod touch 3G/5.0
iPhone 4/5.0.1 iPhone 4S/5.0.1 iPhone 3GS/5.0.1 iPad 2G/5.0.1 iPhone 4/4.3.5 iPhone 4/4.3.3 iPod touch 4G/5.0.1 iPhone 3G/4.2.1 iPhone 3GS/4.3.5 iPhone 4/4.3 iPhone 4/5.0 iPhone 4/4.2.1 iPhone 4/4.3.1 iPad 1G/5.0.1 iPhone 3GS/4.3.3 iPhone 4/4.1 iPhone 4/4.3.2 iPhone 3GS/4.2.1 iPad 2G/4.3.5 iPod touch 2G/4.2.1 iPhone 3GS/4.1 iPod touch 3G/5.0.1 iPhone 4S/5.0 iPad 2G/4.3.3 iPhone 4/4.3.4 iPhone 3GS/5.0 iPhone 3GS/4.0 iPhone 4/4.0.2 iPhone 3GS/4.0.1 iPad 2G/5.0 iPhone 3GS/4.3.2 iPhone 3GS/4.3.1 iPhone 3GS/4.3.4 iPod touch 4G/4.3.2 iPad 1G/4.2.1 iPod touch 4G/4.3.5 iPad 1G/4.3.5 iPhone 3GS/4.3 iPhone 3G/4.1 iPad 1G/4.3.3 iPhone 3GS/4.0.2 iPod touch 3G/4.3.5 iPod touch 4G/4.2.1 iPhone 4/5.1 iPod touch 4G/4.3.3 iPhone 4/4.2.10 iPhone 4S/5.1 iPod touch 4G/4.1 iPod touch 3G/4.2.1 iPad 1G/4.3.1 iPad 2G/4.3.1 iPod touch 3G/4.3.2 iPad 2G/4.3.2 iPod touch 4G/4.3.4 iPad 1G/4.3 iPhone 3G/4.0.1 iPhone 4/4.0.1 iPod touch 3G/4.3.3 iPad 1G/4.3.2 iPad 1G/4.3.4 iPad 2G/4.3.4 iPod touch 2G/4.1 iPod touch 4G/5.0 iPod touch 3G/4.3.1 iPhone 4G/5.0.1 iPhone 3G/4.0 iPad 1G/5.0 iPad 2G/4.3 iPod touch 3G/4.1 iPod touch 3G/4.3 iPod touch 4G/4.3.1 iPhone 3G/4.0.2 iPhone 4/4.0 iPod touch 3G/4.3.4 iPod touch 3G/5.0
It's a good start, but it doesn't consider device diversity even within an identical version number of Android. Is may not be a factor for simple apps, but trust me, if you are doing things that interface with the underlying hardware it's a big problem. Apps that do things with Bluetooth and capturing audio, for example, really expose the fragmentation. I know some folks building something that records and plays audio over the Bluetooth SCO channel and even though they have standardized on Gingerbread, they still have to test every model from the major manufacturers due to different firmware builds.
Audio recording support on Android is pathetic. The APIs only have one error code - roughly corresponding to "it didn't work" without further clue as to what the problem is.
I also found that often the driver or hardware on HTC and Motorola devices would get wedged. You could only fix it by a reboot. (They were probably using the same Qualcomm chipset.)
Of course once it got wedged users couldn't actually tell. Any audio recording program (eg Google's voice search) would say it had started recording and then immediately stop saying "error". Because of the lack of useful error codes they had no idea why and usually didn't expect the error anyway giving a horrendous user experience (untested code paths).
You also can't practically record audio when using the emulator, and in any event it behaves differently than real hardware, so you have to development and testing with a variety of real devices.
I also found that often the driver or hardware on HTC and Motorola devices would get wedged. You could only fix it by a reboot. (They were probably using the same Qualcomm chipset.)
Of course once it got wedged users couldn't actually tell. Any audio recording program (eg Google's voice search) would say it had started recording and then immediately stop saying "error". Because of the lack of useful error codes they had no idea why and usually didn't expect the error anyway giving a horrendous user experience (untested code paths).
You also can't practically record audio when using the emulator, and in any event it behaves differently than real hardware, so you have to development and testing with a variety of real devices.
different iterations of an software platform are not "fragmentation". Fragmentation means that the platform is divided into multiple incompatible versions.
That is not the case here: The Android team does a pretty good job in keeping Android forward-compatible. That means that right now, more than 93% of all Android devices can be targeted by the same API (Android Eclair).
What the author is actually analysing here is the penetration and legacy of new versions of the cross platform technology Android. How fast are manufacturers creating and updating operating systems that are based on a new version of Android? But that's not fragmentation.
That is not the case here: The Android team does a pretty good job in keeping Android forward-compatible. That means that right now, more than 93% of all Android devices can be targeted by the same API (Android Eclair).
What the author is actually analysing here is the penetration and legacy of new versions of the cross platform technology Android. How fast are manufacturers creating and updating operating systems that are based on a new version of Android? But that's not fragmentation.
"Fragmentation means that the platform is divided into multiple incompatible versions."
You are describing only one aspect/axes of fragmentation: Operating System fragmentation. To really have a discussion of Android's fragmentation you have to take into account the entire mobile ecosystem. You must consider the fragmentation across 5 axes:
- User Interface
- Device
- Operating System
- Marketplace
- Service
FWIW, I wrote a piece that explains this taxonomy:
http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...
You are describing only one aspect/axes of fragmentation: Operating System fragmentation. To really have a discussion of Android's fragmentation you have to take into account the entire mobile ecosystem. You must consider the fragmentation across 5 axes:
- User Interface
- Device
- Operating System
- Marketplace
- Service
FWIW, I wrote a piece that explains this taxonomy:
http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...
While this is interesting data, I think that it is far too early to be judging the adoption of ICS, especially against Gingerbread.
On a technical level, ICS is a much more demanding upgrade (e.g updated graphics drivers that are pushed harder). You can see this with Cyanogenmod, which is well behind their Gingerbread pace, not to mention the bumpy road most (all?) of the official updates have had so far (e.g. Nexus S upgrade halted, XOOM and Transformer upgrades late, Transformer Prime has had a nearly continuous stream of fixes, including one yesterday, etc.)
To take it from the another angle, we already have more public commitments for ICS upgrades than we ever had with Gingerbread. A big part of that is that more people care this time around, so there has been a lot more pressure on manufacturers to disclose their plans, but I'd still argue that is an encouraging sign.
To me, it feels more like ICS has been in a public beta since the Galaxy Nexus release, rather than true, official release. My hunch is that Google just hasn't wanted to admit that. In any case, I don't think we're going to know how ICS is really doing for a while.
On a technical level, ICS is a much more demanding upgrade (e.g updated graphics drivers that are pushed harder). You can see this with Cyanogenmod, which is well behind their Gingerbread pace, not to mention the bumpy road most (all?) of the official updates have had so far (e.g. Nexus S upgrade halted, XOOM and Transformer upgrades late, Transformer Prime has had a nearly continuous stream of fixes, including one yesterday, etc.)
To take it from the another angle, we already have more public commitments for ICS upgrades than we ever had with Gingerbread. A big part of that is that more people care this time around, so there has been a lot more pressure on manufacturers to disclose their plans, but I'd still argue that is an encouraging sign.
To me, it feels more like ICS has been in a public beta since the Galaxy Nexus release, rather than true, official release. My hunch is that Google just hasn't wanted to admit that. In any case, I don't think we're going to know how ICS is really doing for a while.
Would be interesting to see a comparison to iOS - are there figures available?
Marco Arment does it pretty regularly: http://www.marco.org/2011/11/30/more-ios-device-and-os-versi...
And it's also worth mentioning that Instapaper will require iOS 5.0 beginning next update. His active users' OS adoption rate is really astonishing.
The critical difference is once a new version of iOS is released Apple stop distributing the old one (with a slight exception when the iPad first came out, and was on 3.2).
Only today Samsung have announced some new handsets at MWC that still run Gingerbread...
Only today Samsung have announced some new handsets at MWC that still run Gingerbread...
> The critical difference is once a new version of iOS is released Apple stop distributing the old one
and all supported devices can get the update on release day by clicking a button.
and all supported devices can get the update on release day by clicking a button.
The problem with these comparisons is that people take the rollout date of the end user operating system iOS and compare it to the first release date of the first OS based on a new version of Android.
Since iOS has no cross platform component similar to Android, it would make more sense to compare it to Google's Nexus OS or to Samsung's Galaxy OS.
I think the term "operating system" is so generic that it confuses a lot of people in these discussions. To many people and most tech journalists, the operating system is all software in a device before you install additional software. And by this definition, Android is not an operating system.
Since iOS has no cross platform component similar to Android, it would make more sense to compare it to Google's Nexus OS or to Samsung's Galaxy OS.
I think the term "operating system" is so generic that it confuses a lot of people in these discussions. To many people and most tech journalists, the operating system is all software in a device before you install additional software. And by this definition, Android is not an operating system.
The best I know of are from single developers, not global:
http://www.quora.com/What-proportion-of-all-iPhone-owners-us...
http://www.marco.org/2011/11/30/more-ios-device-and-os-versi...
for reference, iOS 5 was released October 12, Ice Cream Sandwich on October 19.
http://www.quora.com/What-proportion-of-all-iPhone-owners-us...
http://www.marco.org/2011/11/30/more-ios-device-and-os-versi...
for reference, iOS 5 was released October 12, Ice Cream Sandwich on October 19.
Huh? ICS was announced on October 19th, not released. The first release didn't come until mid-November, when the GSM Galaxy Nexus went on sale.
my bad, I checked Wikipedia and got deceived by the phrase “[…] officially launched at the Galaxy Nexus and Ice Cream Sandwich release event on 19 October 2011” but then it says only the SDK was released that day. so, one month difference instead of one week.
* G1 running 1.6
* Droid running 2.2
* G2 running 2.3
* Tab running 3.2
I'm going to have to add an ICS/4.0 device to the list soon, and am hoping that I won't need to find a 2.1 device (AT&T is to blame for a lot of 2.1 and not doing updates).
Cyanogenmod and similar ROMs are useless to me. They go ahead and fix bugs whereas I need devices having Google's bugs wherever possible to be representative for development and testing.