

Android's Overblown Fragmentation Problem - breischl
http://nick.typepad.com/blog/2012/05/androids-overblown-fragmentation-problem.html

======
AntiRush
Another area that can be quite tricky is games.

Most (but not all) Android phones being produced today support OpenGL 2.0 -
even so, there are lots of tricky differences.

The obvious one is different screen sizes and resolutions. This can be a
challenge, particularly for 2D games. You need either different versions of
artwork, resolution independent artwork (through 9png, vector graphics, or
something else), or to accept that your art is going to be stretched on most
phones.

Additionally, different combinations of GPU/screen size have vastly different
performance characteristics. A phone with a 720p screen might very well have
the same GPU as a phone with an 800x480 resolution screen. Guess which one
performs better? This requires a lot of testing, as the stereotypical "low end
phone" might actually perform better than the latest and greatest with a giant
screen.

Phones also differ, and sometimes greatly, based on the graphics chip/driver.
HTC phones often don't preserve framebuffers in the way most other
manufacturers do.

There are many more: non-po2 textures, compressed texture support, different
context preservation behavior based on phone and OS version.

Games may not be the stereotypical application here, but they're a huge part
of the market, and Android fragmentation has made developing performant, good
looking games much more of a challenge than on iOS.

~~~
ajross
I'm pretty sure OpenGL ES 2.0 (pedantry: not at all the same standard as
OpenGL 2.0) was a platform requirement for everything from Eclair (Android 2.0
-- the Nexus One) forward. I'm sure that factory-new Android 1.x devices still
exist in the market somewhere, but you'd be very hard pressed to find one.
Note that the original iPhone and 3G didn't do GLES2 either, so the platforms
got the support at roughly the same time.

The bit about pixel-perfect art matters to some, I guess. PC game vendors have
been doing resolution-independent games for decades now, so it's hardly a
killer. But if you have to have it, then you're stuck with the iPhone (not
even iOS, obviously, as you'd have to chuck iPad support).

And the rest is just saying that "OpenGL is hard". Yes: if you want to code to
_precisely_ the extension support and bug-for-bug quirks of one GPU
(presumably the PVR SGX 5xx in your case), then it's easier to support just
that phone. Duh. But that seems like bad practice to me. What if Apple goes
with Mali or Tegra3 for the iPhone 5?

~~~
Claytonious
It's deeper than "OpenGL is hard." Right out of the gate, you are hit with the
one-two punch of different texture compression formats being supported on
different devices combined with a maximum APK size on Google's store. The only
standard Android texture format with compression is ETC which doesn't support
alpha. So right at square one, if you want to use compressed textures for
maximum performance and resolution, you have to release 3 separate APK's with
a different supports-OpenGL-texture tag in each manifest. One for DXT, one for
PVRTC, and one for ATC. Or dynamically download megabytes of textures after
detecting which GPU you are running on.

That's a sharp contrast with iOS's unified, simple developer story: all PVRTC
without any maximum app size.

~~~
ajross
That's not iOS's story, it's Imagination Technologies' story. The story from
Apple will change the moment they ship a device on someone else's GPU. If this
is something you expect to rely on, you're in the position of someone writing
Altivec code in 2005.

But yes: texture compression formats and hardware support are a terrible,
terrible mess. Happily I believe the early patents on S3TC are set to expire
soon.

------
nextstep
So Android's fragmentation problem isn't that bad for developers if they're
used to working on an even worse platform (web developing)? That's a terrible
argument. There is always something worse. That doesn't mean Android is any
less fragmented.

~~~
rabidsnail
Android fragmentation is worse than web fragmentation. On the web one only has
to test on 4 browsers x two operating systems, as opposed to dozens of phones
x several os versions x several carriers.

~~~
ajross
You're slipping your terminology here and achieving some pretty clever spin:
It's only four browsers if you don't care about Opera users. It's only two
OSes if you don't care about Linux users. If that's your standard for support,
then why not look solely at the successful Android devices, which takes you
from "dozens" of handsets to maybe seven at most, which is less than the web
world.

