Android Fragmentation Visualized(opensignalmaps.com)
opensignalmaps.com
Android Fragmentation Visualized
http://opensignalmaps.com/reports/fragmentation.php?
90 comments
Spoken like someone who isn't an Android developer.
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.
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.
Your blog post blames a bug on Android fragmentation, but it sounds like it was your fault. You were not calling Environment.getExternalStorageDirectory(), which is the portable way of accessing the storage area where users saves file via USB mount.
I tend to find that with Android success is directly proportional to how much the platform is embraced as it is. Many people seem to approach it as a slightly different Linux, iOS or J2ME/J2SE and get very disappointed. If you fight it it will bite you in exactly that sort of way.
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 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.
That API call is not sufficient. Some devices have more than one external storage device. For example some tablets have an internal storage point and the ability to have a USB key.
The function you are talking about only returns a single directory and my users want to use both if available.
The function you are talking about only returns a single directory and my users want to use both if available.
Yeah, and Motorola have their own etc.
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.
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.
The brutal part is that generally customer requests are no better than "the bug is shitty app" or just "buggggggg". Thats where a responsive strategy sucks - reliable reports are few and far between.
On fragmentation, your blog post is exactly backwards.
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.
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.
> [hardware fragmentation is] exactly the fragmentation the consumer wants
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.
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.
I think there's plenty of evidence that users want the hardware choices they make:
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.
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.
Add to that the fact that every device has a different processor model, gpu, and most of the software on the device is locked.
Right, the problem is with the Google Market, Amazon Market, et. al. It's not with Android as a platform (or operating system).
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.
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.
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.
That's a horrible idea. Instead of hardware fragmentation we'd be stuck with market fragmentation. I have zero confidence in the manufacturers' abilities to foster a good marketplace. And they would have a monetary incentive to disable access to other marketplaces and sideloading, so there wouldn't be any competition, either.
So because it's a "natural consequence" it's not an actual problem? Sorry.
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.
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.
>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.
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.
The alternative isn't for all these devices of different sizes and capabilities not to exist. The alternative is for them all the be running even more disparate, vendor-specific operating systems. We should be thankful for the degree of unification Android's success has brought.
One of the annoyances I've had with Android, from a new consumer's point of view, is that it's presented as this monolithic OS that's the same across every phone. But once you do the research, you find that it's really not. Except for the Nexus line, there really isn't a "Google Android" experience. When you buy an Android device, you're really buying HTC's, Samsung's, Amazon's or Motorola's Android. Every device has different capabilities. Some ship with different Google services out of the box, others ship with their own internal apps. Google's Android strategy is that every manufacturer can make their own Android shell, without placing any requirements on the vendors as to what version of Android they're using.
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.
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.
"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."
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.
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.
This is a failure of Google to implement a forward-thinking license.
Actually, the real solution is a pledge that customers should make:
"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."
"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."
Unfortunately, I don't that any of the manufacturers would listen to that.
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
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 current rules a device must meet to use the android trademark are at http://source.android.com/compatibility/4.0/android-4.0-cdd....
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.'
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.'
But there is a huge difference. First, that desktop OS are ready for differences in hardware. As a developer, you usually don't care about screen size, or processor, or memory.
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.
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.
I don't think so. Even desktop OSes are not ready for such vast differences of today's hardwares.
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...
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...
"When viewed in that frame, it's not so frustrating or confusing, or even an actual problem"
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...
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...
One difference between different linux distros and android is that, in the former case, end users recognize that software written for another distro may not work on their specific OS. In the latter case, however, end users (especially ones that aren't technical) think that they have the same OS (when in reality they all own phones with different levels of API support / compatibility) and are upset when a specific app does not work as expected on their device.
It actually reminds me of the Personal Computer when I was growing up. There was Apple (a bit of a mushroom very few people had) and IBM (your dad's business computer), plus a whole bunch of IBM clones (even Samsung made one). All of the clones ran the same OS (or version thereof).
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.
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.
It's close to that, but not quite. Android is a bit more centralized, so apps are pretty much guaranteed to work on all versions of Android, while on Linux you need different packages for different distros and so on.
But I do think Google could do a lot more to centralize and standardize the platform and the app ecosystem.
But I do think Google could do a lot more to centralize and standardize the platform and the app ecosystem.
The difference is Linux has its act together. Android doesn't.
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.
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.
I'm not defending it, I'm explaining 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.
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.
The messy truth is that Google has created only a half-open ecosystem. 98%+ of Android users are at the mercy of the carriers and handset makers for updates. That's not a truly open ecosystem.
Even if 100% of users were at the mercy of carriers and handset makers, that just underscores that 'Google can't "do something about it"'; it doesn't even mean the platform is not "open", as you are mistaking open devices for open software: the platform is, in fact, so open that carriers and handset manufacturers are allowed to make arbitrary modifications and sell closed devices running the result.
I think a better analogy is a web browser. There are many versions, many resolutions, but they all roughly support the same API, while modern browsers have more features.
Correct, Android is more of a meta-platform, a platform for building platforms, than a single platform itself.
I love my Android phone and I love developing for it but I sort of think that sometimes we have a little bit of Stockholm syndrome when I hear another Android developer say "fragmentation is great!." It really isn't, especially not with the differences between 2.3 and 3+, but I like being able to put my own apps on my phone without paying $99 a year, so I like my phone quite a bit.
I'd tend to agree. But at the same time I do get sick of all the articles like this one harping on "fragmentation" instead of actual porting issues. That's the clue that tells me the linked article was written by Apple fans with an axe to grind.
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.
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.
[deleted]
I think for Asian developers, specially in China, fragmentation is a HUGE problem. There are literally hundreds of variations of cheap Android phones out there with different screen sizes, OS versions, etc. We replace our phones regularly here in the US and have access to the latest phones from Samsung, etc. but that is not the case in most parts of Asia.
I don't think it is that simple. In Asia, which is ground zero for non-Google Android devices, fragmentation is certainly a problem, but the absence of fragmentation would have been far worse. Without fragmenting an open-source Android, manufacturers just wouldn't have been able to make and sell the cheap smartphones Asian developers are targeting.
So what can Google do to reduce the problem? Release only one major version of Android every year? Every 3 years like Windows? Release a private "beta" version for most manufacturers (not just one like now) so that they all have devices with the new OS on the official launch day?
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?
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?
There is nothing Google can do about it. The cat is out of the bag, so to speak. Everything they try will simply make the problem worse.
- 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:
http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...
- 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:
http://ceklog.kindel.com/2012/01/14/fragmentation-is-not-the...
>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.
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.
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.
[deleted]
Do what Sun did for Java, create a really extensive test suite and make sure no device gets the Google stamp of approval unless it passes.
They really need to structure the OS so that the core components can be updated independent of the vendor ones. Then just ship updates regardless of what vendors do.
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.
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.
> They really need to structure the OS so that the core components can be updated independent of the vendor ones. Then just ship updates regardless of what vendors do.
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?
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?
Not sure why downvoted this is certainly the biggest thing Google can do to help alleviate fragmentation.
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.
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.
What a terribly obvious misnomer.
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.
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.
So what can Google do to reduce the problem?
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.
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.
Diversity is all well and nice, but how do developers possibly test against all those configurations? If you don't test - how do you ensure that as low as possible a percentage won't return your app, and ding your ratings simply because their phone has issues with your software?
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.
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.
The Android ecosystem is an incredible success. There is massive compatibility, with very few issues, across thousands of devices from weak to powerful, big and small. Maybe Google actually did something right?
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 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).
Very few issues ? Clearly you don't know what your talking about. I work in a team that does Android and mobile website development. We NEED 20+ devices versus 4 for Apple. And there are lots of vendor specific issues which require you to own those devices even just for comparing web site rendering behavior.
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.
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.
I work in a team that does Android and mobile website development. We NEED 20+ devices versus 4 for Apple
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.
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.
I didn't research anything. I work for a large multinational and our team is responsible for some of the most popular public apps and websites on the entire platform. So yes. I see first hand what it takes to support them.
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.
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.
Ugh, ignore the research comment. Somehow I mixed up your nick with the other guy who referred to that. Face red.
I did some research this morning, since I might be doing some Android work soon. As of May 1 2012, about 5% are on any version of the latest major release: Ice Cream Sandwich. About 3% are on the previous major version: Honeycomb. The rest, a whopping 92%, are still two or more major versions behind.
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.
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.
You're mixing things up, so I'd suggest going back to do more research. Honeycomb was tablet-only, it was never released for handsets. That's like complaining that only 7% (or whatever) of iOS users can run iPad apps, it's meaningless.
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.
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.
Yeah, I'm not up to speed on Android. But, so, that only accounts for 3% of the users. It still means only %5 are on ICS, and the rest are basically on 2.3.
So the process for developing a new iOS app today is:
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.3Pretty much, yes. New features in ICS need to be viewed as optional and probed if you're going to use them. Though to be fair there really aren't that many you'd really want -- ICS focused more on the core apps and user experience than it did on extending the platform APIs.
Also, my memory is that something like 20-30% of iOS users weren't on 5 yet. Is that wrong?
Also, my memory is that something like 20-30% of iOS users weren't on 5 yet. Is that wrong?
About 80% of users are on iOS 5.0+, so, 20% are < 5.0. But the 20% that are < 5.0 are not the ones that will be downloading and installing fancy new apps. If they were big app consumers, they would update the OS.
The iPhone 3G is stuck on iOS 4.2.1. When I still had my 3G, I happily bought apps if they still ran.
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.
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.
This graph is interesting: http://david-smith.org/blog/2012/05/11/ios-5-dot-1-1-upgrade...
The compatibility library gives a developer a lot of pieces from the latest versions of the SDK that one might wish to use. Also ActionBarSherlock (http://actionbarsherlock.com/) is an excellent library that will allow one to create solid looking apps using Fragments and the ActionBar on older versions of the OS.
See what you wrote though ? "As vendors .. start pushing new models".
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.
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.
I don't disagree at all; you're inferring an argument I didn't make. Nonetheless uptake of ICS is increasing, and the driver is that vendors are shipping new handsets.
But they're also shipping at least as many new handsets with 2.3. Sony, Samsung and Motorola have all released new handsets in 2012 running 2.3. Until vendors stop shipping 2.3 on their new phones fragmentation will simply be a fact of life for android developers.
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.
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.
Honeycomb was not the previous major version. It was a version released only for tablets. The previous major version for mobile/tablets was Gingerbread (2.3).
You could also say that you get 6-12 months to develop for the new version once it's launched, without the users crying foul for not getting it early.
There seems to be a tendency to use 'fragmentation' to imply something vaguely negative - a kind of problematic deviation from the norm. I Prefer to think of it as diversity.
I think it depends on your perspective on things. As a consumer I love the diversity of the Android landscape. As a developer I dislike the fragmentation of the Android landscape.
As a consumer I agree with you. As a developer, any frustration I have with the frag... ah diversity of Android is more than offset by the greater potential that it offers me.
yes, or "choice".
Having lots of different screen sizes is never "fragmentation". Having different versions of Android? Maybe.
Having lots of different screen sizes is never "fragmentation". Having different versions of Android? Maybe.
Could you guys get a simple histogram of the model data up? The 2d visualization is clever, but it does not tell me what I need to know: does the distribution have a long tail or not? It sort of looks like it does, but the visualization obscures the truth and prevents comparison with similar datasets.
Not the same thing, but Android Police put together a decent histogram of Platform Versions: http://www.androidpolice.com/2012/04/27/the-big-android-char...
yeah very true, we'll try and throw one up to show that a little more clearly
I too would be thankful for that. Sometimes, simple histogram is the best way to show something. And while you're at it, I think that cumulative version chart would be interesting for readers as well.
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.
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.
Thanks! The data is killer, btw.
I love information like this, and I think the OpenSignalMaps opinion is healthy. Basically, it's cool to have an install base this diverse and dynamic. Maybe this is because I come from a traditional desktop dev background where diverse HW and SW environments were just part of the game.
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.
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.
I think this is a major move in the right direction:
http://www.theverge.com/2012/5/15/3022682/google-direct-sale...
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".
http://www.theverge.com/2012/5/15/3022682/google-direct-sale...
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".
Good news everyone:
"Google to sell flagship Nexus devices with multiple partners this fall, reports WSJ"
http://www.theverge.com/2012/5/15/3022682/google-direct-sale...
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.
Me ITT:
"Well they could keep their major vendors in the loop instead of just dumping the new code on them after each nexus launch..."
"Google to sell flagship Nexus devices with multiple partners this fall, reports WSJ"
http://www.theverge.com/2012/5/15/3022682/google-direct-sale...
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.
Me ITT:
"Well they could keep their major vendors in the loop instead of just dumping the new code on them after each nexus launch..."
[deleted]
Also: Michael DeGusta's chart from Oct 2011
http://theunderstatement.com/post/11982112928/android-orphan...
http://theunderstatement.com/post/11982112928/android-orphan...
Disappointing post. I was expecting a graph of the dozens (or more) versions of "Android" running around on devices that are being sold today.
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.
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.
"Fragmentation allows users to take their pick from thousands of devices."
This person doesn't understand WTF fragmentation is.
This person doesn't understand WTF fragmentation is.
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.