Android isn't iOS, so why do we try to define it the same way?

That said, let's take a look at the data OpenSignal has generated, starting with the insanity that is the sheer number of Android devices that can be found in the wild. OpenSignal has found that right now, there are 18,796 "distinct" Android devices in the wild. Distinct in this case refers to all of the hardware iterations that can be found, meaning each model of Samsung Galaxy S4 is considered distinct from the others. Some devices differ by as little as the radio in use, all the way to various screen sizes, resolutions, processors, etc. This number has been skyrocketing. 

When OpenSignal first started gathering its data in 2012, there were slightly under 4,000 distinct Android devices in the wild. Last year, that number almost tripled to 11,868. And, this year's total marks a 60% increase over the number of distinct devices found last year. Of course, in that same time, Android's global market share has risen from about 70% to about 85%. This points to the idea that while it is quite interesting to note the number of Android devices in the world, it is hard to pull too many negatives from that data.

The number of low-cost devices has led to Android being huge in emerging markets; the selection of mid-range devices makes Android the popular choice for prepaid carriers and customers; and, the array of high-end Android devices has allowed the platform to stay ahead of the iPhone even in high-income regions.

There are some negatives to the vast number of devices, although they aren't really found in the issues that OpenSignal puts forth. OpenSignal is still trying to beat home the idea that all of this device variation (and the wide range of screen sizes and resolutions) puts a heavier onus on developers and makes optimizing apps more difficult. While that is true to some degree, it isn't nearly the issue that you might think. The trouble with looking at the issue this way is that it is a very Apple-y way to view the issue. In Apple's world, there are a limited number of devices with tightly controlled screen sizes, resolutions, and architecture. So, thinking that a developer can and should optimize apps for those specifics makes sense. 

When the basic tenet of the platform is diversity, optimization is not a question of targeting specific devices, but of adaptation and responsiveness.

But, in the Android world, as it is with Windows, Ubuntu, and even web design, trying to assert that the developer needs to or should optimize apps for every device on the market is madness. Pure and absolute madness. It is a fundamental misunderstanding of the task at hand and the platforms in question and a dangerous simplification of how the platform works. When the basic tenet of the platform is diversity, optimization is not a question of specifics, but of adaptation and responsiveness. Developers shouldn't have to waste time and energy optimizing for specific devices, so the system does most of the work for them. 

A well-coded Android app will use the responsive design tools built in to the platform to deal with any issues of screen size or resolution changes. Optimizing for specific processors is won't offer a lot unless you are building a hardcore game, because other apps will essentially run as fast as the processor can go because of the just-in-time (JIT) compiler. For most developers, optimization is a matter of keeping your code clean (Android Lint is a tool built by Google to help with this), and testing your device on just a few devices - something from the very low-end, something from the lower-mid tier, and one of last year's flagships. And, even this depends on whether or not your app is even targeted to all of those markets. 

The idea is simple: if your app runs reasonably well on a low-end device, it should scale up without an issue. Of course, there are plenty of low-end devices that can't even run the Android system all that well, but again, users with those devices may not be going into the Google Play Store all that often, which is why you test on mid and high-end devices as well. Remember, many low-end Android devices use older versions of the platform, but every month the platform distribution numbers put out by Google show the newer versions accessing the store more and more, while older versions fade away. Knowing who accesses the store is a key indicator of where your optimization resources should go. 

That brings us to the much more relevant OpenSignal chart in terms of design: the brand chart. Samsung may have a ton of different devices that run on different processors with different screen sizes and resolutions, but none of that really matters as much as knowing that Samsung devices make up 12 of the 13 most popular devices found in the wild, and a total of 43% of the market. Although, it should be noted that even this chart is slightly off, because there are devices labeled as "Verizon" that appear to be more Samsung devices. Still, the size of Samsung's world matters for developers not because they should be designing to fit into the TouchWiz UI (they shouldn't; Android apps should be designed to be at home in the Android system, be it Holo or Material Design), but because the Samsung ecosystem brings its own challenges to developers.

Developers should know that 43% of the market is made of devices with a ton of bloat software. This will mean that users have a more limited amount of storage, and system resources available than what you might expect when looking at a spec sheet. That bloat could make users more wary of the install size of apps, and it will certainly mean there will be slow down on whatever hardware is there. But, the individual devices don't matter all that much, because Samsung software is largely the same across devices, aside from various gimmicks (SmartStay, etc) and sensors (heart rate monitor, etc) which most developers wouldn't attempt to use anyway. 

The brand chart also helps developers to understand a bit on how to target your app. For example, Sony is the second largest Android brand at 4.8%. This is a huge gap compared to Samsung, but it is an interesting point to note because the vast majority of those Sony devices in use are in Asia, and more specifically in Japan. Sony tends not to rank in any meaningful way in North American or European smartphone sales. And, that points to another oddity in the data, because Sony is never ranked in the top 5 in smartphone market share, but comes in at number two in this data. 

We can't say for sure, but this could indicate something of a discrepancy between shipments/sales data and actual usage data. According to IDC, the top Android brands in terms of shipments (in order) are Samsung, Huawei, Lenovo, and LG. But, according to OpenSignal's data, the top Android brands in terms of usage are Samsung, Sony, LG, and Motorola. This inconsistency could be a matter of methodology, or the timing of the data collection, but if Motorola really is that high up the list, developers are looking at a market with a lot more devices running the newest Android software, which brings us to the last major part of OpenSignal's data:

The dreaded Android platform OS distribution chart. This is often the number one piece of evidence levied by proponents of the "fragmentation is bad" theory. And, as you can see from the chart, OpenSignal is presenting the data in the most confusing way possible, once again choosing to show the Android OS version data starting from April 2010. That much data doesn't really do anything more than add unnecessary complexity (and pretty colors) to the data, and hide the useful information that can be drawn.

Once again, this kind of data, and the subsequent comparison to iOS, misses the point. If you were to look at the Windows OS version adoption (or even MacOS for that matter) in a similar chart, it would look even worse in comparison to iOS, because the software updates are left completely up to the users. When it is solely up to users, they will flat out skip certain versions of the software with little to no regard for security issues. For example, it took until this past January for IE6 to drop below 5% global market share, and that was initially released 12 years ago; and Windows Vista never cracked 20% of the market in the 3 years it had before Windows 7 came along. At least with the Android ecosystem, responsibility for updates is put on the manufacturers, which means a constant progression, even though that progression is never as fast as we would like (aside from Nexus and Motorola devices). 

But, even so, looking at the history from 2010 doesn't help developers understand how the ecosystem looks right now, so we've taken it upon ourselves to delete the data in the chart from before July of 2013:

That gives a much clearer picture of what developers should be looking at in terms of API levels to target, and the trends with what is on the market. As we have been saying for about 18 months, the habit of developing apps for Android versions below 4.0 has quickly become a pointless endeavor that is doing more damage to the platform than it is helping users. Both this data and that provided by Google on a monthly basis show that devices running Honeycomb or below make up a small percentage of the Android ecosystem (under 15% as of this writing). Or rather, devices running that low an OS version are used by people who don't access the Google Play Store, which effectively makes them a non-target for developers. 

Of course, even focusing on the Android versions themselves is becoming less and less useful. Most developers should be aiming to support Android 4.0 as the base, just like most iOS developers use iOS 6 as the base. Some developers need to aim a bit higher though, but really the only reason to do that is if you are making an Android Wear app. Android Wear devices run an offshoot of Android 4.4, and if the app is focused on wearables, the smartphone side can aim at Android 4.3, because that is what is required to connect an Android Wear device.