And of course the 4/2 argument is bunk anyway. Web developers test ever major
version of every browser (especially with IE) and every version of every OS.
So for example it's {XP,Vista,7} cross
{ChromeN,ChromeN-1,IE7,IE8,IE9,FirefoxN,FirefoxN-1} plus {Lion,Snow
Leopard,Leopard} cross {Safari,ChromeN,ChromeN-1,FirefoxN,FirefoxN-1}, etc...

You can't have your argument both ways, basically: either the small market
platform variants matter or they don't. If they don't, Android support is
easier than the web by a significant margin.

~~~
joshstrange
I disagree. Testing is STILL much easier for web development, the android
emulators are no replacement for the real thing. Yeah, if you want to give me
the top 7 Android phones then yes, development becomes easier (I'm sorry but
still no where near as "easy" as it is in the world of web development). We
normally will test Win/OSX and the latest FF+Chrome and then IE7/IE8/IE9/Soon-
IE10. This in total means testing 6 different combos (No IE on OS X and only
test FF/Chrome in one OS). I might throw the site in safari just to double
check but since it runs on webkit I usually can trust that if it works in
Chrome it will work in Safari.

At the end of the day we have to much less checking in web development than we
do in mobile because while browsers are different that are more alike than
they are different. That cannot be said for Android/iOS, they differ down to
their very core and most cross-platform attempts fall hopelessly short of a
usable app.

~~~
ajross
This seems to be a digression. The point isn't that the "task" of development
is easier than web development. Of course it's not, that's ridiculous. It
might be done with fancy Java IDEs, but it's still embedded systems
development on physically disjoint hardware.

The point was that the added cost to development due to platform
incompatibilities is less than it is in the web world. And I think that's
largely inarguable. Where is the list of Android incompatibilities that is
anywhere near as complicated or exhaustive as <http://caniuse.com> for
example? People in this thread are having a lot of trouble coming up with any
specifics at all, in fact. Mostly just a list of apps that break somewhere; no
one seems to actually remember any real bugs or workarounds.

------
ecoffey
Well it's also consumer perception. For Android I paid money for the phone
itself, for a calling and data plan, and then for the apps (sometimes). So
after putting down money and things not working right, yes that angers me.

But for web apps? The browsers are free, the apps are (usually) free, and
there is an _expectation_ of approximate user experience on the web. On phones
the standard is much higher.

That's at least the way I feel about it (and will be switching to an iPhone
away from Nexus S because of all those reasons; my OS X / iOS devices always
feel more "real" than my android phone).

~~~
fragsworth
> For Android I paid money for the phone itself, for a calling and data plan,
> and then for the apps (sometimes).

Did you not pay for your computer itself, an Internet plan, and then for
software (sometimes)? How is the Android experience any different?

~~~
ecoffey
In a strict sense I have a ton of different browser options on the same piece
of hardware, so if one app doesn't work in Safari say, I can use Chrome or FF.
Annoying? Yes, but not world shattering. In a sense you're correct, I've had
to invest money to even get to the browser, but I think this difference is
more emotional / psychology than anything else.

In a sense the "browser" is a different part of the overall experience.

I know that I've become accustomed to have different expectations of web apps,
because they _are_ web apps.

I feel like when it comes to more native apps you have fewer excuses for
something being wonky or broken.

------
runjake
I'm not sure the "overblown" fragmentation problem is about the developer. I
thought it was about the end user.

Sure it's somewhat difficult to develop and test Android applications due to
fragmentation, but I see the bigger problem being the end users with Android
devices in their hands that can't run apps because their particular device or
their new, but ancient build of Android isn't supported.

What Color? is an example of this. It doesn't work on the Galaxy Nexus. Who
knows why. The Netflix app was another example, for at least a while.

And who knows if it will ever be supported, because only $x number of people
own that device, which is one of hundreds available worldwide at any given
time.

