The behavior of the Android Telephony/Signal APIs which OpenSignal depends on varies widely across phones. Many Samsung phones don't implement these well at all, bummer considering they are very popular handsets.<p>One of the things that makes Mobile development interesting to me is the mobile context, unlike the static context of desktop computing. But being smart in the mobile context requires using sensors, and this hardware boundary is where we see a lot of behavioral differences among Android phones (fragmentation). The existing CTS doesn't do a good enough job here. Its where the fragmentation is the worst - in the interesting APIs.<p>Also, the fragmentation problem for me is also about Google being able to deliver features to users at a reasonable speed. They can with the Nexus, but the Nexus was and is not likely to ever be a commercial success. Its mainly HW for the Google engineers to dev on, and they make a few more for us.<p>Bluetooth low energy was announced in 4.3. How long will it take for that feature to arrive for a sizable number of users?<p>What about the limitations of dvm? For example, its 65k method limit for APKs. How can Google fix this when they can't get everybody on the same page in a reasonable amount of time? Its this kind of fragmentation that hurts.<p>If you're building some basic CRUD app, don't worry. If you want to make interesting nontrivial apps that touch many APIS - especially HW APIS, that when you have to watch out - and have a very good testing plan.
Interesting that they declare phones with less than 4" diagonal screens to be barely smartphones, when that's the size of all iPhones before the 5...
Dealing with fragmentation? Null check!<p>I'm seeing a lot of apps that assume too much. They assume I've got GPS. And even if I had GPS they assume it is turned on. Same for Wifi or any data connection. Therefore a lot of crashes occur because of null pointer exceptions.<p>The simple fix is ofcourse to null check or to use a little more of try and catch.
Android fragmentation - do you want to support 2.3 or not? After that it's about as annoying as responsive design is - possibly less for certain apps.<p>The challenge is of course backporting an app developed for 4.0 or frontporting an old app in the new API. That is definitely a pain.
The biggest problem I see from experience is memory limitations impacting design.<p>I have a republic wireless android phone that ships with very little free memory until you root it. Have to be Very careful and pick and choose which apps you install based on size. Is it worth uninstalling evernote to fit this new app? Or is your new app worth the $100/month it would cost to switch to a carrier with a more advanced phone where space wouldn't matter?<p>I also have a 32 gig nexus7 tablet where I pretty much don't have to care about app size. 500 meg game, well OK whatever.<p>The article advises fooling around with different UI depending on device size. Users actually hate that. I can't stand how baconreader renders differently on my phone and on my tablet, when they should be the same. gmail is another offender. I want the phone gmail on my tablet and the tablet baconreader on my phone (or was it the other way around?) Users can understand screen and finger size issues but can't tolerate arbitrary foolin around with UI design.
"Versions before 2.2 are ancient by smartphone standards and can therefore also be ignored, just like most developers ignore iOS 3.0 and earlier."<p>In fact, the current Xcode version only enables developers to target iOS 4.3 and above. So even if a developer would want to support 3.0, he would not be able to do so.
I only deal with iOS, so excuse my ignorance, however the following statement from the article is puzzling:<p>"While Android fragmentation is increasing, the development time for developers is not."<p>Because earlier in the article it states this:<p>"Whenever we have a new release we spend about four hours testing the new build on all the devices. In total we estimate the extra effort of fixing device or vendor specific crashes to add 10% to our development time."<p>So it seems a bit inconsistent. If there is more fragmentation, then that 10% development time figure would necessarily have to increase.<p>I would be interested in the data demonstrating the cost-benefit analysis of supporting the high fragmentation as opposed to just supporting the the OS version with the highest penetration. I'm not arguing either way, but it would be interesting to see the effect on revenue. My hypothesis is that older OSes would likely result in less revenue (than newer OSes), so the question would be if the revenue would exceed the percentage of development cost dedicated to the particular OS in question. I really have no idea.
> (I use the numbering scheme since the numbers are more precise than the associated names. “Jelly Bean,” for example, refers to both 4.0, 4.1, 4.2 and 4.3).<p>4.0.X is Ice Cream Sandwich, not Jelly Bean.
While the headline talks about Android fragmentation he is only discussing Android <i>phone</i> fragmentation. If you want/need to support tablets the problem gets a lot harder.