So while Android is technically an operating system, it's really an open platform on which to build mobile devices on top of. So the Android device I buy is that vendor's take on the hardware and the software. Google has its own take, as does Amazon, as does Samsung.
When viewed in that frame, it's not so frustrating or confusing, or even an actual problem. Fragmentation can be viewed as a natural consequence of the open Android ecosystem.
Take your analogy to the next step. Someone opens an online store that sells binary-only copies of applications targeted to just "Linux".. you would call them crazy, no? That's what the Google Market is. Or the Amazon Market, samsung apps, nook store, ...
I wrote a blog post to help you understand the pragmatic issues faced by an Android developer trying to write decent software.
Your analogy does not make me sleep better at night.
The problem is the API is huge, and the documentation isn't great either, so you're supposed to learn best practice from the apps in the OS source tree.
The function you are talking about only returns a single directory and my users want to use both if available.
It really isn't a big deal. Use reflection to find what works at runtime, and live with it. That's the price of the flexibility which makes the whole thing attractive in the first place.
The big problem is trying to cover all bases from the start: you won't. Attack it like an old school PC shareware dev, and respond to customer requests.
There are far larger problems with Android than this kind of thing. That things on external storage basically bypass the security model is a much bigger concern.
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.
Based on what? This is far from clear to me.
Users have flocked to a device with Just One Form Factor (iPhone), and its biggest competitor - Galaxy SII - is almost identical in this regard.
Users have some choice, yes. Users /want/ that choice ... much less clear.
1. Apple's strongest competitor, Samsung is probably the world record holder for number of different smartphone models / form factors sold simultaneously. Even with the Galaxy S II family as their top sellers, they aren't the bulk of its portfolio. While there are some experiments in there (like the Note was), I'm sure they're not setting that record just for the fun of it. If some people didn't want those choices, Samsung's smartphone strategy would not be viable.
2. The Galaxy S II isn't almost identical to the iPhone hardware. You can (and Apple and Samsung do) argue about the level of aesthetic similarity, but there are many hardware differences: size, screen, removable battery, microSD slot ... and all of these differences are things a customer can easily see in a store.
3. One of the dimensions that users obviously want choice is price - and that leads to hardware fragmentation all by itself (by using cheaper or more expensive components depending on the target price).
4. More than a few experienced iPhone users have specifically talked about switching from an iPhone to the Galaxy Note. They all talk about making the switch because of hardware differences.
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.
I don't see a personal attack in my message. Your original post suggested that android fragmentation is not a problem if I just think of it differently. A logical extension of that is that it's my fault for seeing it as a problem as I'm dealing with it incorrectly.
That doesn't make my users any happier. It doesn't make their bug reports go away. That doesn't make their phones all mount to the same mountpoint. It doesn't make me sleep better at night.
That's not an attack. Neither is claiming your viewpoint is one of a non-developer because pragmatically speaking a developer deals with these problems daily so "thinking of it differently" really makes no difference to the size of the problem.
Please don't accuse me of a logical fallacy here, thank you.
Distribution on Linux can be a similar nightmare. Try downloading a source package to find that it requires version 2.3 of LibExample, and you have version 2.2, but the developers didn't know they needed 2.3 and the configure script doesn't detect the discrepancy, so you get some cryptic compilation error halfway through. Binary distribution on Linux is possible, the Xonotic folks did it, but it's a lot of work. Android development is more forgiving since the API as a whole is versioned, but portable programming is still more work.
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.
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. 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.
 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.