~~~
ajross
This app?:
[https://play.google.com/store/apps/details?id=jarcikon.whatc...](https://play.google.com/store/apps/details?id=jarcikon.whatcolor&hl=en)

Seems to work fine on my Galaxy Nexus, though I've never heard of it before
and maybe support was recently added. And to be fair: this (a camera-
integrated "what is this color?" tool for colorblind users) is a _really_
obscure app! The Netflix example is AFAIK wrong; I don't think it was ever
"unsupported" in ICS, but maybe I'm misremembering.

Are there any real-world examples? I mean, sure: occasionally you see an app
that has bugs on one handset or another, and sometimes those go unfixed. But
to pretend that this is a serious problem for "end users" is vastly
overstating the case.

~~~
gcp
Chrome (doesn't work on pre-ICS). Grand Theft Auto 3 (and most games - don't
work on particular devices due to graphics). Firefox Native (only supports
ARMv6 devices in unofficial builds)

~~~
ajross
The Chrome bit misses the point entirely. _Of course_ some software requires
the latest version of the OS, if it didn't, there would have been no need to
release the new version of the platform. You might as well talk about how
terribly fragmented iOS is because Siri doesn't work on the iPhone 4.

The GPU thing is legitimate. If you let the market differentiate on graphics
performance then software vendors will choose to optimize their platform
compatibility in ways that don't include everyone. That's "fragmentation",
though I'm hard pressed to see how you avoid it without making everyone code
to a single core SGX 540 like iOS does.

And Firefox ships an app that doesn't support the native ABI of the platform
(which, to be clear: has a _slow_ ABI precisely to _avoid_ fragmentation. iOS
has the same backwards-compatible floating point issue, btw). Again, I don't
see how preventing software vendors from making these decisions is helping
anyone.

------
mgkimsal
We've spent 10+ years on the web trying to educate end users that things will
_not_ be pixel perfect across webtv, ie3/4/5/6/7/8/9, netscape 2/3/4,
firefox1-12, opera, chrome, safari on linux, mac, windows, on 10"-30" screens.
Slowly, over time, it seemed to work.

"This rounded corner on ie7/winxp doesn't look exactly the same as the rounded
corner on my iphone4!" isn't the type of complaint I hear from clients any
more, but font renderings, aliasing, shape of rounded corners, etc are all
things I've had to deal with in the past.

We're now entering mobile devices/tablets, which will bring with it its own
version of the same stuff. It was easier to tell someone "that's _netscape_ ,
this is _opera_ \- they're different, and will look a little different*" than
it will be to say "this is android, and that's android, but they don't work
the same".

~~~
gauravk92
Sure it's not an issue if you think you have to support android. When in
reality you just have to support the iPhone, and it doesn't have these issues.

Android support is helpful but not neccesary, like supporting IE alongside
Firefox a few years ago. Sure people use IE more than any other browser (now
Chrome, yes!), but that doesn't mean a lot of IE users are going to use your
website in the first place.

IMHO that applies to android today, iPhone users are way more likely to buy
your service in the first place so you should focus on them. No need to leave
android users hanging, but clearly the platform doesn't warrant anyone's sole
focus so much as basic support.

~~~
thechut
It's tough to tell if you are talking specifically about web apps for browsers
or the platforms themselves. But in either case your comment is short sighted.
Android has over 50% of smartphone market share, and that's only going to
increase. Android support and Android versions of apps should be standard for
companies and startups going forward.

------
tsunamifury
I design and support apps for iOS (Tablet and Phone), Android (Tablet and
Phone), Blackberry (Tablet and Phone), Windows Phone 7.5, and various J2ME
(Nokia s40 etc).

Android is not the very worst one to support (that would be blackberry), but
it is the worst within its own ecosystem. As a designer it infuriates me to no
end to never know the Dimensions, PPI, or general experience of any given
user. It makes any refined UI design nearly impossible. While I can't create
great experiences on specific devices, for Android I have to make glorified
web apps at best.

If I were a Android customer, I would be irritated that my platform has
significantly handicapped my apps.

~~~
king_jester
> As a designer it infuriates me to no end to never know the Dimensions, PPI,
> or general experience of any given user. It makes any refined UI design
> nearly impossible.

This doesn't make sense to me. Android gives you all the tools you need to
scale a UI to different types of screens, so why would not having a set
dimension/resolution/PPI value make it hard for design? The added challenge is
thinking about how your UI may work gracefully on smaller or larger than
expected screens, but those challenges can be overcome as they are on other
platforms like the web.

~~~
roc
I've been told the concept of scaling a UI is akin to the concept of "write
once, run anywhere".

That is, it works fine in theory. It just hasn't ever worked as advertised in
reality. And trying has often generated more pain than it's saved.

It's worth noting that much of modern web design moved to a place of fixed
minimum widths and white-space taking up the remainder. Responsive design
promises to change that a bit _toward_ scaling UI, but thus far is just a
mechanism by which designers can incorporate a few hand-tuned minimum-width
variants.

~~~
obviator
Right from the start Android has been designed with a form of Responsive
Design. With scalable XML layouts, and selectors to choose which layout is
loaded for different DPI devices, one could argue that even early versions of
Android are at least as design-friendly as modern HTML5.

That's not to say there aren't challenges. But the whole point of Android was
always to create an industry standard for a wide range of devices. This
requires - by definition - support for a variety of screen sizes, DPIs,
hardware features, etc. When most people talk about fragmentation as a
negative point of Android, they're forgetting what Android is. A common
platform, running on an unlimited number of devices. That's by design, not
accident.

------
sjhcockrell
The fragmentation is fairly significant, given that 85% of current Android
devices are still running 2.2-2.3.x versions of the Android OS--both of which
are now 2 years old.[1]

Four months ago, we were experimenting with a combination of PhoneGap and
mobile website versions of an app, and that was an unholy nightmare of bugs--
not because of the version of Android, but because of the custom UI that phone
manufacturers added on top of the stock OS.

We got three different Android devices (running 2.2, 2.3, and 4.1), and
debugging for presentation, rendering, and behavioral issues was pretty
painful. Two bugs that I can recall off the top of my head are:

* the "HTC Duplicate Input Bug", where the browser inserted a second <input> or <textarea> element on top of the original element in the DOM when you apply focus to a text input element and bring up the soft keyboard

* issues with heavy caching and cookie management that resulted in failed logins (depending on the user's device) and unpredictable rollout of new versions of CSS and JS

The problem with Android fragmentation is not necessarily that it's spread
across the number of devices and versions; it's that the phone manufacturers
have incentives to continue using legacy versions of the software (2.2-2.3x)
because they have already invested time and resources into building their
proprietary UI on top of them.

[1]: [http://developer.android.com/resources/dashboard/platform-
ve...](http://developer.android.com/resources/dashboard/platform-
versions.html)

------
radley
I think his argument is premature. His app is < 5k installs, he's only
targeting phones, he's still using the option menu (i.e. using an old sdk),
and his UI is simply an iPhone port.

Just from a UI perspective I'm not sure he has addressed: ActionBarSherlock,
black vs. white (or any?) Option Menu icons, portrait/landscape layouts (i.e.
sideways keyboards), and multiple layout folders (3x just for tablets).

He's confident now because the app is small & easy. When you get to ~100k
installs you start to encounter the niche users and when you're missing
something "critical" and unique to them you'll get a lot of 1-star drive-
bys...

~~~
guelo
Just exclude your app from those devices in the market.

~~~
radley
It usually takes the market a month or two to add new devices to the list. By
that time you'll already be nailed by users of a popular new device with an
odd screen. We went through that with the Galaxy Note. (Our solution was to
express ship one via Amazon.)

------
Terretta
As he mentioned, it may be overblown unless you're in video. The streaming
protocols don't get a lot of love (every 2.x.x version broke different bits of
streaming in novel ways) and codecs don't work across devices either.

(Also note other comments here about Color and Netflix apps.)

~~~
gravitronic
It's not just video. It's any time you step out of the sandbox of "simple
native UI app" that you start running into these differences.

~~~
gcp
I'm glad someone else said it.

I don't know how to put this more polite, but if _those_ are the only
fragmentation issues he's had on Android, his applications are either fairly
simple or they just don't have much users yet.

I don't have an opinion on whether it's worse on iOS (prolly not) or Windows,
but it sure _is_ a pain.

~~~
joshstrange
Couldn't agree with this more. Once a bunch of people start using your Android
app you will get buried under support issues. The company I wrote some apps
for will email me all the time saying X device on Y.Z version of Android
doesn't work... Most of the time it's just a dead end. Unless I get one of
those phones in my hands to test it or if it is spitting out an error code
that I know how to fix then there is no easy way to debug the problem. It's
frustrating as a developer because I WANT to provide the best experience in my
mobile apps but that is a very hard to do as the Android platform seems to be
in a constant state of flux with countless new devices hitting stores all the
time.

------
joshstrange
I'll agree that the web development scene is somewhat "fragmented" but I would
argue that Android's fragmentation is not only worse but harder to adjust for.

When coding a website and dealing with different browsers/capabilities/screen
sizes I can test all of the different combinations on my laptop. The times
when I need to test a site on windows I either get someone else to run QA on
it at work or I fire up a remote solution such as <http://browserstack.com>.
The bottom line is I CAN test all the combinations.

Now switch to Android. I'm sorry but emulators are NO EXCUSE for the real
thing. I have had code fail in an emulator and then work fine on the device.
The emulators are VERY slow and trying to run them on my Macbook Air (4GB RAM)
is next to impossible. iOS's Simulator is 100x better. (Emulator != Simulator)

I'm sorry but I would rather write websites all day and have to test on 4
Browsers Across 2 OS's then write one more app for Android.

------
jrockway
I disagree that fragmentation is not a problem. I work on the mobile
build/test infrastructure at Google, and fragmentation does cause us a lot of
extra work. We have to track down and maintain physical phones from each
vendor, and then we have to dole out time allotments for tests to run on each
phone. (And of course, each model of phone runs a different build of Android
for each carrier...) This is annoying because ideally we'd run tests for every
affecting change, but there aren't enough phones to do that. (We can and do
run the emulator for every change, but the emulator is a very optimistic
simulation.)

