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.
http://burnsmod.com/development/2012/05/01/Android-Fragmenta...
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[1]. So the result is that they have to support around 4 different codelines at the same time(ICS, HC, Gingerbread, and Froyo).
It's a problem for developers because your display code might not look right on a new device with a weird screen resolution. Or you might need API calls that are only in 4.0, which would lock you out of 90% of the devices right now.
No, the alternative is for Google to exert control over the device manufacturers and state that if they're going to be using the Android OS, they need to support and update their devices to the latest version for at least 2 years after the phones are released.
[1] There is a good economic argument that patching phones that are 18 months old with 24 month contracts about to be up just doesn't make sense, but honestly, it comes down to that the manufacturers just aren't willing to do it.
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.
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.