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.
Quick Start
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:
- It can be downloaded on GitHub in the Releases section. Unfortunately, in accordance with GitHub policies it’s impossible to attach *.JAR files, so we had to put them into ZIP archive.
- Requirements: installed Java (JRE is enough) and Adb.
- Launch: double click on DroidShoter.jar or use the following command in the terminal: java -jar DroidShoter.jar.
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!
Some Details
According to official documentation of Google, all the displays can be divided into the following categories:
- By their size: small, normal, large and xlarge.
- By the density of pixels: ldpi, mdpi, hdpi, xhdpi.
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:
- wm size [WxH] (for Android 4.3 and higher) and am display-size [WxH] (below 4.3) — to change the resolution of the display.
- wm density [value] (for Android 4.3 and higher) and am display-size [value] (below 4.3) — to change the density of pixels.
- The mentioned commands can be used with reset instead of the desired parameters.
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).
| Category | DPI |
| XXXHDPI | 640 |
| DPI_560 | 560 |
| XXHDPI | 480 |
| DPI_420 | 420 |
| XHDPI | 320 |
| HDPI | 240 |
| MDPI | 160 |
| Screen Resolution | Max DPI |
| 2560×1600 | XHDPI |
| 2560×1440 | DPI_560 |
| 1920×1200 | DPI_560 |
| 1920×1080 | DPI_560 |
| 1280×768 | DPI_420 |
| 1280×720 | DPI_420 |
| 854×480 | HDPI |
| 800×480 | HDPI |
| 480×320 | MDPI |
| 320×240 | MDPI |
We have added the following features to the main logic of the tool in order to make it more useful:
- Automatic detection of connected (disconnected) devices.
- Developers can choose the screenshot folder (it supports both relative and absolute paths).
- The prefix can be added to the screenshot file names. The name is composed with the following structure: [prefix][width]x[height]_[density]
- Developers can define a delay before taking a screenshot after changing the working mode (it can be required to give enough time to activity in order to perform required operations, e.g. receive required information from the server).
- The list of active working modes can be saved for each and every device (all checkmarks will be removed from the working modes, which were deactivated during the previous use of the tool, will be removed after restarting DroidShoter).
- Automatic Adb searching in ANDROID_HOME variable. The tool saves the path to Adb in case if the developer indicated such path manually.
- The tool offers a separate button that resets current parameters to the physical parameters of the screen. This button was created for the sake of uniformity, because it was never used during the real operation of the tool.
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
android:configChanges="screenSize"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!
About the Author
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.