iOS presents is own challenges; running emulator tests for every change is
difficult because the build process is opaque and the emulator only runs on
Macs, which we do not use in production.

All in all, the tools that are available to mobile developers are extremely
primitive compared to what server-side Java developers get, and wasting time
fighting fragmentation isn't exactly helping.

~~~
joelhaasnoot
Hmm in your post I read "I work on mobile build/test infrastructure at Google"
and "tools that are available to mobile developers are extremely primitive".
So what are you waiting for? Pitch your ideas to your (relatively internal)
Android team...

~~~
jrockway
Yes, we do that :)

------
dshefchik
"It can be tricky to take advantage of features in new Android versions (like
ICS) while still supporting older versions (like 2.2)."

ummm...what was your argument again?

~~~
aguynamedrich
Tricky, but not impossible. The same as you would have to learn the API's and
general usage patterns of new features, you just have to learn how to use the
compatibility package or third party libraries like ActionBarSherlock to take
advantage of the most common new features.

That said, I don't fully agree with the OP's argument. Fragmentation is a very
real pain in a lot of subtle unexpected areas (mostly UI related).

------
mchristoff
I make a living off of Android, and I don't think fragmentation is overblown.
Sure, you can make the argument that the PC world has dealt with different
screen sizes and hardware specs for a long time, but at least MS was the sole
vendor of Windows.