You think that would cause the manufacturers to change their behavior in order to stay certified as Android compatible? I think that would lead the major manufacturers to fork Android, like Amazon has done for the Kindle Fire.
"If you do not support my Android phone for at least 2 years, with timely updates, I will never buy another phone from you, ever again."
Ultimately, I think it's on Google's head to do this. I've said in previous posts that Google should have handled the Android trademark a lot like how Mozilla handles their trademarks. Android, the OS, is free to use(both as in Speech and Beer), but if you're going to make major changes(i.e. the standard services and applications, limit install privileges, etc.), then the manufacturer cannot use the Android trademarks in their advertising, and can only use a "Powered by Android" mark.
Manufacturers that comply with Google's requirement could brand their phone as a full Android phone.
EDIT: Not sure why this was downvoted. Mozilla does protect their trademarks in this exact way: http://www.mozilla.org/foundation/trademarks/policy.html
The short version from http://source.android.com/faqs.html#compatibility :
'We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.'
With Android, you have to. Some devices will not be capable to run your app, in some others your app will not even fit the screen... And, of course, because of different drivers, hardware and OS versions your app will not absolutely work on some phones because of some weird error. It's nowhere near Linux development.
I don't know if fragmentation is good or bad for the users, but for developers it's an infinite source of headaches. From my experience (I develop a Twitter client for WP7), even with a system with much less fragmentation than Android, every phone has unique features which can make your app crash for no reason, and you can only wait to be randomly corrected or get that specific model and debugging the app.
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...
Androids main competition allows developers to reach a similar sized user base which targeting a tiny fraction of devices. When it comes time to decide which platform to support or which to support first the answer becomes moot.
If that is "not ... even an actual problem" under the frame of reference you're talking about... all that tells us is that that frame of reference is probably bad. Which sounds about right given that neither is desktop linux a great consumer success story nor are linux distro's held hostage by a third party.
Imagine if you had to wait for Time Warner's permission to update linux, oh I think that would be bad...
Obviously there are some huge differences, but it still feels very familiar to me. I don't think it'll play out the same though, given the quality and popularity of the Apple product this time around.
As much as I do appreciate Apple products, I'm glad they lost the PC revolution. I can't believe we'd have been better off building software for that closed system.
But I do think Google could do a lot more to centralize and standardize the platform and the app ecosystem.
Right now I can SSH into a vastly different array of hardware and update a roughly equivalent set of packages to get for example the latest rendering engine or security fixes. This is not possible at all on Android which is a joke. And I will never understand how people such as yourself can defend it.
Fragmentation is a huge issue for Android and it is only going to get worse unless Google does something about 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.
If people viewed this as an important problem worth solving, we'd see articles about how to do aspect-independent UIs, or apps that cleanly upgrade to gestures in Gingerbread+. Or cute workarounds for rendering bugs on the SGX vs. Mali vs. Tegra.
But we don't see any of that, because quite frankly most people don't care. Outside of stuff that directly faces hardware APIs, Android apps port quite well in the real world.
Contrast, for example, the web development world. There, platform compatibility issues have been a huge problem for years, spawned a bunch of frameworks to abstract the differences, and inspired sites like caniuse.com. The clear lack of these in the Android world is, I argue, an existence proof that "fragmentation" is a red herring.
Develop better abstraction layers for hardware? Force manufacturers to use only a few resolutions like 480x320, 800x480 and 1280x720 (retina) for phones, and only 1280x800 and 2560x1600 (retina) for tablets?
What can Google do so that Android still supports many different devices from different manufacturers, but the fragmentation issue is dramatically minimized?
- Release new versions faster? Nope. More fragmentation.
- Pressure MOs/OEMs to only ship latest versions? Nope. Just pisses them off and makes them more inclined to fork.
- Reduce flexiblilty (better abstraction layers for hardware) ala WP7? Nope. MOs/OEMs care most about flexibility which got them on Android to begin with. They'll just fork.
- Do something really innovative. 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.
Android is alive and well. It is an extremely healthy ecosystem. But it is no longer Google's ecosystem. And it will continue to fragment no matter what Google tries.
FWIW, I wrote about this in depth earlier this year in a post titled "Fragmentation is not the End of Android" here:
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.
People act like Google is somehow unique here. Microsoft and Linux support a vastly more complex array of hardware configurations and still manages to support a diverse ecosystem above the core OS.
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?
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.
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.
What problem? The linked article could as easily have been called "The Diversity of Android". That title would have been more honest, if less likely to get linked.
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.
And no, you don't need to test against all of those configurations. Did the linked product? No. They used the incendiary fragmentation line because it gets hit, but actually point to no specific problem with it (besides, bizarrely, pointing out that Google has added functionality to scale for screen sizes...which has been a fundamental part of the Android development suite since day 1).
And there is nothing magic about Android working on different devices i.e. it's not like ICS works on them. They just are running old versions of Android.
Just to be clear, you're the guy who "researched" Android by looking at the public, everyone-knows-about-it Platform Versions breakdown this morning. And you're schooling me on Android. Delightful.
I have actual public apps. The only real issue are a small number of devices where the HAL essentially lies (which leads to the blacklisting of the handset), and understanding the different GPU architectures and their limitations / benefits (#1 issue people have is when they commit to a proprietary vendor texture format and then try to do runtime conversions. Bad idea. Just use ETC1 and shader transparency). Big deal. I get paid for my development so I suck it up.
And the problems with Android are far, far beyond just GPU issues. It is the fact that the most popular devices are also the ones running old versions.
By developing against the latest major version, you are going to reach 5% of Android users. Compare that to iOS, where developing for the latest major version (5.0+) means reaching maybe 80% of users.
ICS uptake, however, has been ploddingly slow. It's finally breaking through now as the vendors clear out their holiday inventory and start pushing new models.
So the process for developing a new iOS app today is:
1. Download latest SDK
2. Develop for iOS 5.1
1. Download latest SDK
2. Develop for Android 2.3
Also, my memory is that something like 20-30% of iOS users weren't on 5 yet. Is that wrong?
We also had quite some support requests for a three digit dollar app (!) because customers never bothered to update their iPad, the OS versions were all over the place.
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.
If I where to make a prediction, I suspect we're set for a future where Android 2 is the OS of choice for low end smart phones and Android 4 is the OS for high end smart phones, and developers who want to target both the high and low end of the market will be required to support both Android 2 and Android 4 for years to come.
Having lots of different screen sizes is never "fragmentation". Having different versions of Android? Maybe.
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.
I recently co-created an automated web-service that tests apps on real devices, and of the thousands of tests we've run, the majority of the failures and errors are more general software development issues. Errors caused by assumptions about the presence of other apps or network connectivity or the inability to handle certain transitions like screen orientation are much more common than device-specific problems like CPU type. It does happen, for sure, but not nearly as often, and free services like ours seek to mitigate these errors altogether.
It should bring a lot more stock devices into the market. Manufacturers will be able to upgrade their devices faster, and if Google is smart, they will stick with 1 major release per year rather than 2, and this way manufacturers will have to upgrade their devices only twice in 2 years, rather than 4 times. And we won't have this problem of being "2 versions behind".
"Google to sell flagship Nexus devices with multiple partners this fall, reports WSJ"
linking verge because, paywall.
Apparently google read my comment below, made a major business decision and leaked that to the WSJ all in the last hour.
"Well they could keep their major vendors in the loop instead of just dumping the new code on them after each nexus launch..."
I'm tired of seeing "Android" cited as a single OS in all kinds of statistics, when in fact it's a pile of proprietarily hacked OSes with a common heritage.
This person doesn't understand WTF fragmentation is.