Dealing with Android fragmentation – experiences from our startup | Hacker News Reader

Dealing with Android fragmentation – experiences from our startup

blog.instabridge.com

58 pointsniklas_a35 comments

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.

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.

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.

Bluetooth low energy was announced in 4.3. How long will it take for that feature to arrive for a sizable number of users?

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.

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.

I have had a few interesting problems with Samsung handsets over the past year as well. A couple examples I've observed:

* Samsung S3/Note2 - requestSingleLocationUpdate() would never return a location to the listener, where starting the location listener and then stopping it when you get your first result works fine...

* Samsung S3 (4.0.4) - onResume() then onPause() was being called repeatedly after the device blanked the screen (the time varies before it starts freaking out and calling onResume) - I observed it wait 7 minutes, then start calling onResume/onPause a few times per minute.

edit: formatting

I think several big selling phones had Bluetooth BLE before it was baked into the platform, so it really depends on what you mean by sizable number of users. The fact that it's hardware dependant too, somewhat limits the adoption.

They were advertised, but only the S4 and Note2 had BLE that came close to working...

though "Close to working" is as good as I can say for my wife's Note2... it was extremely flakey and loses connection all the time.

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...

I was recently dragged into a Verizon store by a nontechnical friend to help with buying a second smartphone. I let them browse for a while then asked them what they thought about what they saw. I was actually thinking of recommending an iPhone since they really do offer a simpler interaction model over the rest.

After a couple questions I realized that she couldn't figure out which ones were the iPhones from the Android from the Windows Phone. So I walked around with her to the phones that she liked and answered a few questions about each (storage, battery, if it was a popular phone that sort of thing). I realized that she hadn't even checked out the iPhones at all. They were kept over in a special Apple section of the store, and from a distance looked like the small budget smart phones they had elsewhere in the store. So she had skipped them entirely. All of the phones she liked were in the larger screen sizes.

I took her over to them and the conversation went something like this, "and these are the famous iPhones, give them a try, they're really easy to use." She messed with it a bit, "isn't there a bigger one, like the other phones?" I pointed out that it's designed to be easier to use in one hand, for people on the go. "But it's so small, it's hard to see things on the screen, I have to hold it so close" She pointed to the iPad mini they had there "something in-between that one and this one"

And that was that, it came down to a decision between the Droid MAXX, the Galaxy S4 and the Galaxy Note II. She walked out with an S4.

Ooh ooh, if we're playing anectodal data game day I'll pitch in too.

One girl I knew was complaining about how big her phone is and asked me about my 4s at the time so I let her try it out. She decided she'd get the 5 right after it was out because her current phone was "too damn big to text with easily". I pointed out she could install a different launcher/keyboard but her phone had never been updated.

This is the problem with anecdotes. The plural is not data.

I also know a fair amount of women primarily that have iphones because they don't like the giant android phones. But again, could just be my friends, where I live, the alignments of whatever influencing buying decisions.

I'm getting more annoyed with all of these "my anecdote X which reinforces view Y means company FOO should BLAH" comments. They don't really contribute to actual discussion of the technical problems at hand, which are interesting. Hopefully that didn't come off too harsh as its just intended to spark more of a discussion of can we please stop with anecdotes in these stories in future? Pretty please? If you come to the twin cities I'll even buy you beer, or if we're ever in the same spot. I'm not above bribing.

You might be reading too much into the comment.

For both your and parent's anecdote, screen size was the primary determinant for this user. I wouldn't be surprised if that's common.

It's a good reminder that many people don't buy a device based on the topics we discuss a lot like openness, lock-in, carriers, and fragmentation.

Right. She actually like the way the Windows phone hardware looked the best -- it's colorful and different looking than everything else. But I think she would have bought an iPhone to be honest just based on name recognition if Apple would offer competitive sizes. With the way it was presented in the store, it had as much sales sex appeal as the aging netbook display to one side of it and the feature phone display behind it.

The iPhone 5 just absolutely mystifies me, they had a 4 and 4s for sale there too but unless you hold the phones right next to one another and see the extra row of icons on the screen, they're virtually indistinguishable as products to most people, yet the 5 costs much more. To a nontechnical buyer it seems inexplicable that this extra row of icons costs $100-$200 difference in price. Even digging into the specs, I couldn't really make a case for the 5 over the 4 series without getting into technical specs she didn't care about. Her comments were "the 5 is the new one, but I'm getting price gouged for it, and the 4 is on the way out...and these other phones are really popular too"

In the store, with all of the important context clues that stores put around flagship products, the iPhone section felt like it was selling to a market that was quickly disappearing. Like selling incredibly nice horsewhips at a car dealership.

Even Nintendo sells two sizes of their portables.

All I'm saying is, Apple would have made a sale that day if they offered a slightly larger product in addition to their already popular one. They don't offer it, and they lost a customer. I'd imagine this same decision happens thousands of times a day and it's bizarre that they haven't identified that market segment as one to compete in.

Apple took it's sweet time to get into the small tablet market, and now is selling iPad minis like they're going out of style. Why not get into the slightly larger smartphone market which has already proven itself to be at least as popular a segment as the niche the iPhone is in.