As Android developer you have to deal with myriad of manufacturer and
community developed permutations of the OS - TouchWiz, Sense, Cyanogenmod,
MIUI to name a few. If you make a widget app like us, you not only have to
deal with HTC, Samsung, etc's launcher you have to deal with 3rd party
launchers too - ADW, Apex, Launcher Pro, GO, etc.

How about when HTC decides to break multitasking in favor of better battery
life?

[http://www.theverge.com/2012/5/16/3024854/htc-one-x-
multitas...](http://www.theverge.com/2012/5/16/3024854/htc-one-x-multitasking-
operating-sense)

Personally, I think it's a bit of a double edged sword. A lot of the issues
that make Android hard to develop good apps for make it a fun platform, ie the
ability to choose whatever launcher or rom you want. That said, you're kidding
yourself if you think fragmentation is not a major issue.

------
rdg
The problem with Android fragmentation is the impossibility of most developers
to reproduce device-specific bugs. Without physical access to one problematic
device it could be very hard or even impossible to debug bugs. There's only so
much you can do with the emulator. And most developers don't have access to
more than very few devices. If you're not a company, it's hard to invest in
all sorts of devices.

------
nalybuites
I think the fragmentation issue has bigger impacts in software consumption,
rather than software production. The fragmentation is really more of a symptom
than the problem. That problem is disparate hardware as a result of how device
manufacturers compete with each other. Instead of adding any value with useful
features (NOTE: the additional battery drain of 4G and lessened security of
using NFC are not features), they decide to manufacture devices using cut-rate
hardware. The hardware failure rate of Android powered devices is staggering
when compared to iOS devices. This hurts the user and it hurts the platform.
The user is left with a bad taste in their mouth, which they attribute to
"Android's fragmentation problem". Now, I'm not the biggest Apple fan and I
love the philosophy behind Android, but I find the crappy hardware a big
enough of a pain to deal with that I would rather use a device that's part of
a more controlled ecosystem.

