8 ms·

Measuring fragmentation in Android

66 points by AndrewDucker 15y ago

sparkiegeek 15y ago
Would be interesting to see a comparison to iOS - are there figures available?
- natesm 15y ago
  Marco Arment does it pretty regularly: http://www.marco.org/2011/11/30/more-ios-device-and-os-version-stats-from-instapaper http://www.marco.org/2011/11/30/more-ios-device-and-os-versi...
  - AllenKids 15y ago
    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.
- falling 15y ago
  The best I know of are from single developers, not global: http://www.quora.com/What-proportion-of-all-iPhone-owners-use-iOS4-%2a-today http://www.quora.com/What-proportion-of-all-iPhone-owners-us... http://www.marco.org/2011/11/30/more-ios-device-and-os-version-stats-from-instapaper 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.
  - fpgeek 15y ago
    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.
    - falling 15y ago
      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.
- objclxt 15y ago
  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...
  - falling 15y ago
    > 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.
- bookwormAT 15y ago
  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.
gravitronic 15y ago
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 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).
- rogerbinns 15y ago
  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.
  - gravitronic 15y ago
    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 :/ )
    - rogerbinns 15y ago
      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.
      - gravitronic 15y ago
        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 15y ago
rogerbinns 15y ago
I am an Android developer. The simplest illustration of fragmentation is the devices I have on my desk: * 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.
- abraham 15y ago
  Is it even worth developing for 1.x with sub 2% market share?
  - rogerbinns 15y ago
    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-compatibility.html 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 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 http://tools.android.com/recent/lintapicheck The development tools for Android are pretty nice, especially compared to the dross from older platforms.
Rabidgremlin 15y ago
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.
- objclxt 15y ago
  ...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.
  - natesm 15y ago
    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?).
    - king_jester 15y ago
      > 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 http://developer.android.com/design/style/metrics-grids.html
    - 15y ago
mrb 15y ago
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...
- objclxt 15y ago
  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.
- rogerbinns 15y ago
  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 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/148427.aspx http://blogs.msdn.com/b/oldnewthing/archive/2004/06/04/14842... http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481... http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...
fpgeek 15y ago
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.
bookwormAT 15y ago
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.
- cek 15y ago
  "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-end-of-android/ http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...
weirdkid 15y ago
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.
- rogerbinns 15y ago
  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.

66 points by AndrewDucker 15y ago

sparkiegeek 15y ago

Would be interesting to see a comparison to iOS - are there figures available?

natesm 15y ago
Marco Arment does it pretty regularly: http://www.marco.org/2011/11/30/more-ios-device-and-os-version-stats-from-instapaper http://www.marco.org/2011/11/30/more-ios-device-and-os-versi...
- AllenKids 15y ago
  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.
falling 15y ago
The best I know of are from single developers, not global: http://www.quora.com/What-proportion-of-all-iPhone-owners-use-iOS4-%2a-today http://www.quora.com/What-proportion-of-all-iPhone-owners-us... http://www.marco.org/2011/11/30/more-ios-device-and-os-version-stats-from-instapaper 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.
- fpgeek 15y ago
  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.
  - falling 15y ago
    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.
objclxt 15y ago
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...
- falling 15y ago
  > 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.
bookwormAT 15y ago
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.

gravitronic 15y ago

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 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).

rogerbinns 15y ago
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.
- gravitronic 15y ago
  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 :/ )
  - rogerbinns 15y ago
    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.
    - gravitronic 15y ago
      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 15y ago

rogerbinns 15y ago

I am an Android developer. The simplest illustration of fragmentation is the devices I have on my desk: * 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.

abraham 15y ago
Is it even worth developing for 1.x with sub 2% market share?
- rogerbinns 15y ago
  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-compatibility.html 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 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 http://tools.android.com/recent/lintapicheck The development tools for Android are pretty nice, especially compared to the dross from older platforms.

Rabidgremlin 15y ago

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.

objclxt 15y ago
...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.
- natesm 15y ago
  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?).
  - king_jester 15y ago
    > 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 http://developer.android.com/design/style/metrics-grids.html
  - 15y ago

mrb 15y ago

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...

objclxt 15y ago
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.
rogerbinns 15y ago
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 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/148427.aspx http://blogs.msdn.com/b/oldnewthing/archive/2004/06/04/14842... http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481... http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...

fpgeek 15y ago

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.

bookwormAT 15y ago

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.

cek 15y ago
"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-end-of-android/ http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...

weirdkid 15y ago

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.

rogerbinns 15y ago
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.