Wednesday, June 02, 2010

What Do YOU Think Fragmentation is?

Dan Morrill, Google open source & compatibility program manager extraordinaire, wrote a great post on compatibility on the Android Developer Blog yesterday. It explains - in some detail - why device and platform variety is a good thing for developers, and what the Android team are doing to make sure it stays that way.

Within the post, Dan makes what some might consider a bold claim:
Because [fragmentation] means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.
If that pull quote makes you angry, I strongly suggest you go ahead and read the full article. Seriously. I'll wait.

By reading it you'll learn all about the Compatibility Definition Document [PDF] and how the Android Market and Compatibility Test Suite are used to ensure that the apps you write will work consistently across all compatible devices.

As an apps developer, Dan addresses my concerns completely. As long as there's a process in place to ensure I only need to write one app, launch it in one place, and know that it will behave as expected on any device for which it's available, I'm happy.

Judging from some of the abuse I get when I link to the updated platform distribution graph, or urge developers to start using new APIs when we release a new SDK, it seems some people have Strong Opinions on the matter. So, if having read Dan's explanation, you're still angry (or angrier still), I'd be interested in finding out why.

As Dan says, fragmentation has been used as a catch-all for "things that are different", making it impossible to have a meaningful conversation around any of the individual topics. I've created this Moderator page to find out what YOU think is a "fragmentation" problem on Android -- and more importantly why you think this does / could cause issues for developers -- hopefully while avoiding an argument over what "fragmentation" is or isn't.


  1. THE fragmentation that users are worrying about its the fact that they often don't have the latest (and greatest!) version on Android running on their device. And most device manufacturers are slow at best at updating the OS. I can totally see their point and clearly this is mostly due to the device manufacturers, not Google.

  2. What Eric said. I'll also add that I think what people want Google to do is adopt the Apple model where they push software updates to all the devices on the market. They see people with 1st generation iPhone running OS 3.0, and wonder why their 6 month old Android device is still running 1.5 instead of that fancy Froyo OS they just saw in the news.

    Google is obviously taking a different approach, but I do think the Nexus One and what was the Google Phone store could have been a nice middleground. Phones like the Nexus One can be entirely managed by Google and upgraded more frequently as its in their best interest. I just don't know if we'll see a Nexus Two.

  3. Well, I welcome diverse hardware specifications / profiles, but users with old versions are a real world problem.

    I get the vibe that Google can't do anything here. I don't thin that is true.
    What could Google do?

    It would be good if Google would put at least a little pressure on the vendors to keep their customers current.
    I think it would be reasonable that a vendor who wants to carry the Android logo and the Market, needs to make all official Android versions available to every customer who purchased their device during the last 12 months.

    I would cut out 1.5/1.6 users soon if I would still be able to support them, e.g. provide them with bug fixes. But the way the Android Market is setup today this won't work.
    I can only post a single version of my app as opposed to a legacy version for 1.5-1.6 devices that I have in maintenance-only-mode and a version for 2.0+ devices.
    Also my app cannot be found anymore by 1.5 devices, even though the "old" version would run fine if only the Market would allow that.

    (one) might be possible, but tricky, (two) is a no brainer from my point of view.

    Speaking of fragmentation and apps that are ignoring 1.5/1.6 users, how is it going with open sourcing the twitter app? ;-)

    I'd like to borrow some stuff right away. And I really hope that the stuff I want to borrow (maybe action bar, definitively quick actions) is not tied to some fancy 1.5+ API ;)

  4. I never got the whole fragmentation problem. If that is fragmentation, it exists on *every* platform. Even supposedly non-fragmented platforms like your average gaming console experiences some form of "fragmentation", as you can never be entirely sure the user has plugged in whatever peripheral you want to support.

    If you compare what happens on Android with what happens on the iPhone, fragmentation is less of an issue because Apple drops support for older iPhone OS releases the minute it releases a new version.

    What that means is that as a developer, you either must upgrade or risk losing all your customers. That shouldn't happen, and Apple doesn't exactly want it to happen, but the truth is that existing APIs change in their behaviour significantly enough from release to release that while link-time compability exists, run-time compatibility is not always guaranteed. That's pretty much the worst thing you can do as a platform vendor.

    Oh, sure, you can support various different releases of iPhone OS, but then you're stuck with the same fragmentation issues that exist elsewhere.

    But as developers tend to circumnavigate this issue by simply releasing new versions of their apps only for new versions of iPhone OS, as a user it means you must upgrade or risk losing support for the apps you like. That is, if your apps run perfectly and you never want to install any new ones, you'll be fine, of course.

    Effectively iPhone OS eliminates fragmentation by blackmailing the developer and user community. And they can do that only because they're the only manufacturer of devices that run their own OS.

    If that doesn't bother you, and it's all you know, then yes, Android is terribly fragmented in comparison...

    ... also it means I will slap you if you talk to me about fragmentation on other platforms.

  5. Anonymous1:17 pm BST

    Fragmentation is definitely not the right word for it, because, as Dan pointed out, there is a lowest common denominator of functionality, but few outstanding apps use only the lowest common denominator of functionality, and with the number of Android apps now available developers need to produce outstanding apps in order to make a living, which causes a lot of another F-word; Frustration.

    I've seen numerous users confounded by the fact they've bought a "New" 'phone but it's completely unable to run apps which are several months old, especially given the core functionality of the app isn't something that couldn't have been achieved on their device.

    The twitter app demonstrates this perfectly; It doesn't actually provide any core functionality which couldn't have been provided in an app which would have run on earlier versions of Android (as shown by third party clients), but by adding things like a live wallpaper it's excluded a majority of Android users just for a user interface feature.

    So maybe the frustrated users haven't found the right word to express their feelings, but there is a problem, and it's a problem which users are seeing first hand, which means in the long run it's not a good thing to just leave alone and hope it'll go away.

  6. Justin's comment made me think of another point.

    Closing the online store was way too early. You guys didn't even try it here in Europe. Although the general population also buys subsidized handsets here, it is not mandatory and the geeks/early adopters often do not (besides a forced iPhone mandated purchase of subsidized phone I haven't bought contract and phone together for more than 10 years). And in the high end phone market I suspect the geeks/early adopters are a sizable crowd.

    With you guys pulling out so early who will keep the heat on the manufacturers to do after-sales upgrades? That also leads to more abandoned phones with old versions.

  7. I personally don't see a problem with the so called "fragmentation". Backward compatibility is great and not every app out there uses bleeding edge functionality anyway. In fact virtually all don't.

    This "fragmentation" happens with every platform. And Android is no different. In fact i think Android has handled it better than any platform I've used.

  8. I used to think fragmentation of Android was an issue but not anymore.
    There are two kinds of "Android devices":
    - the "Gooogle Experience" Android devices should run the latest Android OS version like the G1 or the Nexus One.
    - the "HTC/Samsung/LG/SonyEricsson/Motorola experience" Android devices which are phones that happen to run on Android but they are more or less customize to fit the manufacturer identify.

    Most of all, as of today, it's clear that cheap Android devices are gonna be running android 1.5 and that's going to be this way for a long time (1 year or more). I don't think most of this cheap devices will be updated. User who cares about having the last Android version won't buy these devices in the future.

    High-End Android devices are running Android 1.6/2.1 and will certainly be updated over the time.

    As Android app developers, if we want to make an app that works great on all Android devices, we have to test our apps against Android 1.5 HVGA devices (cheap) and Android 2.1 WVGA devices (high-end) and that will cover most of the market.

  9. I don't think of it as "fragementation" and I am glad to see Dan (and you) address the topic directly, but I agree with Mariano.

    I would like to see a market system that allows me to upload multiple binaries, each with different "badging" (support for different configs) that I decide upon, all under the same application name as users see it. This would allow me to have, for example, a version of an app that works on 1.5, and another version that works on 1.5+, or any combination therein that I might need (if I need one version that supports a camera, and one that doesn't, that too, any different config).

    I know I can fallback gracefully within my app in many circumstances, and that should be the preferred approach (whether or not the camera exists, for example), but for some scenarios that isn't possible or for one reason or another isn't desirable. Allowing multiple binaries with different configs, which seems like it would be simple to do (and then using the same detection in the market that currently happens, based on the users device), would resolve issues like releasing 2 versions of an app with different names (one for <= 1.5 and one for thereafter).

    Seems like many apps could benefit from this (including stuff like the official Twitter app). If you want a fancy feature that is only available in a newer API, you can choose to use it and make a binary for devices that support it. But for older devices you still want your app to be available, even if in a less fancy version.

  10. The fear of fragmentation comes from older mobile programming language, especially Java ME (though Symbian would apply too). When you program a Java ME app, as soon as it becomes a bit complex you can be sure it won't work on more than half the phones.
    You use the camera on Nokia phones? It's different between a S40 and a S60 phone. And on some phones it won't even work properly even if they do have a camera.
    And don't get me started on LG's or Windows Mobile's Java support.

    So you have to test and debug your code on a lot of phones if you want to make sure most people will be able to use it. You often end up using device (or at least device family) specific code.

    With Android, I was afraid to see the same problems happen. I remember reading ZXing's message board and seeing that the application, which worked correctly on the HTC phones (Dream and Magic) had problem working on the Samsung Galaxy. That made me think "Fragmentation is back".

    There are also those who said "fragmentation will kill Android" and repeated it when devices with different screen sizes came out (and everytime a new version comes out), but they are Apple fanboys who just hate Android for not being made by Steve Jobs and I guess they won't be able to say it anymore when the next iPhone comes out with a bigger resolution.

  11. Agreed with Mr. Collins, and I'll raise his solution one more. Not only will having multiple alternative binaries help with respect to hardware variances, but if the user can choose flavors of the app, it can also address the permissions problem.

    Right now, you have to ask for all permissions up front, even if there's a 99% chance the user won't exercise a feature that needs a certain permission. Requests to have some sort of conditional permission system haven't exactly been met with resounding enthusiasm among the core Android team.

    Having multiple flavors of an APK associated with a Market entry could handle that.

    For example, take Evernote. Evernote's client, last I checked, requested the INTERNET permission (makes sense) and the READ_CONTACTS permission (egad!). Now, I assume READ_CONTACTS is for an overly-integrated note-forwarding option, one I would happily live without. As it stands, I either need to skip the app or allow Evernote to snitch all my contact data. If, however, Evernote could publish apps with and without that permission, just disabling a menu choice for the note-forward feature, I'd choose the one without the permission in a heartbeat.

    It'd still be better to have optional/conditional permissions, but if solving Mr. Collins' issue can give us a workaround for the permissions challenge as well, I can live with that.

  12. Mark,

    I think it would be much cleaner to solve the issue you raise by introducing conditional permissions.

    The developer could then express via Manifest that his app needs some permissions (e.g. INTERNET) and optionally wants some others (READ_CONTACTS), maybe with a short description of the reason ("Need READ_CONTACTS to SPAM your friends"). The user is then asked to give or withhold the optional permissions.

    I really wouldn't be too happy to maintain different apps just because of some permissions.

  13. Anonymous7:29 pm BST

    I agree with Mariano. Google should have persisted with the Online Store. They killed it very early. I am from India. There is a lot of craze around Android [and Nexus One too] here. Probably, if Google could have made Nexus One available in India, it would have become very popular here.

    And reg fragmentation, as Andy Rubin said yesterday, very soon Android will have ONLY one release for the entire year. Probably this will change the Android mobile handsets landscape totally. Hope it matures to that level in very short time, which will help developers, handset makers and also the end users.

  14. Having to maintain multiple binaries does not solve the problem at all. Mariano's conditional permissions suggestion seems like a more sound solution, but I still think there has to be a better alternative out there.

  15. Oh really great article,
    im very pleased to read this.

  16. Anonymous8:10 pm GMT

    Here it is in a nutshell.

    Person A with an Android shows Person B an App. Person B likes the app goes to the market place and finds out they can't get the app, because their Android phone is not compatible.

    Does that happen on Blackberry, iPhone, or Windows Phone? Person A with a HTC Windows phone shows Person B with a Samsung Windows Phone an app what will happen next? Fragmentation?