One of the biggest reasons for Android's success is in the hardware variety. There is an Android smartphone that fits everyone's preferences, size needs, and budget. The basic aim of the platform is to be incredibly adaptable and malleable, so why do people continue to try defining Android's success through the lens of what Apple has done with iOS? The comparison makes little sense when looking at market share, and even less sense when looking at how the platforms are built and how that affects the resulting hardware.
iOS is a tightly controlled ecosystem designed to run on Apple's hardware and nothing else. It is highly optimized because of that software/hardware relationship and affords. Android on the other hand, is designed to be able to run on a wide range of devices across price points and form factors. Of course, that same variety causes a number of different issues which some people lazily file under the heading of "fragmentation". That is what OpenSignal has done, which takes a bit away from the incredibly cool data it has.
This is a topic that we've covered a number of times before. The basic argument is that "fragmentation" is a blanket word that 1) fails to adequately describe the various issues within the Android ecosystem; 2) assigns blame in the wrong place; and, 3) ignores all of the benefits derived from the diversity in the Android world. Also, the word "fragmentation" tends to only be used when talking about Android, even though it is an issue that affects all computing platforms, including iOS.
And, even worse, this same issue is something we talked about in regards to OpenSignal and its incredibly cool data set, but OpenSignal has obviously not learned anything from the feedback and has continued to soldier on in the same flawed way. That's not to say that OpenSignal is pushing bad information, it's just that the conclusions drawn and comparisons made are often incomplete. The real trouble is that while the text of the report tries to portray "fragmentation" as something of a good thing, it doesn't take into account how loaded the word has become. Trying to reclaim it as a positive is nearly impossible, and it would be best to simply not try to use the word as a catch-all term and talk about each issue on its own.
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.
Recommended Stories
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.
The optimization misunderstanding
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.
The missing Play data
The other reason why Android versions are becoming less and less useful is that Google has consistently been shifting the major changes to Google Play services, while the Android system updates are more surface level changes. Unfortunately, OpenSignal's report doesn't even mention Google Play services, which is a huge omission. And, it is unclear why there has been no mention of Google Play services, given the huge impact it has on Android as a whole.
According to Google, Google Play services is updated regularly, and the updates are pushed out automatically to 93% of Android devices. This has a big impact specifically on this report and when you're talking about supposed "fragmentation" because there are key APIs in Play services, including Google Maps APIs, Location APIs, Play Games APIs, account authentication/syncing, in-app payments, and Cloud to Device Messaging. This means that the API level of different Android system releases have little bearing on these services, and it means that only certain developers need to even look at the distribution chart for Android versions, because many apps don't really need much beyond those core functions.
Conclusion
Talking about Android is a complex issue and trying to simplify any of the many idiosyncrasies of the platform can easily get you in trouble. Much of that trouble is still connected to the fact that Apple is seen as having kickstarted the current smartphone revolution, and the rhetoric pushed by Apple is still ingrained in many minds. Apple tried desperately to control the conversation and use many of the same Mac vs PC arguments to put down Android before it could get going. Unfortunately for Apple, history repeated itself and Android took over the ecosystem.
Many who cover smartphones still try to use Apple's vision as the standard for which platforms should be judged. The idea being that Google could somehow still have a platform as dominant as Android is, but somehow still change fundamental aspects of it. That can't happen. Google has found ways to mitigate the issues that arise from its basic design, including instigating more rules to push newer versions of Android on devices, mandating updates, and shifting critical pieces to Google Play services. But, Android will always have the same types of issues with system update speed and insane variety in devices. Those are issues that we all have to accept as part of the deal, just like how there are issues inherent with iOS's nature that we have to accept, like no real customization options or ways to change the default app for certain tasks.
Michael Heller is known for his clear and informative articles on mobile technology. He explores important topics such as the rollouts of 5G networks and the advancements in mobile payments, offering readers insights into the evolving tech landscape.
Recommended Stories
Loading Comments...
COMMENT
All comments need to comply with our
Community Guidelines
Phonearena comments rules
A discussion is a place, where people can voice their opinion, no matter if it
is positive, neutral or negative. However, when posting, one must stay true to the topic, and not just share some
random thoughts, which are not directly related to the matter.
Things that are NOT allowed:
Off-topic talk - you must stick to the subject of discussion
Offensive, hate speech - if you want to say something, say it politely
Spam/Advertisements - these posts are deleted
Multiple accounts - one person can have only one account
Impersonations and offensive nicknames - these accounts get banned
Moderation is done by humans. We try to be as objective as possible and moderate with zero bias. If you think a
post should be moderated - please, report it.
Have a question about the rules or why you have been moderated/limited/banned? Please,
contact us.
FCC OKs Cingular\'s purchase of AT&T Wireless
Things that are NOT allowed: