Programmer’s Perspective: How Android’s Fragmentation Can Be a Good Thing

One of the chief arguments against Android and in favor of iOS in today’s mobile OS battle can be simplified to one word: fragmentation. I see that word thrown all over the place, usually padding walls of text written by an iOS fanboy who probably hasn’t the slightest clue what fragmentation really is. Isn’t that the problem with everything, though? People don’t know what they’re talking about.

First off, let me state my belief that yes, Android is fragmented. It is fragmented in the sense that it exists on a plethora of devices, all of which differ in screen size, processing power, and even the Android platform itself. It is fragmented in a way that enables it to reach a large population of consumers, from power users who rock the latest superphones to the average Joe who wants to keep in touch. It is fragmented in such a manner that it is able to adapt to almost any situation in which it finds itself. Yes, Android is fragmented, but not necessarily in a bad way. In addition, the few shortcomings fragmentation causes for Android are being quickly remedied by Google as of late.

I recently spoke with Jake Wharton, a developer for both Android and Web applications, who is perhaps best known (at least on the Android scene) for contributing various software libraries for use on Android, including ActionBarSherlock. I asked him specifically for his take on the manner in which the common masses label Android as fragmented, and whether or not fragmentation hurts or hinders Android developers and, as a result, consumers. It turns out that he shares a few of my views:

Fragmentation might be the most overblown issue with the entire Android platform and the primary arguments against it are actually some of Android’s greatest strengths. Iteration on any technology inevitably leads to two things: deprecating the old and introducing the new. How can an entire platform [that] exists in arguably the most competitive market of the past three years (mobile) stand to not innovate? The fact that Google has adopted Android and managed to create a rich, interactive, dynamic, and inconceivable versatile OS [with] roots [that] were based on a near clone of the BlackBerry OS is amazing. Having not done so would have left it in the dust of what is now iOS.

Indeed, Android’s fragmentation is quite possibly its greatest strength. As I said before, being able to adapt to a wide range of device configurations allows Android to provide a rich experience to an equally wide range of people.

Programmer's Perspective: How Android's Fragmentation Can Be a Good ThingMoving on, let’s discuss the device ecosystem for a bit. When many people speak of Android fragmentation, it is usually the result of frustration stemming from delayed device updates and inconsistencies. Is this Google’s fault? Maybe, maybe not. Is this the OEM’s fault? Yes, indeed. Jake agrees:

Blame always seems to fall [on] Google for fragmenting the platform and I have no idea why. It would take weeks, not months, to port and test drivers and deploy every successive dessert-themed release. Here are your culprits: Sense, TouchWiz, and Motoblur.

Coming from the experience of working with the Android Open Source Project (AOSP) on a few devices, I can safely say that porting a new Android version to an older device is definitely doable, especially if you’re an OEM armed with working drivers and knowledge of the device’s inner-workings. Let’s look at it this way: If the CyanogenMod team can do it in a few months, OEMs should be able to do it in a much, much shorter time frame.

Problems arise, however, when an OEM’s custom framework turns around and bites it in the butt. I’m talking about HTC’s Sense, Samsung’s TouchWiz, Motorola’s Motoblur, and others. Whenever a new Android dessert is released, OEMs have to painfully refactor their custom framework to work with the new platform, or risk breaking the experience for consumers when they finally get that OTA.

Before continuing, I should explain what I mean when I say “custom framework.” Included in the Android system are UI controls like buttons, dropdowns, and checkboxes that developers use when building their apps. Custom frameworks usually target these controls, styling them and even changing how they function. Many frameworks, like Sense, also include additional widgets for your home screen. They’re all about differentiating their experience from the rest of the pack.

To be fair, of course, OEMs are perfectly justified in creating custom frameworks with different UI feels. When competing in such a market as the mobilescape, if you don’t differentiate yourself, you won’t perform very well. One of the most distinguishable ways OEMs can do this is by way of frameworks like Sense, TouchWiz, and Motoblur. The problems arise when these frameworks appear to be severely delaying OTA updates. Are the frameworks the problem, though? After all, Google announced earlier this year that the stock Holo theme is to be included with OEMs shipping Android builds if they want to qualify for the Android Market. We’ll see if that move lessens the negative effects frameworks play on devices.

