Android Fragmentation Visualized

One of the annoyances I've had with Android, from a new consumer's point of view, is that it's presented as this monolithic OS that's the same across every phone. But once you do the research, you find that it's really not. Except for the Nexus line, there really isn't a "Google Android" experience. When you buy an Android device, you're really buying HTC's, Samsung's, Amazon's or Motorola's Android. Every device has different capabilities. Some ship with different Google services out of the box, others ship with their own internal apps. Google's Android strategy is that every manufacturer can make their own Android shell, without placing any requirements on the vendors as to what version of Android they're using.

It's a great thing that there's all this choice for the devices. It's a great thing that Android allows this kind of freedom. But it's led to a lot of issues for Google and for developers.

The problem that Google has is that they've effectively lost control of Android. They can't force manufacturers to use the latest version of Android. So they're left with situations like this, where the vast majority of Android devices are running an old version of the OS, and will never be updated to the newest version, because the manufacturers just don't want to[1]. So the result is that they have to support around 4 different codelines at the same time(ICS, HC, Gingerbread, and Froyo).

It's a problem for developers because your display code might not look right on a new device with a weird screen resolution. Or you might need API calls that are only in 4.0, which would lock you out of 90% of the devices right now.

No, the alternative is for Google to exert control over the device manufacturers and state that if they're going to be using the Android OS, they need to support and update their devices to the latest version for at least 2 years after the phones are released.

[1] There is a good economic argument that patching phones that are 18 months old with 24 month contracts about to be up just doesn't make sense, but honestly, it comes down to that the manufacturers just aren't willing to do it.

I don't think so. Even desktop OSes are not ready for such vast differences of today's hardwares.

Desktop-PC usually have approximately 100dpi screens, so the OS and the app generally don't consider dpi differences. So, if you've ever got a high dpi screen for Windows, you'll see the icons are frigging small.

Whereas, on mobile platform, we have screens ranging from 80dpi to above 300dpi. Android take dpi differences into account in the first place, to make sure, a same icon have almost same size on different dpi screens. It's a start.

I much doubted Microsoft or Apple would deal better with 'retina' desktop-pc coming in. Real trouble have just begun...

I'm not defending it, I'm explaining it.

Google has created an open ecosystem, and these are the natural consequences. Google can't "do something about it" because of the open terms of their licensing.

>Diversity of hardware and software isn't an inherent boon, it's just something that brings its own benefits and drawbacks.

Absolutely. Also, fragmentation is more of an issue in Asia where there are literally hundreds of cheaper variations of the same phone with different Android versions, screen sizes, memory, etc.

Right, the problem is with the Google Market, Amazon Market, et. al. It's not with Android as a platform (or operating system).

The problem is that Google copied the "App Store" idea for software distribution that Apple created for their iPhone. Instead, they should have gone with the same idea that Linux distros use: The product vendor is responsible for distributing the software for the product. That would look completely different from what we have now, but it would be a more natural fit to what Android really is.

Also, you could have made your point just as well without the ad hominem.

Add to that the fact that every device has a different processor model, gpu, and most of the software on the device is locked.

Your blog post blames a bug on Android fragmentation, but it sounds like it was your fault. You were not calling Environment.getExternalStorageDirectory(), which is the portable way of accessing the storage area where users saves file via USB mount.

On fragmentation, your blog post is exactly backwards.

You're calling out hardware fragmentation, but that's exactly the fragmentation the consumer wants - they see it in the store and pick it (via form factor, price, etc.). Beyond that, Android couldn't rein in hardware fragmentation without being something utterly unrecognizable. On Android dealing with hardware fragmentation is your job, just as it is in the desktop/laptop/netbook/... world.

Software fragmentation is the fragmentation consumers can't see and, generally speaking, don't want. And that's the fragmentation that is often preventable, as CyanogenMod's porting success demonstrates.

I don't think it is that simple. In Asia, which is ground zero for non-Google Android devices, fragmentation is certainly a problem, but the absence of fragmentation would have been far worse. Without fragmenting an open-source Android, manufacturers just wouldn't have been able to make and sell the cheap smartphones Asian developers are targeting.

Not sure why downvoted this is certainly the biggest thing Google can do to help alleviate fragmentation.

Of course it does run into two opposing aims:

