

Measuring fragmentation in Android - AndrewDucker
http://pxldot.com/post/18281312362/android-measuring-stick

======
rogerbinns
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
Is it even worth developing for 1.x with sub 2% market share?

~~~
rogerbinns
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...](http://developer.android.com/resources/articles/backward-
compatibility.html)

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.

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

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

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

~~~
rogerbinns
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/2004/06/04/148427.aspx)

[http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481...](http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx)

[http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...](http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296.aspx)

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

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

~~~
mrb
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!

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

~~~
rogerbinns
> 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...](https://plus.google.com/105051985738280261832/posts/AzwMc3pSDUU)

> 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/util/DisplayMetrics.html)

[http://developer.android.com/reference/android/view/Display....](http://developer.android.com/reference/android/view/Display.html)

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

------
bookwormAT
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
_"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...](http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the-end-of-
android/)

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

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

~~~
natesm
Marco Arment does it pretty regularly: [http://www.marco.org/2011/11/30/more-
ios-device-and-os-versi...](http://www.marco.org/2011/11/30/more-ios-device-
and-os-version-stats-from-instapaper)

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

