Key to a Healthy Android Project with Sonarqube

Our story of integrating Sonarqube, Detekt, and Jacoco to keep Android projects healthy, and what we learned from it.

A Healthy Android

Introduction

Android has come a long way from being a small mobile platform to the biggest one on the market, with over 2.5 billion active devices worldwide. Therefore, developers need to deliver high-quality experiences to large audiences and do that faster than their competitors. With such a high development pace, it gets more and more difficult to maintain a healthy codebase with decent test coverage and follow best practices when implementing new features.

There are several ways to prevent a codebase from degrading over time, such as code reviews, regular refactors, automated tests forcing developers to write testable code, and static code analysis tools. In this article, you will get familiar with the most popular static code analysis tool called Sonarqube, and an open-source Gradle plugin I developed at Pinch making its integration easier, especially when you have to do it in several projects. We will share the results of implementing static code analysis in our development pipeline and share implementation details so that you could start analyzing your projects too.

Goal

Our goal as a software development agency is to improve the quality of work that we deliver to our customers. For making any improvements, it is key to measure the impact of these improvements to be able to judge how successful they actually are. While we could measure things such as our average email response times, crash rates and product delivery times from start to finish, it was not clear how we could measure the technical quality of the work we deliver.

While trying to solve this problem, we came across Sonarqube and implemented it in one of our projects. Sonarqube is one of the most popular tools for static code analysis used by many software teams across the world. It can detect potential bugs, security vulnerabilities, duplicate code blocks, complex functions, and provide various useful metrics. Not only will Sonarqube highlight problematic code, but also suggest ways to solve it and provide some estimate on the time it could potentially take. All of these issues are then displayed in a clean web interface.

Sonarqube web interface highlighting a code smell

What makes it particularly interesting for Android developers is the fact that Sonarqube can digest reports from Jacoco (test coverage plugin) and Detekt (an advanced Kotlin static analyzer). It is also worth mentioning that Kotlin and Java are among the languages supported for free. However, integrating all of these plugins in your Android project might take hours or even days, since you would need to configure your paths correctly, define your own Gradle tasks to enable code coverage and so on. This is how we came to the next problem: how can we integrate Sonarqube, Detekt, and Jacoco in all of our projects in a scalable manner. As a result, the Android Analyzer Gradle plugin was created.

Sonarqube + Android Analyzer = ♥

Android Analyzer Gradle plugin is a helpful tool to avoid the configuration burden described above, exposing a simple interface and handling all the complexity of integrating plugins internally. To give you an example, below is the minimum configuration that is required to start analyzing a Gradle module using the plugin, excluding the dependency import:

apply plugin: 'com.justpinch.androidanalyzer'
..
androidAnalyzer {
    applicationId = 'com.domain.example'
    projectName = 'Your Module Name' 
    detekt = true
}

It looks quite simple, doesn’t it? This plugin allowed us to quickly introduce static code analysis in many of our customers’ projects without a need to learn the interfaces of the underlying plugins and spend time on connecting them together. Here is how we did it.

At Pinch, we are having regular Android team meetings where discussions on everything related to Android development takes place. Since we have limited knowledge about each other’s projects, this is also the time to talk about various challenges we are facing and present solutions to these problems. This time, I volunteered to prepare a workshop on Sonarqube and part of that workshop was the integration of our Android projects with Sonarqube. I already had Sonarqube on our CI server installed and configured by that time and prepared an example app (which is available in the Github repo too) for my colleagues to use as a reference. We sat together for about an hour, while I gave a short presentation about Sonarqube and the AndroidAnalyzer plugin and showed how much configuration code was saved in the project I was actively working at that time. Then, by the end of the session, my colleagues were able to not only integrate Sonarqube with their projects but already resolved some bugs and vulnerabilities that were found by the tool. Since the plugin integrates Detekt and Jacoco internally, we also got code coverage reports and advanced Kotlin analysis for free in the same dashboard.

In the Integration section at the end of this article, you can find a guide on integrating Android Analyzer plugin in your Android projects. For now, let me share my thoughts on the results of this whole activity.

Results

Integrating Sonarqube with Android Analyzer in our development pipeline at Pinch gave us the opportunity to have a high-level technical overview of our projects. We are able to identify and fix critical issues in existing projects in relation to security, maintainability, code smells and overall best practices. In addition to this, by constantly analyzing projects that are in active development, we were able to prevent a large number of bugs that would otherwise only have been noticed in production.

Since Sonarqube provides a full history of project analysis results, we had exact numbers to share with the management about the outcomes of our refactoring and bug fixing sprints. These reports made it clear for management that we were actually improving our codebase, effectively making it easier to get time allocated for such “improvement” sprints in the first place.

Sonarqube project analysis history of a sample project. We see no bugs or vulnerabilities, and a number of code smells represented by the dark blue line over a period of several weeks.

All in all, continuous code analysis using Sonarqube and Android Analyzer plugin can be beneficial for the development of software products. Even though this is not a magic pill for all of your problems, it is certainly a step towards maintaining a healthier codebase, making it possible to develop and release faster, resulting in a better overall product and user experience.

This is where the story ends. In case you got inspired and want to know more about the plugin, I suggest you follow the Integration section below.

