Android Fragmentation Myth

Recently, we are increasingly hearing about how fragmented the market for Android devices has become, how Google has given control of Android to device manufacturers, and how dreadful is writing and testing applications for Android OS. All this is not true.

To understand what exactly formed such an opinion, consider the first diagram posted on the TweetDeck blog. As part of the beta test application for Android, hundreds of different types of devices are listed, but note that the overwhelming majority of testers preferred phones from the top 15.

Now we will look at the second diagram in the same post. There are more than 100 different firmwares on it, but more than half of testers use native Android 2.2 firmware, another big part of testers use 4 more popular versions of native firmware.

The conclusion to the first diagram reads: “From our point of view, it’s very cool to note that our application works on such a wide range of devices and variations of Android OS”. And despite: “there are serious differences in phones and Android OS versions, everything works for everyone”.
')
Fragmentation of the Android device market is not a problem for software developers. From a programming point of view, if you are using the Android SDK, then you usually stick to Android and Google API by about 99.7% in your work, choosing the minimum API level that you need and not worrying about how it will work with interface skins which add HTC, Samsung, Motorola and others. Manufacturers are responsible for ensuring that their devices support standard APIs, and they do this, as TweedDeck has proven with the help of 36,427 active beta testers.
In rare cases, you may want to write an application that uses non-standard hardware capabilities, access to which is not available in Android or Google API, for example, to use a dual LED flash on HTC Incredible as a flashlight. Usually in such cases, manufacturers are trying to add support for such applications in the end. In the case of Incredible, support for HTC Flashlight was added to the Android 2.2 update.

If you want to test on each device that supports your minimum API specifications, you do not need to have an instance of each of them. If you use the Android Market, you can test all the hardware on real devices, releasing free beta versions, as TweetDeck did. Believe me, users are not shy to report problems if the application does not work perfectly on their device when the program is free.

If you have a closed application, you may want to let users know which devices have been tested and which of them are supported, but you cannot allow them to test the application themselves on those devices that you do not have. In this case, you can add only those users to the list of supported devices whose users will tell you that everything is fine with them. To do this, you can use questionnaires for users, paid by the principles of crowdsourcing.

In fact, everything is not so difficult. Start with the currently largest Android 2.2 API target, and write your application under it. Perform internal testing on three Android 2.2 phones one by one from HTC, Samsung, Motorola. Release the release only for version 2.2 and see what the testers say. When the tablets based on Android start to go out, start testing on them and change the application, adding alternative screen layouts if necessary.

After that, go back to previous versions of Android and using workarounds make everything work on version 2.1. The official Android blog has some good practices for doing this. Then test the application again on three phones, then change the version number to a smaller one. Continue to do this until you reach the lowest version.

Are you sure that fragmentation is not a problem? Testing applications for Android is much easier to optimize for various OS versions, browser versions and screen resolutions that have been done in the past 50 years.

via InfoWorld