The S4 size tends to do poorly with women (not just anecdotally, but based on market surveys.) It's large enough that it won't fit into their pockets. But if you go even larger (Galaxy Note) then women start to find the larger size okay, because they're going to put in their purse/bag anyway (but men now find they can't fit it in their pocket easily, so they dislike that size jump more.)

So the 4" and 6-7" sizes end up being more popular for women, while the 5" sizes do worse, because they're not as big as the Notes but still too big to fit in a woman's pocket.

(Similarly, there's appeal to the 7" size for guys because it's something you can fit in a jacket pocket.)

Dealing with fragmentation? Null check!

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.

The simple fix is ofcourse to null check or to use a little more of try and catch.

Most apps aren't really useful without a data connection of some sort, games might be an exception but then most of them would need advertising revenue to continue development and ads require an internet connection.

No apps are really useful if they crash on startup...

I'd argue the complete opposite: that is, most apps that don't work without a data connection aren't useful.

Specifically, most apps should be able to perform their functions off-line. Why? Because mobile data is expensive and unpredictable in a lot of countries. You can't expect that 3G will be on and working, and you can't expect that someone will be inside wifi.

FWIW, anecdata and all that, the majority of people I know in NZ prepay for data in chunks that roll over multiple months, and so they only turn on 3G when absolutely necessary.

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.

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.

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?

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.

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.

So, by "memory", you mean internal storage, not RAM?

They are two different things, with their own problems,so it is better to try to be precise.

Yes, although I imagine there are devices that are RAM limited.

I have enough ram not to be ram limited, but for example per my "running" tab, tunein radio pro burns up about 20 megs continuously. No idea why and I don't think I'm getting 20 megs worth of battery draining "anything" out of it. Too bad, because when I'm actually using it, its an awesome app. Google Goggles burns a bit less than 6 megs continuously, even if you're not using it, to do... what exactly?

This all costs battery, if nothing else. I'd rather have an extra hour of runtime rather than goggles and tunein starting up slightly faster when I use them.

There should be a configurable android setting where "piggish" apps can ask to start a battery sucking and ram sucking 24x7x365 service, but this specific app is simply not allowed to do so because its a pig-app.

"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."

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.

On the other hand, iOS3 can also be safely ignored because it's a completely insignificant part of the userbase: early june studies showed an install base of 0.1% on phones (0.6% on tablets).

By comparison 2.5% of the android userbase was still on 2.2[0]. Though things look good as it's been falling fast (2.2 was over 8% in february)

[0] http://www.gsmarena.com/android_in_july_41_jb_now_more_popul...

This still doesn't change the fact that phones using 2.2 are ancient and users are probably uninterested in downloading apps, so you can safely ignore them.

It's a high percentage, but mainly because of negative selection. People who don't care about apps bought cheapest Android phones.

I wish Google disclosed more statistics than "worldwide active users" for the Android versions.

If they published additional details, for example:

* filtering by country/city,

* filtering by age or demographics,

* "total money spent on apps" instead of active users,

then developers could be more confident in supporting 4.0+ only (and convincing their clients or employers to do so).

> This still doesn't change the fact that phones using 2.2 are ancient and users are probably uninterested in downloading apps

That is a completely unsupported assertion.

The article is about versions before 2.2. So, 2.2 and it's 2.5% are "supported".

Excellent point, I had misread that part. So it's only Eclair's much lower 1.2% which are ignored.

I only deal with iOS, so excuse my ignorance, however the following statement from the article is puzzling:

"While Android fragmentation is increasing, the development time for developers is not."

Because earlier in the article it states this:

"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."

So it seems a bit inconsistent. If there is more fragmentation, then that 10% development time figure would necessarily have to increase.

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.

You also have early adopter syndrome where people who know about fragmentation assume you won't support their phone, even if you do, even if you later add support.

Oh, $app? I heard about $app but it didn't support my phone on launch day, so I ignored them and installed a competitor who works everywhere. Oh, $app added support for my phone 6 months ago? Who cares, I've had $competitor installed for 7 months.

i think they are saying there is fragmentation, but they can effectively group the different fragments into this much smaller list of buckets by the 5 major versions and the 3 screen size ranges. that leads to 15 possibly combinations, ( although i doubt an android 2.2 phone will have a big screen size and so on... ) So until a new major category comes out they still have there 10-15 "groups" of devices to test...

> (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).

4.0.X is Ice Cream Sandwich, not Jelly Bean.

Which proves his point beautifully. I have no idea what version the silly names refer to being an iPhone user. I do know them by their numeric identifiers though.

They are just fun code names. Nominally textual rather than nominally numeric.

I think they're all supposed to be desserts. Akin to how all releases of OSX have cat names. Until the last one. Combo breaker!

While the headline talks about Android fragmentation he is only discussing Android phone fragmentation. If you want/need to support tablets the problem gets a lot harder.

What are common vendor specific issues that cause crashes?

Crappy OpenGL drivers are a common device-specific problem.

Reply on news.ycombinator.com