(1) "cracking down" on the carriers at a time when Microsoft is literally throwing cash at them in an attempt to buy market share may by counterproductive.

(2) shipping os updates independently of carrier ui layers can break major ux or, even worse, crash the whole device.

What else could Google do? Well they could keep their major vendors in the loop instead of just dumping the new code on them after each nexus launch. I mean ICS launched in October but because of the development time frames involved many new handsets launched in the last couple months still shipped with Gingerbread.

How about this: if you're an Android branded product and decide to make a substantial UI layer modification you need to give google the source code and a team at Google will work to keep your differentiation layer working with updates.

> They really need to structure the OS so that the core components can be updated independent of the vendor ones. Then just ship updates regardless of what vendors do.

Except that won't work because what vendors do is modify core system components. Network stacks, audio/video codecs, system themes, etc. are all things changed by carriers and manufacturers for a variety of reasons.

There are two core reasons why Android OS updates are slow to roll out:

1) there is no profit motive to upgrade phones that have already passed their prime retail lifespan

2) modifications made my carriers/manufacturers are not simple and often have dramatic consequences for how the phone and apps on the phone behave

For companies like Microsoft, there is a profit motive to updating released software and selling larger OS upgrades at a price. For Linux users, the onus to upgrade comes from the users themselves, much like how there are those that choose to install custom ROMs on Android to get those advanced features.

Regardless, the fact that you can create an Android app that runs on so many hardware configurations is extraordinary. The downside to the popularity is that its likely your app won't run on every hardware configuration, so the question is how will Google mitigate that problem?

What a terribly obvious misnomer.

1. OEMs deserve 90% of the blame for being slow. CM is proof that OEMs are absurdly slow at updates, almost surely because they put absolutely no priority on supporting old devices. People blame Google because OEMs are greedy and lazy and are more interested in making the next buck than support an already cashed-out device.

2. Building a ROM for a phone is wildly different than adding hardware support to the Linux kernel or bundling drivers. Number one, because that is flat out impossible to do on mobile devices due to reasons that I only understand as "component manufacturers have tight control of software radio components", to the point that it makes it nie impossible for Google to distribute everything to make complete images even for their own Nexus phones.

3. OEMs over customize because they have access to the source code. They can do >= 90% of their customization using stock Android and just change what ships by default, but because they have the source, they tear into it and modify every last piece. If you don't think this would happen if OEMs had source for Windows, you're crazy.

Diversity is all well and nice, but how do developers possibly test against all those configurations? If you don't test - how do you ensure that as low as possible a percentage won't return your app, and ding your ratings simply because their phone has issues with your software?

Google needs to do more work to make software development and testing easier - as an end customer I don't want the pain of having to guess if the software I buy is or is not going to work.

>Maybe, but it would have to be mind-blowingly-differentiated. Can't find any proof points of Google doing that in the past, so have to assume it won't happen in the future.

Right, because Android itself doesn't meet that exact specification? A completely free operating system that is enormously huge on hundreds (thousands yet?) of different devices that anyone can build and distribute without royalties? It literally changed how smart phones exist and has put them in the hands of people that would never otherwise own a smartphone.

If you want revolutionary, check out boot to gecko. Even cheaper phones, more transparency, all open standards.

See what you wrote though ? "As vendors .. start pushing new models".

There seems to be this acceptance on the Android platform that in order to get the latest OS you basically have to buy a new phone. It's quite extraordinary.

Yeah, I'm not up to speed on Android. But, so, that only accounts for 3% of the users. It still means only %5 are on ICS, and the rest are basically on 2.3.

So the process for developing a new iOS app today is:

    1. Download latest SDK
    2. Develop for iOS 5.1

For Android, it seems to necessarily be:

    1. Download latest SDK
    2. Develop for Android 2.3

As a consumer I agree with you. As a developer, any frustration I have with the frag... ah diversity of Android is more than offset by the greater potential that it offers me.

Thanks! The data is killer, btw.

I too would be thankful for that. Sometimes, simple histogram is the best way to show something. And while you're at it, I think that cumulative version chart would be interesting for readers as well.

Even now, lot of carriers are pushing cheap phones with Android 2.2 or even 2.1 and while for better known devices this can be fixed with CyanogenMod, the state of Android versions is still bad.