Android Fragmentation Visualized
opensignal.com
opensignal.com
http://en.wikipedia.org/wiki/HTC_Sense http://en.wikipedia.org/wiki/TouchWiz
I wonder what Android fragmentation looks like per-country.
You've never seen people griping in unix land about the different opinions the different versions of different distros have, about where various files belong? or how/which configuration defaults should be set? Or how packages support a small handful of environments and rely on individual admins or community maintenance to discover and document how in the world to get package W to play well with package X on distro Y.Z?
What's the push for containers even about, if no-one's running into fragmentation-style roadblocks?
As for complaining about different distros: that depends. For some time I've tried to solve that problem through a project of mine, Autopackage (now defunct, website gone; it's still on Wikipedia: http://en.wikipedia.org/wiki/Autopackage). But we met a lot of resistance from distribution people and even from users. The view was that each distro is its own operating system and shouldn't bother with compatibility with other distros. Heck binary distribution is only for closed source software, was what they said. In the end there was not enough support.
So no, I've not seen people complaining quite as much about Linux distro fragmentation as about Android fragmentation.
As to quantity of complaints: you asserted these sorts of complaints just didn't exist. If you want to argue about whether they're overblown, or simply proportional with the fragmentation gripes of various historical platforms, that's quite a bit different.
It'd be interesting to see if the newer versions of Android would attempt to do what the newer versions of Windows did - detect an older application trying to use an undocumented feature, and then give the app what it wants to hear, instead of crashing or having a bug. Therefore, keeping compatibility with older programs.
Microsoft of course had teams of people doing this kind of stuff.
The iOS development philosophy is that developers should not have to worry about any of this, and their apps should just work. I mean, when was the last time you tried to install an app on iOS and it gave you an error message about such and such prerequisite missing, or you installed it and the user experience was broken because the phone had an older version of the OS or a wacky manufacturer UI?
I can find a way through a code problem, but when it comes to bureaucracy sometimes there is no alternative, or they shut it down the moment you find it.
And I doubt you would see any difference between Apple's bureaucracy and Google's. Anytime you try and embarrass the company, try and take money away from them or be anti-user then of course you will have problems.
I like neither Apple nor Google but I believe we shouldn't overlook facts that clearly differentiate one from the other.
It's also not quite as big of a deal on Windows - you can simply include or launch the installer for the XYZ Library or ABC Framework version 3.9.
Microsoft, and IBM before them, had that same philosophy: if only everyone would use the current version of their OS, developers would not have to worry about cross-platform compatibility because everything would just work. Nobody liked that philosophy then, and most developers don't like it now either.
Web development can certainly be a PITA, but at least the web development platform is based on open cross-platform compatibility as a goal, rather than monoculture. It recognizes the reality that monoculture can't be achieved without giving up fundamental freedoms, and strives to work in that reality rather than in some company's monopolistic wet-dream.
I'm not sure if the latter part of that sentence is correct, since iOS is the most popular mobile development platform.
Yes, there are different screen sizes, but that's not a big deal, the API abstracts from that.
And yes, there are different API versions, but that's not a big problem too, because the API is backwards compatible (or forwards comaptible, I'm not fully sure about the difference between these two).
As for the API "not being a big deal." I think you grossly overstate how well the APIs have been managed. It is nowhere near as hellacious as the J2ME fiasco, but it is not pleasant, either.
Not sure I understand, what do you mean by that?
> but it is not pleasant, either
Why exactly?
I meant that the latency of the touch screen is a huge factor. If the screen is not keeping pace with my finger, it is highly noticeable. And jarring. This is just as true for many GUIs, but the speed of getting text onto the screen is a solved problem. And rarely goes wrong. (That is, most UIs on desktops are relatively static while the user is doing stuff. This appears to not be the case on my phone. Further, if Facebook goes slow on my desktop, I just switch to another app/tab for a bit. Not really doable on the phone.)
As far as the API issues, it really comes down to just how obnoxious it is to target many versions of devices. You wind up picking the API that is solid across them all. Often this is the "old" one, that is not quite as nice, and definitely not as supported. In fact, this is the main thing I hate about how Google has curated their stuff. They don't so much "stabilize" apis, as they do constantly churn them.
I mostly agree with the touch latency, even with Nexus 4 it's not as good as iPhone. But it's getting better.
API issues: there are different API versions that are backwards compatible. But apart from that, the API is the same across devices. Manufacturers don't change the API. Having to use older API versions can be a bit annoying, but I don't see it as a big problem, and there's also the support library.
Cf: http://developer.android.com/reference/android/app/AlarmMana...
This is a very common API.
Thanks to twitter and other social tools complaints now get amplified and travel quickly.
There always have been a lot of pain and complaints in windows, macos & linux development, in any case, but we didn't pay much attention to it as we do now.
Problem with Android fragmentation, on top of that, is the frustration that comes when you compare to the competing platform (iOS). I'm not saying iOS development doesn't have its own pains, but it looks tidy and simple compared to the Android ecosystem. If iOS wasn't there Android fragmentation would be accepted as the normal state of affairs.
It is a big deal? Well, it depends on what kind of app you are developing and how much you can get away with. For some developers screen resolution differences are not a big deal, but different processors, memory, etc... are. For others the opposite is true.
Example of this? I can't think of one offhand (besides things like the original iPhone not providing fine-grained location, because it didn't have a GPS receiver). Some of the user-facing features vary by device, but the APIs are the same.
There are some horrific devices available today that are Android in name but definitely not in spirit. They are so underpowered that they are more akin to feature phones.
It is not just about effort. It is also about opportunity cost. Imagine you work for someone else and then you tell them that for the kind of UI we want I can ensure it works for 95% of Android devices if you give me another three weeks and access to these 30 other devices (maybe on some website that offers paid access to them for a bit of time). Right now it works well for 75% of the devices.
Now, the person who owns this business may consider his/her money better spent when you implement some other feature on both Ios and Android rather than ensure you support almost all of Android devices. It may not be the developer who chooses. Many times it may not be so clear cut too. It may be that some features get shot down during design because they are hard to get right on all the various aspect ratios and screen sizes that Android offers.
So, yes the 'fragmentation' is a problem but in my experience it is mostly only to do with the variations in aspect ratio and screen size.
Nevertheless, like one of the first replies to this topic (by bookwormAT) says, it is not as bad as having had to code for various Operating Systems if the manufacturers hadn't agreed to go with Android in the first place. So, Android does help us develop for a wide range of manufacturers' phones but it doesn't help much to ease the pain of accounting for the variation in displays.
The second part is the API differences. You don't get to use the latest fancy new features when 34% of your audience is on the older version. That is similar to windows land, but it is also not nearly as big a deal as the screen sizes.
Finally, hardware. Yes there is a lot of different hardware on desktops, but on average it is more powerful than on mobile devices. Ask anyone who has done embedded development, there are a different set of problems there than you have on the desktop. The same goes for mobile. Most of the new mobile devices have hardware on par with desktops from a few years ago, so it isn't quite as bad as embedded. That being said, the range of Android devices is huge, and there is some percentage running on crap that creates another headache for Android developers.
In my small experience, the "so what" is that, for example, just today I get an email saying that feature X of my app doesn't work on tablet Y.
So now what? Do I go and buy that tablet to see what the problem is? Hardly worth it for the money I make from Android.
This sucks for developers for obvious reasons and it sucks for consumers as it's pot luck whether an app will work for you, especially if it's not one of the top 5 devices.
I've read it's terrible for 3D programmers as often devices just flat out lie about the GL capabilities they support.
Exhibit A: Apportable's android device library https://twitter.com/chinmaygarde/status/349809877176156160/p...
That isn't simple anywhere. I'd call it flat out amazing that they have apparently mostly succeeded, and a massive testament to the level of consistency that does exist.
The last three places I've worked at had similar cupboards in order to support the array of Android devices. And they were just run of the mill web companies. The problem really isn't Android but everyone's screwed up implementation of it.
But in "run of the mill web companies"? Where I work, we have ~6, but 99%+ of the time we just use our Nexus 4s because 99.9%+ of the time it "just works" everywhere, especially if you stick to an older API / support library and know the quirks. We support 2.2+, have a few 3.0+ and 4.2+ features, and it has been terrifically easy to handle our range - much easier than iOS. The other devices are to see how using the app feels on different sizes / performance classes. Getting that feel is important, but it just requires a couple "token" devices.
1. Performance: These devices can run your app smoothly even with a large number of assets demanding computational/graphics processing. 2. Basic: These devices can open and run your app but it starts to lag when pushed to the limit. 3. Incompatible: These devices don't make the cut in terms of specs and it's worth not even allowing the app to be downloaded.
The quickest way to deal with this is to eliminate the bottom wrung of devices by choosing only to deal with the more recent Android versions since older devices may not be able to upgrade. From there, it's probably worth excluding certain devices based on your app's performance trends (crashes, lags, customer complaints). Obviously, the most optimal solution is to continuously optimize your app to further include more devices.
Here is how I see the "Fragmentation issue": My customers are using one of maybe 800 or so different devices, with maybe 100 different software systems powering them. That number was about the same before and after Android came about.
Now if I want to write a program for all my customers, I need to theoretically write at least a hundred different applications. That sucks. But today, thanks to Android, like 95 of the available operating systems are based on the same development kit, Android, and so instead of writing 95 different applications, I make one and then adapt a little if necessary.
Android is a defragmentation platform. What we call "Android fragmentation" just means that the defragmentation works 90%, not 100%. People can use Android to build lot's of different operating systems, which are either very similar or very different that what is available in the Android open source project. But because it's all based on the same code base and runs against the same compatibility test suite, a developer like me can target many devices and many operating systems with a single code base. That's awesome.
iOS and Windows are fragmenting the market for me. They are not compatible with Android, so I have to write a separate application for these systems. Often from scratch.
A few notes to further explain this position:
"operating system" is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself.
E.g. the app store, itunes, Location Services, the User Interface and the push notifications system are considered features of the iOS operating system. But on Android based devices there are independent from the Android system. You can make your app run Holo no matter what Android version is installed on your customer's device.
When speaking in iOS terms, you can say that 90% of all Android devices get updated once per months or so, when another update for Gmail, Google Voice Search or GCM arrived.
You do not need to depend on Google if don't want to make your software compatible with Android. There is no dependency from Google in Android, all their influence comes from the fact that they own the most popular third party app suite that every OEM wants to license on their device. If and OEM wants to go their own way, like Amazon, Google has no way to stop them.
So yeah, it's a "pick your poison" kind of world and theres no easy way out. You deal with it and hope for the best. But that doesn't mean it's not worth pointing it out or that is not a problem for the Android ecosystem in the long run.
> iOS and Windows are fragmenting the market for me. They are not compatible with Android...
By that same logic Android is fragmenting it too.
> When speaking in iOS terms, you can say that 90% of all Android devices get updated once per months or so, when another update for Gmail, Google Voice Search or GCM arrived.
No, as a developer having users in different versions of Android affects the things your app can do. What APIs does it have access to and how. I don't care if the user thinks he's updated because their gmail app looks new. I care that my app needs more hours of coding to make sure it does the same on Android 2.3 than on 4.1.
> ... You can make your app run Holo no matter what Android version is installed on your customer's device.
There are some iOS developers that follow this same route. A lot of services / functions in iOS are not mandatory, you can use your own versions of it if you want to devote the time and skill to rewrite them. Loren Brichter comes to mind as a good example of this. Developers use the Apple route because it's easy and takes out a lot of the workload.
How? Android is an open cross platform technology for building operating systems that are app-compatible with each other. How is that fragmenting?
"No, as a developer having users in different versions of Android affects the things your app can do."
This is correct, but not in the sense that an older version of an operating system (in the iOS sense of the word) would. New developer features of ios7 are a new user interface, better location services, background push notifications etc. All of these things are available on android-based systems as well, but none of these things depend on the Android version.
I admit that there are also APIs that are part of Android, and therefore only available in newer versions. And so an OS that is based on Android 4.0 can not run every app that is made for an OS based on Android 4.3.
But if you need to target all 800 devices that your customers use in the end, the iPhone turns out to be much different from an Android 4.0 device than Android 4.3. And that's the point: You need to develop for all these devices anyway. So think about effort per device, not effort per platform.
If you're going to say introducing a new OS is fragmenting the market than Android fits that definition as well as any other. If you're going to claim Android gets a free pass because Calvinball well we might as well close the thread.
Since Android was first released in 2008, Many vendors have replaced their incompatible OS with another one based on Android.
Situation: there are two operating systems, A and B. Someone who wants to target all the devices on the market has to write two apps, one for A, one for B. This is fragmentation.
Introducing a third operating system, C, means that someone who wants to target all the devices on the market now has to write three apps: one for A, one for B, one for C. This is, arguably, more fragmentation, since you have more apps to write.
Does it really matter what A, B and C are actually called? Android is the latest entry to the mobile operating systems market (save for ghosts like WebOS). If anything, it was one of the driving factors of fragmentation.
> But if you need to target all 800 devices that your customers use in the end, the iPhone turns out to be much different from an Android 4.0 device than Android 4.3.
How? IIRC, there's nothing stopping you from developing with an older API if you want, just like on Android. Sure, you can't use the new and fancy features, just like you can't use them on Android, either...
Pixels (CSS, not physical) are especially interesting because they're an angular unit of measure based on the user's expected distance from the screen. Once you start building off that foundation, many device fragmentation woes go away.
That said, there are a handful of places where we logic-branch based on API version by reading the UA string. These are usually due to features that report working, but fail miserably.
I, for instance, would prefer that the industry adopt six or eight standard screen sizes and stick the fuck with them. Google is in a position where it can mandate that, actually.
There are many excuses one can make in Google's favour, but this does not take away the fact that their development environment is very poor, primarily due to fragmentation (and then there's development tools and documentation, but those have been traditionally been a stumbling point).
Also, it's intelectually rude to try to rest your arguments on words for which you construct your own meaning. That's what salespeople do and it's a marginal improvement (in technique, not in correctness) of the straw man sophism.
> "operating system" is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself.
"Operating system" is a very clear expression that means exactly one thing.
Fragmentation can mean more things, and this article claims one of them. People who want to write software for the iOS operating system have a small set of screen sizes and resolutions to target. People who want to write software for the Android operating system have a fuckload of incompatible APIs, screen sizes and resolutions to target, which is exactly what fragmentation means. This is especially problematic for small apps: if you need 3 weeks to write the core of your application, and 1 day to tweak each combination of obscure resolution and screen size, strange device, hardware configuration range and API version you can easily end up doubling your development time.
Also, if you actually try your hand at writing an application with a decent UI, you'll find that the "a little" you want to tweak it is "a lot". In my experience, if you try to target a full set of platforms, ranging from small phones to full HD tablets, you actually end up designing 3 UIs from scratch (unless you want at least two of them to feel like someone stretched or compressed the other one to fit a screen it wasn't designed to). This includes entire sections of the UI logic (e.g. redesigning navigation flow), and while there are tools to help you with it (such as Fragments), it doesn't take away the pain.
That's not correct at all. An "Operating System" can mean many things and there's tremendous debate in the OS and Systems community over the definition.
Is it an OS's job to...
-provide a Graphical Interface?
-provide any interface?
-handle a hardware abstraction layer?
-handle font rendering?
-composite graphical displays?
-provide an abstract virtual machine environment across different processor types?
-handle user accounts? What about systems that aren't multi-user?
-does an OS need to handle virtual memory to be an OS? what if all memory management (virtual or otherwise) is handled by a dedicated support chip instead?
Some more:
-does the simple timing code on a $1 digital watch count as an OS?
-does a system that, when turned on, goes automatically to a memory address for more instructions, and those instructions are only the instructions for a user program count as having an OS (lots and lots of computers past and present are like this)?
-does an OS provide software beyond just the Kernel? e.g. Start with a modern linux distro and start removing packages, at what point is it no longer an OS? (GNU would like you to think it's an OS only when you have GNU userspace tools, X etc. on it. )
-is an OS just a space to host and run programs? Does that make the JVM an OS? How about a browser? How about MS-Excel and Macros?
-the OS I'm using right now ships with a paint program, a calculator a browser and a text editor, must an OS have those things?
-how about a system with a complex BIOS that happens to have USB, Ethernet support and a web browser? Is the boot code now an OS? When does bootcode become an OS if this isn't it?
-should an OS handle all available hardware on a system or just some subset?
-what is the first OS in history?
etc. etc. etc.
At some point, somewhere between boot loader and a fully loaded gaming system there exists this thing called an OS. It seems to be more than just a kernel, unless it's an embedded system with basically just a kernel (unless the system is so small and dedicated it just runs code directly without an OS layer (unless you count the code that's running and doing its own resource management an OS since by definition an OS does resource management)), or it seems to be resource management code that also happens to have nice font rendering and a full networking stack. The debate goes much deeper and has gone on for decades.
There are a lot of debates about whether X or Y should be a function of the operating system, but that doesn't justify OP's position. Applications that come with the operating system are not part of the operating system, you know, on account of them being separate applications. Unless I missed the debate on whether grep and emacs are essential parts of Linux or not.
The questions you quote are much like the heap paradox, but that doesn't make the concept of operating system so flexible that you can bend it to mean anything. Also, let's be honest here -- quite a few of those questions are there only because at some point in history, fanboys of one platform wanted to rest their fanboyism on some sort of technical grounds, which is how we ended up with fundamentalist-like questions of the "should the OS provide a GUI" sort.
Here's GNU's definition of a Unix-like, "A Unix-like operating system is a software collection of applications, libraries, and developer tools, plus a program to allocate resources and talk to the hardware, known as a kernel." This is a very heavy idea of an OS and grep and emacs sound like "developer tools" and "applications". Most OS people involved in unix-like OSs would be aghast if you didn't at least include some basic userspace applications like cat and ls.
GNU isn't specific about what needs to be in the collection of things to constitute a unix-like OS, but it looks like that agrees in most respects to bookwormAT, "'operating system' is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself."
GNU's concept is miles different from very light concepts of an embedded OS's like Femto OS which near as I can tell is pretty much just a kernel and some libraries.
WP on the other hand says, "An operating system (OS) is a collection of software that manages computer hardware resources and provides common services for computer programs." So strictly speaking, by this definition an OS doesn't even need to provide disk access like the old DOSs!
Although of course it later contradicts itself and says "Access to data stored on disks is a central feature of all operating systems." which anybody involved in the OS community knows is not a central feature of "all" operating systems. I've used OSs where useful file system access was provided via userspace applications (a la FUSE).
Palantir takes the position that an OS doesn't need to be interacting or managing the hardware stuff, just providing the ability to run different hosted applications is enough, making things like web browsers operating systems (http://www.palantir.com/2009/11/palantir-like-an-operating-s...)
bookwormATs position is that not only are OSs heavy things, but that "Android" is not just an OS, but a meta-OS description of what an Android OS should be (just like XML is a meta-language for describing XML compatible file formats).
So if GNU's definition is correct (and lots of people subscribe to GNU's position), bookwormATs position, "'operating system' is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself." is correct.
I'd rather think of devices having different size displays, different shape displays, multiple displays or even no display.
Theses things can change rather rapidly! I quite like the idea of skinning incrementally, start with a CLI (or even something more minimal - like the button and beep input/output interface) and go up from there.
That's not a question it's a straw man. The real question is whether Android would have been better served by Google withholding their closed source services unless devices met some additional standards on dimensions and software updates.
I make one and then adapt a little if necessary.
This is disingenuous. The whole point of people complaining about Android fragmentation is that you don't adapt a little. You adapt relatively a lot vs iOS which is a bigger market in dollars.
Adapt from one of two not android based systems to another, for example from iOS to Windows Phone.
Now adapt from one android-based OS to another, e.g. from the Galaxy S "Nature OS" to HTC Sense.
Compared to the former, the latter only needs to adapt a little.
Android did not make users buy multiple devices. Android did not make users buy into different operating systems. Android just makes different operating systems compatible to another.
Random example: http://comments.gmane.org/gmane.comp.handhelds.phonegap/3631...
I work for a very popular cross platform mobile application (ios, blackberry, android), and we have dozens and dozens of test devices, a qa department just dedicated to finding differences between devices, and let me tell you that most of the time, special tweaks are required for android that are not required for ios. Surely this is hugely due to the fact that there is less variety in the ios world, but you simply wont find that "manufacturer xyz decided to implement this differently so now the developer must account for that".
Finally, in your analogy of adapting from Android->Android, is similar to adapting from say ios5->ios6. Having been through this several times now, I can tell you with confidence that the initial time of adapting is very similar with equally skilled developers, but the delta of "code complete" to "ready to ship" is much larger on android, due to all of the testing, double-checking, and edge cases. So in summary I would say that you do "adapt a little" with ios, but you end up adapting a lot more than a little for android, if you want to support more than a couple phones, in my opinion.
iOS however is a horrendous mess. Every year or two they overhaul their layout system (contentScalingFactor, then auto-layout, and other things). Also, each time a new version of iOS comes out you need to work around various bugs/changes and you end up tweaking/hacking your code to get it working on all devices. I've just spent an entire day getting one of our apps working on the ipad in iOS 7, and another half day getting it working on iphone. It will require another day or two to get everything working perfectly, and then I'll have to recreate all the new icons, launch images, screenshots, etc.
No, no. Play fair: adapt from Samsung Galaxy 580 to the Asus Transformer Pad TF300TL, ensuring that your interface actually looks OK on both of these and on every device in-between -- that includes the Xperia V, the Asus PadFone and the HTC One X.
And no cheating here -- when a customer complains that the application "looks funny" on his phone, don't forget to factor in the price of buying the damn thing.
Have you actually written a real Android application? Maintaining a list of differences between devices (and the hacks you need to make just to make a program written for the same fsckin platform work on all those devices) is a part-time job in itself.
Not true at all. They could standardise on a few screen sizes and minimum hardware requirements and the problem would be solved.
And it's not that screen sizes are the problem when people talk about fragmentation. Any proper made Android app scales easily on all kind of screen sizes.
I own a bunch of android devices, I stuck it out through three major OS updates in hopes that things would improve. I still like my Android devices but 90% of third party apps are single-purpose tools of very limited scope. There's a reason the good stuff is on iOS, and I hate to admit this as I have a bias against Apple for their walled garden and general anti-hacker/tweaker approach.
The problem isn't that I can't make an app for all the Android devices. The problem is that I can't make it as good as I'd want for all intents and purposes. Developing for iPhone, I can easily hit 95-99% of the market without making any sacrifices at all. It will look good and it will work on every phone, all while allowing me to use the latest features and API's. With Android, the app WILL NOT look as good as the iPhone version on some of the phones. 34% of the market is using something released over 2 years ago, and several major version ago.
I actually like Android, and developing for it isn't the worst thing in the world. But to say it isn't fragmented and doesn't create headaches for developers is absurd. It absolutely adds to fragmentation, and parts of it are a real pain.
Please reread my post. I'm referring to the software on the Galaxy S, the HTC One etc. as independent operating systems. These OSes matter. It's what people use today on their computers.
Android is not an operating system in the sense that Windows or iOS is. It's a platform on which you build such an OS.
I was first puzzled and am now intrigued by their choice to use physical screen size as a basis for that diagram, as opposed to screen resolution. Very appropriate in our resolution-independent times. Of course either way you do it, Android is going to have more variation than Apple. That diagram is also kind of difficult to read; what shade of blue corresponds to what market share?
Finally, it's awesome of them to share the source data! Maybe I'll actually get around to implementing my suggestions.
Absolutely. However, what struck me as crazy is the sheer number of devices per manufacturer. There are more than 100 devices there -- for Samsung alone. I get that they put out different devices for different locales. But I can't imagine the overhead in having that many devices in all kinds of different sizes.
What gives?
But most of it is that hardware manufacturing of low-margin products is hard. Sure, you might really want to use a partcular Snapdragon part, but Qualcomm can't give them to you in the volumes you want, so you make two boards for two different chips. Or the camera manufacturer you were using just had a glitch and can't give you the second batch in time, but with a quick PCB rev you could use this other sensor which is "mostly" the same, etc...
Apple doesn't do this because Apple ships high margin parts and can pay more (i.e. order extras, pay premiums to get first priority in shipments, etc...) to get the components they want. And, frankly, because Apple is willing to eat the occasional supply burp and just spin it as "demand was too high!".
Android 2.3 has around 40% of the Android market. I doubt many players can do it. Some companies still want IE7 or IE6 support.
Actually, Android UI design (if you follow the guidelines) is comparable to responsive web design, and that isn't surprising, considering that Google is a web centric company.
You have layout XML files (HTML), seperate XML files for styles (CSS) and then your code that manipulates the layouts dynamically. And most of the time you work with relative positioning of UI elements (like you do on webpages) instead of absolute positioning. Even Androids Intent mechanism is based on the idea of web links. (but here you link to another "page" of your app, or other apps) Also, Android apps behave like web pages with stacks of Activities (comparable to pages), and a dedicated back button to browse back.
Yes, it would be easier if you had only one screen size and therefore could design everything statically, but with so many different screen sizes on current iOS devices (3 sizes for different iPhone revisions, at least 3 for iPad and I don't know how many for iPods) I don't think it's a painless process there either, and I expect that Apple will introduce changes in the future.
Also, you probably will never have pixel perfect design on Android that works across every device (it was never intended to do that), but you don't have that on the web either, and no one's complaining here that the web ecosystem will collapse because of that.
Why does everyone only ever complain about Android?
Only Press Complains. I haven't met a serious Android Developer who complained that fragmentation is in top 5 of their problems. I say this as some one who run Android Game/App Development company.
Yeah, but you'll meet lots of iOS/WP developers who complain about Android fragmentation :P
i suspect this probably has to do with a truism every programmer knows. there are really only 3 cases to solve for (not 11,868) -- one device, two devices or n devices.
m3mnoch.
That and the media needed something to write about.
For a long time websites were designed to fit a lowest-common-denominator screen size - 800x600 or 1024x768 - and anything larger just had padding or other void space added.
Hell, most websites are still like this. See: NYTimes, IGN, etc. Fragmentation exists on the web and it causes many of the same issues as it does for native-mobile, it just isn't new, and it isn't very controversial given that we've thrown up our collective hands and quit trying to take advantage of everyone's browser windows and just resign ourselves to wasting pixels instead.
Screen size fragmentation is still a big deal on Android because we haven't resigned ourselves to throwing black bars up on screen and we're still doing our damndest to make good use of each individual screen size.
On the other hand, browser API fragmentation is a huge deal, and people do complain about it incessantly, for good reason, and it shares fundamentally many similarities with Android API fragmentation. Want to build your new thing with Canvas or WebGL? What's the penetration like, how many users even have browsers/machines that can handle it? New CSS tag? Sorry, not supported in many still-shipping browsers. Pretty much the whole "IE sucks" meme comes down to API and implementation fragmentation.
Complex apps on the modern web involve miles upon miles of compatibility hacks to work out the implementation differences for the same API, as well as different API support levels entirely. This is a big deal, and a huge time sink, and people rightfully do complain about it.
tl;dr: Fragmentation on the web is a problem and people do complain about it. The only thing that isn't complained about is screen size, mostly because we've taken a huge cop-out to avoid it.
Standards restrict choice and ensure interoperability. If you do not have feature comparability between Android versions you do not "an" Android, you have many and they are not all the same. Fandroid chanting (remember the Maoist hordes?) and manufacturere obfuscation hide this simple fact from the people who buy handsets.
This is all very typically Orwellian behaviour by the fandroids, endlessly chanting about freedom, while actually having very limited choices. The reality is that for most users their only freedom, to get new features or the latest set of bug fixes, is to buy a new handset. As so often, "open" means open your wallet.
"Freedom is slavery", indeed.
Meanwhile, some fruit company chooses to only accept a handful of fruit sizes: an apple in two lengths, and two sizes of watermelon. Your job of projecting a user interface onto those surfaces is an order of magnitude easier because you're really only dealing with a couple of levels of detail to design for.
But on top of that, your analogy doesn't translate vary well to mobile platforms, i think.
Apple, the poster boy for non-fragmentation, is consistently losing market share. They are now starting to realize that their only chance of continued growth depends on releasing more devices with different screen sizes and different price points. (Gasp -- more fragmentation).
It is up to Google to try to make programming across different devices as easy as possible. I am not sure how successful they are in this, I am not an android programmer. But fragmentation is not a choice or the result of a strategic error by Google. It is a fact of life when you are programming for hundreds of millions of users.
Think of it this way, if Google had chosen to go the Apple way and only used Android on their own Nexus devices, would there be more or less fragmentation? There would certainly be less fragmentation in Android, but there would be much more in mobile devices in general. Because Samsung, HTC, Sony and every other Android manufacturer would come up with their own wacky OS.
2. Apple losing market share to hoards of cheap spam-ware phones? I'm sure Google isn't as excited about this as you think.
> But fragmentation is not a choice or the result of a strategic error by Google.
I think it is. The choices aren't 1 screen size or any screen size. There is a third perfectly reasonable alternative that windows phone took, and that is a handful of sizes that are likely to satisfy 99% of people.
Samsung, Sony, Motorola were using Java ME but you cannot build just one app that works for all manufacturers.
If Android doesn't exists, we'll have 1 OS for each manufacturer because Apple would not share their OS with others.
I'll take a fragmented Android ecosystem over a fragmented mobile OS ecosystem any day.
I develop Android apps for a living. For a lot of devices (e.g. HTC One, Nexus 4, S3), there is very little differences in code, if at all.
Highlighting different versions is also misleading. Not much difference in the APIs between 4.0 and 4.3
I'm sure Microsoft would have been more than eager to take up the slack, or perhaps Palm would have pivoted that way.
I cannot remember what the update cycle was like on Microsoft phones. Perhaps the OS version would have still been an issue. I do seem to remember some upgrade blocks on the 7 version.
For Windows Mobile? In almost all cases, they never got upgrades at all. The iPhone was pretty unusual in its day as a non-computer consumer electronics device that got substantial software changes after release.
there are big differences between 2.3 and 4.0 though. 34% are still on 2.3, and that is sad.
With Android you really have to just cut your losses and realize you can't make it perfect for everyone. Target the top 70% and do the best you can. Handle the top few screen sizes and api versions and move on.
Then again, for certain situations, they may not. Of the two wildly different apps I work on, one has 40% of users on 2.3, and the other has 10%.
Nowadays we hardly think twice about the fact that there are millions of combinations of monitor and GPU brands and models and configurations. Has anyone ever thought to do a similar comparison of desktop and laptop "fragmentation"?
I'm also not sure Google wants to do that so badly. I think they're pretty content and comfortable with how Android is working right now, generally speaking.
For example, if my application depends on some feature delivered in 4.2, I need to be aware that my potential market is less than 5% of devices in the wild.
On the other hand, if the app is 100% compatible with the 2.3.X line, I can count on the all of the devices working, but I also should regression test with the updated versions to make sure that they work.
Otherwise we will be in situations like a friend was cursing me yesterday about how I dare have android 4.2 (and wait for 4.3 rom) on my unlocked 2010 device and he is stuck on his HTC with 4.1 and no signs of incoming upgrade soon.
I understand the necessity of the "rolling update" model in general, however in the case of Nexus machines it should not be necessary. At any rate, I should be able to opt out of the rolling update model and put myself at the front of the line without having to manually flash a factory image.
Caution though, apparently this breaks app updates for some people, but all you have to do is add and remove your google account to get them to work again.
Of course for many apps, if written properly, this simply doesn't matter - but if you try cram too much on-screen assuming 1280x800 means a 7" device your app may be difficult to use on 4" one.
Most of the people you see complaining about Android fragmentation are people that are avoiding Android because they are scared of it (rather than having tried to deal with it) or people who would prefer you to buy an iOS device that their app is already available for instead of an Android one that drops you out of their target market until such time as they port to Android.
> if you try cram too much on-screen assuming 1280x800 means a 7" device your app may be difficult to use on 4" one.
For the reason above, this just doesn’t follow. A 7" device would be about 600dp wide (in portrait), while a 4" phone would be about 320dp, regardless of pixel density. That’s not too different from iOS – the original iPad and the iPhone 5 have a similar number of pixels.
The OS thing is real and really worse than what is depicted because depending on the APIs you are using even OEM specific tweaks introduce additional variables.
The most important trend to notice is that Android operating system breakdowns are getting better.
4.x accounts for 60%~ market share. 2.3.x accounts for 34%.
Those are good signs.
DIGMA iDs10 3G
!QU SMILE advance
\002\""
(MC605CH)
*#? (^?^)=?
001DL
001HT
003Z
007HW
009Z
06_v89_hjy1
06_v89_jbla768_asx
> 47.5% - Samsung's share of those devices.
It seems implausible that Samsung has made 5,934 distinct Android devices.
Also many of those ROMs might only run on a dozen devices, trimming the long tail, remove say any ROM used by < 100 people, might be a good idea.
edit: it's working now
This is some great information to think about concerning Android fragmentation, and how, perhaps, it's not actually a bad thing.
Great diagrams anyway.
In other news, "DOS vs. VMS fragmentation", Only 5% of PC are manufactured by IBM, Digital manages to capture 100% of the VMS market!
Linux is even more "fragmented" than windows why would people even use it with all that scary fragmentation!