Integration

This section is a quick guide showcasing how simple it is to integrate Android Analyzer plugin in your Android project. Complete documentation, as well as an example project, can be found on our Github page. I encourage you to read the documentation later as it contains useful information about customizing the plugin for certain specific scenarios.

Step 1: Setup Sonarqube

If you already have a running Sonarqube server, you can skip this step. If you don’t, the easiest way to get started is using Docker. If you are not familiar with Docker, I would recommend this article to get up and running in just about 5 minutes. An alternative would be to ask your system administrator to do this work for you, but it really takes little time to set up.

After having Docker in place, you can download an official Sonarqube image and run it. Then, you only need to configure two things: port and credentials.

Make sure to configure your local port to 9000 as it is used by default by Sonarqube. This is how ports are configured in Kitematic:

Configuring ports in Kitematic

Change your default account credentials as you wish and set the following environment variables in your Sonarqube instance for username and password:

username: ANDROID_ANALYZER_SONARQUBE_USERNAME
password: ANDROID_ANALYZER_SONARQUBE_PASSWORD

This is how environment variables are provided in Kitematic:

Setting environment variables in Kitematic

That is all the server-side setup needed. You can go to localhost:9000 and verify that the setup went correctly. You should be able to login using Sonarqube’s default credentials, admin as both username and password. Now you are all set for integrating the Android Analyzer plugin.

Step 2: Add Dependencies

In your project-level build.gradle file, add the following dependencies (make sure to check the latest version on our Github page):

allprojects {
    repositories {
        ..
        jcenter()
        maven { url "https://plugins.gradle.org/m2/" }
        maven { url "https://raw.github.com/pinchbv/android-analyzer/master/repo" }
    }
    dependencies {
        ..
        classpath "com.justpinch:androidanalyzer:1.1.1"
    }
}

Step 3: Provide Configuration

In your module build.gradle file (or files, in case of a multi-module project), apply the plugin at the top of the file:

apply plugin: 'com.justpinch.androidanalyzer'

Then, provide the configuration in androidAnalyzer extension at the end of the file:

androidAnalyzer {
    applicationId = 'com.domain.module'
    projectName = 'My Module name'
    projectVersion = '1.0.0'
    detekt = true
    unitTestCoverage = true
    packageName = 'com.domain.module'
    buildVariant = 'debug'
}

Let me explain a bit about what is happening here. First of all, only the applicationId and projectName are required parameters, all others are optional. More detailed explanations of all the parameters above are listed next in this section.

applicationId is mandatory and used to generate a unique project key on Sonarqube, and you must make sure that these are unique across your apps for a single Sonarqube instance.

projectName is mandatory and used as a display name in Sonarqube.

projectVersion is used for versioning in Sonarqube, and provides some metrics to compare different versions.

detekt is a feature flag to turn Detekt Kotlin static analysis tool ON or OFF. By default, it is OFF. If you have Kotlin code in your project, I would strongly recommend to turn this feature ON. Note that this will generate a configuration file needed by Detekt and place it in your module directory. Once the file is already there, the plugin will not generate it again. The Detekt configuration file will come with a handy set of default parameters that can be modified per your particular project needs. Please consult Detekt documentation for possible configurations.

unitTestCoverage is a flag to turn Jacoco test coverage ON or OFF. By default, it is OFF. When set to true, the plugin would run unit tests in your module and generate a coverage report that would later be displayed in the Sonarqube web interface. Please note that packageName and buildVariant parameters must also be supplied in the case when unitTestCoverage is set to true. Note: instrumented tests inside the androidTest package are not supported, but you can use Robolectric to mock the Android framework in your unit tests.

packageName is required if unitTestCoverage is set to true. This must correspond to a package in which your module’s source code is located. In many cases, this value would be the same as the applicationId parameter value.

buildVariant is required if unitTestCoverage is set to true. This is needed for the plugin to only run tests of a particular build variant instead of running all. To see a list of build variants of your module, open Build Variants tab in Android Studio.

Step 4: Run Analysis

Once the configuration is complete, all you need to do is run the plugin. You can run it using Gradle wrapper as below:

./gradlew androidAnalyzer

This task would perform all needed Sonarqube configuration, run tests with coverage if you chose to include coverage, as well as perform Detekt configuration if you chose to run it. After the task is complete, you will see analysis results in Sonarqube web interface:

Sonarqube web interface

I will let you explore the analysis yourself as it is quite easy to get around in Sonarqube. Note that while for experiments and personal projects a local Sonarqube installation is fine, but if you want to integrate it in a larger project, it is better to install Sonarqube on your CI/CD server and trigger analysis when new code is being pushed to your repository.

Hope you enjoyed the article and it was useful for you. In case you are using the Android Analyzer plugin and have questions or issues in relation to it, feel free to create an issue on Github and I will make sure that every question is addressed.

PINCH is a leading Dutch app agency. Being familiar with and working with the latest technologies is part of our work. That, together with our flexible, down-to-earth approach and startup mentality with corporate experience, allows us to add extra value for our customers. PINCH is creating apps for iOS, Android, Tizen, Apple Watch & Apple TV.