Recently, Motorola Mobility announced that it would be producing less of a variety of devices while, instead, focusing its efforts on quality. This means that you should stop seeing a new Droid flagship device launch only to witness its successor show up only a few months later. This announcement also inspired an interesting concept in that, logically, less devices would result in faster, smoother updates. With that, we see two paths to speeding up and smoothing out updates:

  • Ditching custom frameworks completely, focusing on stock Android, thereby eliminating the development time of getting those frameworks working on new devices.
  • Cutting back on the number of devices being produced, thereby increasing the development force behind each device and extending support for devices for a much longer period of time.

I think the latter option is the one that will see the best results and improve the Android ecosystem as a whole, populating it with devices tuned and optimized for the long haul rather than for just a few short months. There is something to be said about quality over quantity.

Continuing on the topic of developing for Android with regards to fragmentation, Jake shares some important insight:

The Android platform has been fundamentally designed (since 1.6) with advanced filtering mechanisms for nearly every asset to allow targeting layouts, menus, strings, images, icons, and various other platform components so that the best available option is always used. There are simple, well-documented patterns to implement the same functionality for filtering your code. There is zero reason that you should not be able to write an application that targets every platform, every screen, and every device.

With that said, where does the blame fall now? I believe it weighs partly on the application developers themselves. Google has provided invaluable APIs and examples you can utilize to make an awesome app, and it’s recently launched the Android Design website for developers to be educated on how Android flows, including tips and patterns they can use to incorporate their app into that flow.

To conclude, there’s one final point I want to make. Fragmentation is inevitable. So inevitable, in fact, that it exists in more places than you might expect. First off, let’s see what Jake says:

Most people fail to realize that iOS is equally (if not more) fragmented between its major versions. The oversight that everyone makes is that Apple is both the software architect and the hardware supplier and can thus ensure that a massively large subset of its users upgrade. In fact, it’s laughable to think that [it] once charged to update across these major versions. If the Android OEMs did not exist and/or chose to not put an “enhanced” version of Android on their phones, no one would be talking about this.

Go talk to a Web developer about fragmentation. How many screen sizes does a website have to support? How many browsers have different implementations of various HTML5 and CSS3 features? Even if you ignore the fact that you have to support multiple browsers, the “fragmentation” is almost incomprehensible. How do they cope? A myriad of libraries aim to standardize behavior just like we have on Android.

To add, you could cry fragmentation for the PC market and Windows, paying particular respect to PC gaming. Many game developers have no choice but to stick to older versions of DirectX and OpenGL when developing games because they want to hit the widest market possible. This goes back to Jake’s talk about innovation, though. If DirectX and OpenGL didn’t continue to grow and evolve in fear of becoming fragmented, we wouldn’t be seeing all the cool things GPUs can do these days. As far as the PC gaming market goes, fragmentation is rampant, but is accepted as a fact of progress.

Before I end, I’d like to include one last bit from my chat with Jake:

“You’re a Web developer in Java” is the first thing I tell every person mentioning fragmentation. There are no tablets. There are no phones. There’s no Google TV. There is only an unlimited set of configurations of every conceivable feature. Write your application in a dynamic, progressively enhancing manner that follows well-documented patterns and you will be just fine.

That pretty much sums up this article, I think. Android is a dynamic OS designed to become fragmented — at least in the sense discussed here — so that it can better perform for the end user’s particular wants and needs. So, what’s the consensus out there? Is Android’s fragmentation good, bad, or nonexistent?

Article Written by

  • http://www.rainbowbreeze.it/ Alfredo

    I have had the feeling that only “screen” fragmentation has been taken into account. But fragmentation in Android ecosystem is much deeper that this. Is also about internal component of the framework (for example camera, media providers, default directories, window managers and more). And you cannot resolve those problem with “advances filtering mechanisms”, but you need to discover them first, imagine how work-around them and then put some lazy “if” inside your code.

    And we can also talk about not-so-high quality of inner framework components: ImageView that doesn’t release bitmap memory, gallery that do the same, overall controls graphic quality is very low (expect on ICS, but it is the future, not the present), so you often need to use a custom look’nd feel. All this stuffs force you (the OEM) or you (the developer) to re-invent the wheel just because basic support is sometimes poor. And when a new version of the system is available, you need to recheck your custom library against it to verify compatibility, better way to do your hack etc… For me, also these tasks are part of the “fragmentation issue”.Finally, OEMs don’t really want to upgrade their devices with latest Android version: why upgrade a device (for free) if you can force the user to buy a new one? Google proposed a 18-months support period for new devices, but who knows if OEMs will respect that proposal?

    And yes, I’m a proud android software developer, and I do this as a main work! ;)