Everybody talks about Android fragmentation. I have felt it. Inside me. It hurts.

For many apps, fragmentation isn't such a big issue. If you're building an app for a summer festival, all you need to handle is different screen sizes and it will work everywhere. Well, not really but you'll get there eventually.

There are however other types of apps:

• Games
• Apps that interact with hardware

The main issue with games is performance. Good games are fine-tuned for the hardware and it's hard to fine-tune for thousands of different devices. I haven't ported any games to Android so I won't comment. Enough others have done it.

I will also let aside the very upsetting fact that manufacturers like to remove languages or fonts. My small Sony Xperia Mini Pro has all languages and fonts, including Hindi, proving that the now old Android 2.1 provided everything for the whole world and that it ran on a cheap phone. Manufacturers and phone operators are the ones to screw everything. The result is I own a Xoom that is only in German for example, and if you're wondering, no I live in the french part of Switzerland.

Interacting with hardware

I have two very successful apps on Android. One is a Battery monitor which runs calibration tests, another is a "simple" Flashlight. Together they're reached over 10 million downloads so I think it makes my numbers reliable.

Both apps share in common that they have different behaviours depending on hardware.

Flashlight LED HD

It's a simple flashlight. SIMPLE. Really. That's what I thought when I asked my colleague to port it to Android.

In theory on Android 2.2+ you can turn on the LED with like three lines of code. The only issue here is that is basically never fucking works.

While some constructors like Sony and HTC usually cause very few issues, others like the dominant Samsung and the miserable Motorola have so many quirks and bugs that this app now has 15 different techniques and workarounds to turn on a freaking LED. When a manufacturer finally updates its device then we suddenly need to use a different technique depending on the system version. And this has to be fixed quick before users will get very angry when it stops working.

Most of the e-mail I get is from people saying their LED doesn't turn on on one model or another or that it does only using the test tool (meaning we've failed to detect which new variation it is), or that it blinks, or turns off after 5 seconds, or locks up the whole system... I keep telling every day to all ZTE device owners that the only way they can turn on the LED from a third party app is to root their phones, making it insecure. Unbelievable, right? But true.

Because of the milions of downloads involved, this mess is suprisingly worth maintaining. Thank you Admob. But when compared to my iOS port, which I only update every three months, this app really doesn't make Android development shine. There is not one single week where my colleague doesn't have to add another line to the code that says something like "if Model == X" and "API level = Y"...

A picture is worth a thousands words, so here's a picture of words. That's a screenshot of some of our ticket's titles.

.

That's what we do on a nearly daily basis: handling inconsistencies, bugs and the like. All that hoping that a new users launching this app will just hear a 'click' and see light.

Battery HD

In order to provide estimates, this app runs calibration tests and saves the result on a server. New users can automatically get an average of tests run by people with the same device and the same system. This way it works fine for most users and running calibration tests (which may take several hours) is optional. As of today over 368,919 tests have been saved on our server, totalling over 212,312 hours of tests run by our users. Yes that's the equivalent of running them for about 24 years straight on one device. I am proud to say this works suprisingly well for the vast majority of users. The number of users makes up for the variety of devices.

The tests are rather simple so they rarely cause compatibilities issues. That is not counting, of course, the only hardware interaction it has: locking / unlocking the screen after tests. This is particularly inconsistent among manufacturers and system versions.

In order to provide the right crowd-sourced average estimate we create a unique key to identify the device's hardware+system combination. The values returned by Android devices when it comes to manufacturer, device name and motherboard name are just hilarious.

Can you imagine one iPhone's model being returned as "iPhone", another as "iphone" , another as "IPhone" or "iPhoneB" because it's sold in Brazil... only to switch to "i2923_39" after an official update ?

Well, that's approximately what our friends at Samsungs and their siblings do. Nearly every time they bring a major update to the system they change something. Sometimes they just change capitalization, other times they just completely change the motherboard name (because it previously contained the phone's model... oops).

Then you need to factor in the wide amount of custom ROMs available and installed everywhere by many users trying to compensate for the lack of official updates.

ROMs with wrong hardware identifiers are particularly harmful since they make all detection fail, which in turns makes us use the wrong workaround for their particular system bug. What do you do with a device supposedly manufactured by "Samsung" but named "HTC Desire HD" ?

Yes, I know. You trash it.

So how many combinations do we have now for

Manufacturer + Model + API Level ?

According to the server stats from Battery HD, the total number of variations since the last app update is now 5208. I didn't believe it either. Check for yourself in this terrifying CSV.

To be fair if we convert all to lowercase we only get 5008 CSV.

Yes, that is five fucking thousand variations.

One could argue that even if there are so many variations, it's very often the same hardware behind. We could easily account for this if manufacturers used the os.android.Build.BOARD field correctly. By correctly I mean that the name of the hardware wouldn't change with every major update or just not be plain empty or contain the same value as another field, such as the device name.

And this mess comes from the same people who reject an app because the BSD license in the about box isn't translated in Serbian. Yes, I am looking at you Samsung Apps.