Android's Overblown Fragmentation Problem Revisited | Hacker News Reader

Android's Overblown Fragmentation Problem Revisited

nickbradbury.com

49 pointssendhilp45 comments

I've found that the much more annoying and difficult to deal with fragmentation bugs are carrier specific. You will find things like Samsung has changed how you launch the default browser from your app or HTC doesn't follow the spec for getting an image from the camera. These are the kind of bugs that drive me crazy.

My current project runs a test suite (as well as some light adhoc testing) on 6-7 devices (across screen densities and carriers) and that seems to catch most of the issues without spending $20k on a device lab. (We use the excellent Spoon library by Square: http://square.github.io/spoon/)

Screen sizes are not an issue for anyone that's shipped a non-toy app. API levels are not so bad - though you will find yourself using the Support Libraries even in cases when they shouldn't be needed.

BTW: Android provides a weekly report of OS/screen sizes etc that access the Play Store: http://developer.android.com/about/dashboards/index.html Use this (not a random blog post) to make informed decisions for your clients on your minSdkVersion.

Now if you want to talk about a real headache for Android developers, let's talk about Fragments - not fragmentation :)

Many comments here can be summed to “I am frustrated because Android is fragmented and I may not be able to target all one+ billion android devices if I code for a week”.

No problem here though, if you think 1+ billion users don't deserve a few dev hours, you may as well code for another platform. Same goes if you think targeting anything less that 1+ billion users is problematic.

As far as OS version fragmentation, iOS 6 and Android 2.x are both running on approximately 20% of their respective ecosystems. But for some reason iOS developers are more ruthless in cutting off older devices. I recently convinced a very insistent company to drop Android 2.x support after I pointed out that they had already dropped iOS 6 support without giving it a second thought.

So, now you support one version on each platform?

One major version with several minor versions. iOS 7.0 and 7.1, and Android 4.0 through 4.4.

I guess more iPhone users have the opportunity to upgrade for free than Android users.

iOS 6 was released fall 2012, the last release of Android 2.x was in 2011. A better comparison would be Android 4.1 Jelly Bean to iOS 6 - that's 35% of the android base on ancient versions (pre 4.1, relative to iOS's 4%)

cf. http://en.wikipedia.org/wiki/Android_version_history#Android... http://en.wikipedia.org/wiki/IOS_6 http://developer.android.com/about/dashboards/index.html http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-d...

I still maintain that fragmentation is less of an issue than is commonly believed...I think the biggest problem is that unless your app is relatively new, you probably have to continue supporting Android 2.3. Making sure your app works on that ugly, buggy OS is a massive pain.

I gripe about having to support an OS that Apple shipped in Q3 2012. Semi-mandatory Android 2.3 support is a fragmentation problem, especially when you mix in all the crazy shit some handset makers and carriers have done to 'improve' Android.

See, for instance, http://techcrunch.com/2012/06/02/android-qa-testing-quality-...

>Semi-mandatory Android 2.3 support is a fragmentation problem

Only for spoiled iOS developers.

I used to develop for Windows, starting in pre-1995. Want to talk about fragmentation? With dozens of video cards, each with their own custom APIs for doing anything that standard VGA couldn't handle, dozens of sound cards with varying levels of support for the de facto standard(s), memory configurations from 128k through multiple megabytes, BIOS variations, and even CPU bugs in AMD or other non-Intel chips...and then tons of software that might be running on top of your app (drivers and such)? THAT was fragmentation.

Windows 95 and later (specifically after DirectX was introduced) reduced THOSE problems significantly, but new ones surfaced, anti-virus and firewall packages being the worst, though some video cards still have bugs that break things randomly.

You think having to support 2.3 qualifies as a problem? JUST having to support 2.3 is a dream compared to what we used to have to deal with. The compatibility libraries -- especially the latest versions -- do a great job of making apps work everywhere. And if you're using OpenGL, you have even fewer compatibility issues to worry about.

Get off my lawn. ;)

From my point of view its management handling thats my issue. When I say week to update iOS, 3 days on the html version, 3 weeks for android, I get a massive push back... "android in one week".. "OK an extra few days for testing, but we need these out now"

Then I start to get really annoyed at the level of shit of I have to support for Android and the backwards and forwards on testing and just seriously wish the company didn't support it all.

Actually TBH, I only took up looking after the mobile suite as a learning thing. And what I learnt is I'd rather be doing other forms of software (almost exclusively due to time pressures and android). The experience has been less rewarding that other forms of development I've done.

