With the proliferation of many different types of mobile devices – from various smartphones to tablets, to phablets – one significant challenge faced by developers is ensuring that their applications function correctly across all of them. To achieve this goal, app developers and their QA teams need to account for the many shapes, sizes, and restrictions that emerge when dealing with multiple devices.

Due to Apple’s markedly closed system, their entire library of devices shares very similar specifications. No other developers can modify the platform – only Apple devices run iOS. This allows developers to expect that their application will function properly without necessarily having to test on each Apple device.

With Google, the situation is much different. It has opted to allow manufacturers to create their own hardware that often runs a customized version of the Android platform. This open system creates a broader spectrum of devices that vary in screen resolution and size, memory and processing limits, and even app availability. Consequently, there are a variety of unique, device-specific issues that testers have to be cognizant of.

Below are a list of devices and some of the more significant testing challenges they present, as well as some tips on how to avoid potential QA issues.

Nabi

Nabi devices are child-friendly tablets that operate on one of the customized versions of the Android platform mentioned above. One of the major benefits to of Nabi from a consumer perspective – apart from the large rubber borders that protect it from physical damage – is the inclusion of two separate modes: Parent and Nabi. The latter is the mode that is used for children. They have access to apps, but cannot modify settings or add applications to themselves. Parent mode allows full functionality and enables parents to approve the apps that their children have access to.

These two distinctive modes can present development challenges. For example, having too long of a package name will cause Nabi mode to ignore your app when grabbing all approved apps, even if you do approve it. Thus, when testing, one of the most important things to check is whether the app can appear in Nabi mode, especially considering it is the biggest selling point of the device.

Kindle

Kindle devices have evolved from simple e-book readers to fully functional tablets. They are becoming an increasingly popular choice, and developers would be wise to ensure their applications work on the Kindle platform.

The hardware itself contains only the minimum amount of physical buttons (power and volume up/down) – everything else is placed into a digital navigation bar. The bar can be hidden but will be revealed with a swipe. This navigation bar is typically the root of many QA and dev issues.

When testing an app on a Kindle tablet, it is very important to test all UI features both with and without the navigation bar. The app requirements may dictate that when the bar is visible, the entire UI of the app shifts up to accommodate the extra space that is being taken away. In that case, the UI shifts may cause unwanted visual and (potentially) functional issues.

Other Devices Running Android

The majority of other Android devices follow general conventions like physical navigation buttons or app distribution via Google Play. However, their hardware differences can affect the functionality of applications.

Variations in screen size, resolution, CPU and memory limits become the biggest challenge when testing for on some of the more “common” devices, including Samsung, Nexus, Asus, Acer, etc. All of these devices will have different specs, which unfortunately can result in a number of device-specific problems. From example, some UI elements may appear correctly (quality and position) on Device A but will appear improperly on Device B.

Having a list of supported devices will certainly help with testing, ensuring that any issues raised only apply to those listed devices. Another thing to keep in mind is that devices may be running different OS versions. Not all users upgrade their operating system immediately, and different OS versions may handle certain functions, layouts, etc. differently. Keeping a small variety of OS versions on the same type of device will give you the most coverage possible.

Testing Android devices is a much more involved process than iOS devices, due to the large variety of hardware being created and the manufacturer-specific Android setups being put on those devices. Learning the hardware-specific quirks of your testing devices will allow you to create a more stable, polished app through thorough testing.