The discussion should be around "What is it that people without the latest hardware / OS version can't do?" not "What number does your phone say under OS version?"
This benefits users, but not developers. Developers still need to code and test against old API levels.
http://developer.android.com/google/play-services/index.html
These features are made available on older releases of Android.
cf. http://en.wikipedia.org/wiki/Android_version_history#Android... http://en.wikipedia.org/wiki/IOS_6 http://developer.android.com/about/dashboards/index.html http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-d...
I gripe about having to support an OS that Apple shipped in Q3 2012. Semi-mandatory Android 2.3 support is a fragmentation problem, especially when you mix in all the crazy shit some handset makers and carriers have done to 'improve' Android.
See, for instance, http://techcrunch.com/2012/06/02/android-qa-testing-quality-...
Only for spoiled iOS developers.
I used to develop for Windows, starting in pre-1995. Want to talk about fragmentation? With dozens of video cards, each with their own custom APIs for doing anything that standard VGA couldn't handle, dozens of sound cards with varying levels of support for the de facto standard(s), memory configurations from 128k through multiple megabytes, BIOS variations, and even CPU bugs in AMD or other non-Intel chips...and then tons of software that might be running on top of your app (drivers and such)? THAT was fragmentation.
Windows 95 and later (specifically after DirectX was introduced) reduced THOSE problems significantly, but new ones surfaced, anti-virus and firewall packages being the worst, though some video cards still have bugs that break things randomly.
You think having to support 2.3 qualifies as a problem? JUST having to support 2.3 is a dream compared to what we used to have to deal with. The compatibility libraries -- especially the latest versions -- do a great job of making apps work everywhere. And if you're using OpenGL, you have even fewer compatibility issues to worry about.
Get off my lawn. ;)
Then I start to get really annoyed at the level of shit of I have to support for Android and the backwards and forwards on testing and just seriously wish the company didn't support it all.
Actually TBH, I only took up looking after the mobile suite as a learning thing. And what I learnt is I'd rather be doing other forms of software (almost exclusively due to time pressures and android). The experience has been less rewarding that other forms of development I've done.
I'd never work on Android products again without a proper team (project manager, QA etc...) so someone else could fight the battle of more development time every iteration instead of me.
While Google's cheap handset initiative embodied in Nexus 5 will ameliorate problem a bit by giving people incentive to upgrade, it is not nearly enough. I would like to see Google do more to address growing complexity of fragmentation.
I really don't get why some people make a huge fuss about it on Android.
Rapid, very different hardware variants- Screen size, cpu power, GPU power, storage mechanisms. Software: 3d Apis, third party Apis, if you want to take advantage of a new framework you may not be able to because of people either unwilling to, or not able to upgrade.
It's completely different from the PC world.
Because the app store is a race to the bottom, I don't want to create an Android app that works well only on the latest devices and have someone else copy it and make it available for all other platforms. This fear is enough to keep me from executing any ideas on the mobile platform.
I still focus on web applications and HTML5 because eventually everyone will be on a phone powerful enough to use it.
Cross-platform development with PhoneGap or similar is also trivial, and isn't hard to make work on (almost) all devices.
PhoneGap I'm not so sure about because people seem to be walking away from it and writing native applications instead because they were frustrated by performance. Now, I'm sure there's success story.
My current project runs a test suite (as well as some light adhoc testing) on 6-7 devices (across screen densities and carriers) and that seems to catch most of the issues without spending $20k on a device lab. (We use the excellent Spoon library by Square: http://square.github.io/spoon/)
Screen sizes are not an issue for anyone that's shipped a non-toy app. API levels are not so bad - though you will find yourself using the Support Libraries even in cases when they shouldn't be needed.
BTW: Android provides a weekly report of OS/screen sizes etc that access the Play Store: http://developer.android.com/about/dashboards/index.html Use this (not a random blog post) to make informed decisions for your clients on your minSdkVersion.
Now if you want to talk about a real headache for Android developers, let's talk about Fragments - not fragmentation :)
No problem here though, if you think 1+ billion users don't deserve a few dev hours, you may as well code for another platform. Same goes if you think targeting anything less that 1+ billion users is problematic.
