Measuring fragmentation in Android

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

falling3• 14 years 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.

bookwormAT2• 14 years 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.

gravitronic3• 14 years 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]. 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).

rogerbinns8• 14 years 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.

gravitronic3• 14 years 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 :/ )

rogerbinns8• 14 years 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• 14 years ago

Is it even worth developing for 1.x with sub 2% market share?

rogerbinns8• 14 years 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-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.

Rabidgremlin4• 14 years 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.

objclxt3• 14 years 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.

natesm2• 14 years 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?).

Rabidgremlin4• 14 years ago

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

masklinn3• 14 years ago

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

Rabidgremlin4• 14 years ago

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

mrb6• 14 years 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...

objclxt3• 14 years 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.

rogerbinns8• 14 years 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

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

mrb6• 14 years ago

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.

codezero• 14 years ago

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.

mrb6• 14 years ago

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.

user2634• 14 years ago

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.

mrb6• 14 years ago

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.

cooldeal• 14 years 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...

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.

jsz0• 14 years ago

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.

mrb6• 14 years ago

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.

fpgeek2• 14 years 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.

bookwormAT2• 14 years 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• 14 years 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...

weirdkid• 14 years 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.

rogerbinns8• 14 years 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.

Measuring fragmentation in Android

Related Stories