Earlier this week OpenSignal released their latest visualizations around the state of Android fragmentation. The results were not encouraging:
We have seen 24,093 distinct devices download our app in the past few months. In our report last year we saw 18,796. In 2013 we saw 11,868.
A two-year doubling of the Android device population boggles the mind. It’s almost unfathomable. Now keep in mind a lot of these “new” devices are coming from companies like Xiaomi, Huawei, Micromax and others serving developing countries. But strip those out and we’re still left with way too many devices.
Source: OpenSignal, 2015.
This graph demonstrates the huge challenge that lies ahead for enterprise IT teams responsible for mobile development:
- Product owners are often faced with a Sophie’s choice when it comes to what new features they can add. As a result they must often revert to lowest-common-denominator solutions, based on the capabilities/limitations of the known device population.
- Designers are challenged to create optimized experiences across dozens of screen sizes and resolutions. Google’s Material Design approach solves some of this, but MD was announced in concert with Lollipop (installed on fewer than 1 in 5 Android devices) and may seem out of place on the 80% of KitKat and older devices.
- Developers cannot possibly build apps to optimize the experience across all the various screen sizes, idiosyncracies, and capabilities of this wide swath of devices.
- QA teams can’t possibly test enough to catch all the defects
- Help Desk teams cannot provide adequate support for thousands of devices
A quick sidebar: Of all of these challenges, testing is the most acute. Most companies still don’t have an adequate mobile testing strategy in place (if one exists at all). Emulators help companies build a cache of testing devices (as do companies like Keynote and Perfecto Mobile), but provide just a more robust—still incomplete—set of testing devices. The maturity of mobile test automation tools is still fairly low and the use of automation on average throughout the enterprise is even lower. Not to mention more effort is required for non-functional testing than for functional. The impact of the variations in CPU, WiFi, and wireless network chipsets, device memory, and the availability/capability/breadth of device sensors only increases the problem exponentially.
Now let’s add-in the expectation of the rapid release cycle associated with mobile and you’ve got your classic Pepto-Bismol moment.
COPE/CYOD to the Rescue
So how do most companies deal with this conundrum? Those that don’t support Android devices at all wind up facing an irked employee base. Others try to use Android OS level as a bulwark against fragmentation. But as big of an issue as OS-level fragmentation is, significant behavior differences remain even between two devices on the same OS version.
Others companies select a target set of devices to build and test against, based either on an analysis of their own device population or using third party lists like Perfecto Mobile’s Mobile Test Coverage Index. This can reduce dev and test efforts but still leave a bunch of users out in the cold.
The simplest method is to avoid BYOD and employ COPE or CYOD-based programs. Defining a short, discrete set of approved devices removes any ambiguity and can vastly improve the efficiency of your development and testing efforts while easing deployments to users, ultimately yielding a better overall user experience.
How are you addressing Android in the enterprise today? Does this make you think any differently? Please give us a call and let us know. We’d love to hear from you.
Mobile leader, speaker, blogger