I'd never work on Android products again without a proper team (project manager, QA etc...) so someone else could fight the battle of more development time every iteration instead of me.

With a TAM measuring in the hundreds of millions of devices for each platform, I'd much rather work with the one that requires less self-flagellation. But, to each their own :)

Spoiled by having lower costs and so being able to devote more resources to the product for their customers?

Isn't that simply a logical consequence of the GP comment? Presumably the downvotes indicate a dislike of the state of affairs.

The people who point out "90% of Apple iPhone users are on the latest OS version! Android sucks because not everyone is on the latest OS!" don't realize (or care) that Apple just bundles up a bunch of userland components and calls it an OS update. Nearly everything but the kernel is auto-updated to the latest version on all Android devices, even if they're several OS versions behind.

The discussion should be around "What is it that people without the latest hardware / OS version can't do?" not "What number does your phone say under OS version?"

Nearly everything but the kernel is auto-updated to the latest version on all Android devices, even if they're several OS versions behind.

This benefits users, but not developers. Developers still need to code and test against old API levels.

The overblown problems that the Apple-zealot bloggers are always bringing up are 100% user issues, not to do with developers.

This is only partially true. Google has started distributing some APIs automatic updates as well via Google Play Services.

http://developer.android.com/google/play-services/index.html

These features are made available on older releases of Android.

If almost everything is auto-updated, why do developers need to test against old API levels? Wouldn't the frameworks be updated as well? Or are the frameworks covered by the "nearly" qualifier?

Wait some bugs are security issues and cant be patched unless a full upgrade is performed so no the discussion is how do we keep people protected when they cannot upgrade the phone. I apologize if I am missing something but it my understanding Android relies on the carriers to push the updates, correct?

Also "latest version" in iOS means roughly yearly, but roughly twice-yearly for Android.

Around our shop (we have several PhoneGap projects) we frequently refer to Android browser as the IE of mobile. (and we're referring to IE6-8). Its crazy how many really key parts of HTML & CSS don't work on various versions of Android browser that are still very much alive and well, including some that worked on 2.3 and stopped working on 4.0 or 4.1. We basically have to turn our apps into static pages for anything < Android 4.2.

For me it's Mobile Safari. Everyone on the platform is forced to use it and it's many, many horrible bugs.

I think a subtle problem with the android fragmentation is that it is not going to get any better. As time goes on there will be more devices running more android versions.

While Google's cheap handset initiative embodied in Nexus 5 will ameliorate problem a bit by giving people incentive to upgrade, it is not nearly enough. I would like to see Google do more to address growing complexity of fragmentation.

We manage fragmentation between computer systems since the dawn of computing.

I really don't get why some people make a huge fuss about it on Android.

I do not dispute that. I agree that it is a manageable situation. What I was pointing out is sheer scale of it. Given enough effort it is certainly possible to make any app to work on all android platforms. However, there are millions of apps in the play store and it is not possible to make them all to work on every device. I just think Google should be actively working to make that task easier on developers. For example getting cloud emulators or even physical devices available to developers for testing their apps against with automated framework.

How is that any different to make it work on the hardware configurations of all PCs ?

I agree that in general situations are quite similar, however there are few differences:

1. PC never had a singular point of access to nearly all available applications. Play store makes it easy to download/install or distribute a new application making it instantly available to large amount of people.

2. It is fairly easy following a tutorial to create a new mobile app. This combined with 1 makes it easy even for relatively inexperienced people to make apps that reach wide audience.

3. Rigidity of mobile environment. On PC if something goes wrong you have a chance to figure it out and correct a problem. This is much harder on mobile, often times only thing you could do is complain to the developer.

4. No POSIX. On PC if you need an app to work across a wide array of software and hardware configurations POSIX got your back. Granted, this is a weaker point because it would work only on a limited set of operating systems that are POSIX compatible.

5. You can install almost any app from play store on nearly any android device. You can't install mac os app on windows.

1. Magazines with tapes, floppies, CDs, DVDs

2. BASIC, Logo, Hypercard, ...

3. Fail to see the difference

4. POSIX only covers a tiny bit of OS portability and even POSIX leaves the little bit it covers with lots of vendor specific behaviors

5. You can install any Mac app on any Mac, any Amiga app on any Amiga, any PC app on any PC, ...

6. The 8-bit microcomputer madness. How many pieces of software were ported to half a dozen or more platforms?

It's not. Except Windows has 95% of the market and the Mac had 5% of the market. So even though it's easier and cheaper to support a Mac app, the market is so much smaller it's still not really worth it.

Compare to mobile where iOS market place was leading, it didn't make a lot of sense to spend more effort on the smaller market.

Now the Android market is about equal, you are still spending more effort to make the same money.

> Except Windows has 95% of the market and the Mac had 5% of the market.

Except you are forgetting, screen resolution, processor speed, graphics card, sound card, co-processor, printer type, scanner type, microphone, webcam, harddisk, network card, modem, ...

Way back in the day it was pretty common for people to swap out pieces of a system (not too much today except for gamers).

Your system needs a bigger screen? Get a bigger monitor and/or graphics card. Need a faster modem? Buy one. Need a camera? Add it.

Go upgrade the graphics chip in your Android 2.3 handset. Oh wait...

That doesn't have anything to do with the complaint about Android's fragmentation.

you're pointing out 'fragmentation' in the windows market because of all the varying hardware, and it seemed you were saying it was equivalent to the android world. it's not, because you generally could change hardware on a windows system, but not on an android device.

Quite the contrary.

I am pointing out that fragmentation in the COMPUTER HARDWARE and SOFTWARE is normal and exists since computers are among us. Windows market is a tiny spot of the COMPUTER HARDWARE and SOFTWARE around the world.

Any good developer learns to deal with it instead of writing posts whining about it.

Plus iOS which is oversold as not being fragmented has different set of API support depending on iOS/handset/tablet pair set.

But... it wasn't ('a tiny spot') at the time. And good developers didn't 'deal with it' so much as people simply upgraded their hardware - computer stores routinely upgraded people's modems, graphics cards, sound cards, monitors, etc. Of course, some software would run with lower quality hardware, or try to run without certain features, but people mostly upgraded components (or entire systems) to be able to run newer software. We do that today somewhat - buying new systems - but no one reasonably tries to upgrade the CPU in their android smartphone - they just get a new one.

We're either talking past each other or have a vastly different sense of the issue we're talking about (or both).

> We're either talking past each other or have a vastly different sense of the issue we're talking about (or both).

My point is that developers always had zero control over the hardware/software configuration of the systems being targeted, it has nothing to do with the ability to upgrade.

Lets say one is coding an application for Amigas. There are 500, 600, 1000, 1200, .... series.

There is zero control over which type of monitor/TV and external devices the respective users have attached to their systems.

There is no concept of device drivers as of today systems, most need to be provided by the application writers themselves.

Again, zero to do with upgrade capability rather with the diversity of the installed base.

Well, no, Android market share is not equal to iPhone. It's much, much more.

The problem is the hardware AND software targets for mobile devices is still growing and evolving rapidly.

Rapid, very different hardware variants- Screen size, cpu power, GPU power, storage mechanisms. Software: 3d Apis, third party Apis, if you want to take advantage of a new framework you may not be able to because of people either unwilling to, or not able to upgrade.

It's completely different from the PC world.

I think the main issue with fragmentation is dealing with 2.3 (as the article mentions). Now that that's going away it's getting much better very soon so I can't agree that "it is not going to get any better". The latest Android project I'm working on will only work for ICS and newer and I've had very few cross-platform issues (two minor issues that I can think of).

If you have used Android's Camera APIs, you would know how bad the fragmentation is. Had to fix various framerate/preview size issues on many Samsung S3/S2 variants because Samsung have their own private camera parameters when you don't use the default MediaRecorder and just try to process the frames yourself. (I work on recording for Vine)

I still haven't popped my mobile development cherry because of how fragmented the development experience is on a few levels. One, the pain of having to develop twice for iOS and Android and Blackberry (if someone requests it). Two, the pain that comes with fragmentation in each specific platform with Android being the worst.

Because the app store is a race to the bottom, I don't want to create an Android app that works well only on the latest devices and have someone else copy it and make it available for all other platforms. This fear is enough to keep me from executing any ideas on the mobile platform.

I still focus on web applications and HTML5 because eventually everyone will be on a phone powerful enough to use it.

Cross-platform development of games is trivial (C/C++ and OpenGL work on all of them).

Cross-platform development with PhoneGap or similar is also trivial, and isn't hard to make work on (almost) all devices.

I have been looking at Intel XDK, I think it hits my pain points.

PhoneGap I'm not so sure about because people seem to be walking away from it and writing native applications instead because they were frustrated by performance. Now, I'm sure there's success story.

Just target Android 4.0 and higher, and you've got over 80% of Android devices. Don't worry about earlier versions at all.

Reply on news.ycombinator.com