As you know, there are many different devices using Android. As a result, there are also an incredible number of displays with different combinations of resolution and pixel density to take into account, which makes the entire development process significantly more complex. At one point, we at Distillery decided to make the testing process on various displays easier and avoid running the application on different devices and virtual machines. After performing a thorough analysis of the problem, the solution became obvious — it is one which could be implemented using Adb and only one connected device. As a result, we managed to develop cross-platform utility software that automatically saves application screenshots with various parameters of the display without any need to change the source code of the application (it also works with various emulators and virtual machines). After running the utility software, the developer gets several screenshots of the application, which reflect the appearance of it on devices with different configurations. The developer can use these screenshots in order to find application artifacts and to analyze the level of layout optimality.
In order to make things easier for those who don’t want to read all the details of the application development, I will provide a short recap about the operation of the software:
The thorough user’s manual with the links for Java and Adb can be found on GitHub. The usage of DroidShoter is very simple: just launch it, choose the desired parameters and press Start!
According to official documentation of Google, all the displays can be divided into the following categories:
As you can see, the giant number of different display combinations appears from the intercrossing between the size of the display and the density of pixels. It’s worth noting that the combination of the size and the density of pixels define the resolution of the display. Thus, we can say that there are two main characteristics, which are enough to define the type of the display: the resolution and the pixel density. Specifically, these characteristics can be changed with the help of Adb. We also know that we can use Adb in order to take screenshots, thus there is nothing that can stop us from going through the different combinations of display characteristics, taking screenshots for each of them. So we decided to automate this amazing process.
Firstly, we had to find a way to get information about the display parameters. Even though it was pretty easy for all the devices with Android 4.3 and above (we had to parse wm size and wm density commands), all other devices required a different technique. As a result, we decided to use the dumpsys window command that gives us a string similar to ‘init=480×800 240dpi’. Unfortunately, a few devices (currently we faced such problem only with one model of Sharp) are not giving information about density, so our software won’t support them.
One has to use the following Adb shell commands in order to change the parameters of the display:
Unfortunately, various system elements (e.g. the status bar) can be represented wrongly after changing the configuration of the screen. This problem has its roots in Android and we couldn’t manage to solve it. However, it doesn’t affect the entire layout of the tested application.
At this point, it was obvious that software had everything that was required, and we were sure that our software utility would make it, all we had to do was develop it. We used Java as a programming language and Swing framework in order to interact with UI. Furthermore, Java includes amazing ddmlib library that makes the entire operation of Adb significantly easier.
DroidShoter is based on a very simple base logic rules. After the developer selects a device, DroidShoter detects the physical parameters of the screen, making a list of parameters for the further operation of DroidShoter. When the developer clicks Start, the application starts to iterate various parameters of the screen and takes screenshots.
The list of parameters contain all possible combinations of the resolution and the pixel density, which are lower than the basic characteristics of the device. In other words, if the display of your device works with the resolution of 720×1280, the resolution of 1020×1980 won’t be used to take a screenshot. The same principle works for the density of 320 when the physical density of the screen is equal to 240.
More specifically, Adb made it possible to use parameters which exceed the physical parameters of your device, however, we decided to avoid using them for now, because it resulted in the loss of several pixels and affected the overall appearance of the tested application (e.g. list element separators may simply become invisible).
|Screen Resolution||Max DPI|
We have added the following features to the main logic of the tool in order to make it more useful:
Some applications may cause fatal errors for different combinations of the parameters. In such cases the developer just needs to exclude such combinations from the list (however, it’s recommended to find the reason of such errors, because it may be hidden somewhere in your app).
The operating system considers new parameters of the display as a new configuration of the screen, which results in the standard process of recreation of current activity. The configuration is changed with screenSize parameter and can be intercepted in activity by registering manifest with the following tag
That creates another great advantage of DroidShoter: it tests the entire process of application restoration after changing the configuration of the screen.
Below you can find a video of how DroidShoter works. And if you have a mobile app idea our team could turn into reality, just let us know!
Vladimir Farafonov — a mathematician by education and a programmer by calling — joined the Distillery team back in 2014. His first language was QBasic, which he learned while still a schoolboy. Today, he’s obsessed with Java and everything related to Android development. He has come a long way from working as a regular developer to a mobile architect, and these days heads Distillery’s Android department.