------
fdr
I still can't read "The Economist" on Ice Cream Sandwich. I noticed it
silently went away the moment I upgraded.

Anecdotal? Yes. But until it is more or less unheard of (especially for an
application that "just" renders text and images), there is a fragmentation
problem.

"Ice Cream Sandwich" has been available for months.

~~~
jcromartie
> "Ice Cream Sandwich" has been available for months.

And only about 5% of phones have it.

Devs have to prioritize. Obviously, power-users are going to be up-to-date,
but the vast majority of customers are probably not affected. I would imagine
the customers of The Economist on Android are less likely to fit the power-
user profile than other apps.

~~~
fdr
> And only about 5% of phones have it.

This is a statement of the fact that seems reasonable.

> Devs have to prioritize. Obviously, power-users are going to be up-to-date,
> but the vast majority of customers are probably not affected. I would
> imagine the customers of The Economist on Android are less likely to fit the
> power-user profile than other apps.

This is a justification I entirely agree with. It doesn't mean that there
isn't a fragmentation problem that annoys customers.

I understand _why_ this is, there was never to be doubt about it. Just because
it is understandable doesn't get to the heart of my disagreement with the
headline: there is a fragmentation problem.

------
THEM
Price of testing on multiple flavors of web browsers: An internet connection &
a few virtual machines to run versions of IE/Firefox.

Price of testing on multiple android devices: Thousands of dollars to purchase
new phones without a contract.

------
aiscott
While the fragmentation such as it is really sucks for developers, I do see an
upside.

It's a grand experiment with many competing designs, all striving to become
the best and biggest (sounds like Osmos ;).

iPhone iterates down a closeted path. Innovation for iphone depends solely on
the creativity at Apple. And while that is nothing to sneeze at, if some
really left-field neato must-have innovative feature occurs, I think it's
going to be found on Android first.

~~~
taligent
Except that you miss the point.

PCs have been doing this for decades without having the OS fragmentation
problems. Why ? Because Microsoft allows OEMs to customise the experience
while still allowing them the ability to upgrade the core OS.

