Multiple Module Dependency setup ��

The purpose of this repo to demonstrate the use of a custom Gradle plugin to centralize the dependency management in multi-module app setup.

When you start breaking down your Android app into different modules you need to do the following steps for each one:

• Define compileSdkVersion, buildToolsVersion, minSdkVersion, targetSdkVersion etc.
• Copy the dependencies block even though you might be repeating yourself. This is specially true for common and test dependencies.
• Make sure each feature module depends on the app module or whatever base module you have. Turn outs this is a bit of complex scenario to infer for simple use case. This has been removed from the Plugin implementation.

I recently started working on a sample project which demonstrate the use of dynamic-feature modules and found myself in a similar situation.This lead me to do some research on the topic and �� found people already have a solution.There are a couple of blog posts that I found interesting (outlined below) and inspired me to dig further.

About ��

The repo contains two example android modules namely sampleapp and samplelib. These modules demonstrate the usage of the Plugin in their respective build.gradle files here and here.

The, AndroidModulePlugin, plugin will configure the following for each of the modules:

• compileSdkVersion, buildToolsVersion, minSdkVersion, targetSdkVersion, compileOptions, testInstrumentationRunner
• Add common test dependencies like junit, mockk
• Configure SonarQube and its properties
• Configure Jacoco

Note: You can still override properties which are set by this plugin, by just configuring them again using the android {} or other blocks �� .

Use it in your project ��

The actual setup is pretty simple. The code is also pretty self-explanatory. All you have to do is copy the buildSrc folder to root of your app project.And click on Gradle sync so that gradle can pick up the source and build the plugin and add it to build phase.

After the project builds successfully the only step is to apply the plugin in your individual app/library/feature modules build.gradle.

apply plugin: 'dev.nikhi1.plugin.android'

Make sure to apply this plugin after either application, library and/or dynamic-feature plugin definition in their respective gradle files.

Why Jacoco?

Jacoco is a tool to measure code coverage and currently the most widely used.

Code coverage in simple terms means how much of the production code that you wrote is being executed at runtime when a particular test suite runs.

To measure this you write Unit/UI/Integration tests. And this is what Jacoco does under the hood, it hooks on to these tests while they are executing. In the process, it can see what code is executed as part of the tests and calculates its coverage.These coverages are helpful, for example, if you have miss handling an else branch in one of your test cases.

Though on Android, the test execution data (.ec file) for UI test cases is not taken into account by Jacoco and hence we have to tweak the gradle task and make sure if also reads those files to give a complete code coverage across Unit and UI/Integration test cases.

The task outputs xml reports per module which are uploaded to SonarQube for a nice looking dashboard �� .

This example repo has 100% code coverage. Of course this doesn't mean the code is rock solid and is following all the SOLID principles of software engineering. It's more an indicator that code bases are lacking test cases and we should do something about it �� .

If you are not ready with test cases yet then remove the method configureJacoco from the AndroidModulePlugin class. Every method is self-contained and could be added/removed on need basis.

Why SonarQube?

SonarQube is the leading tool for continuously inspecting the Code Quality and Security of your codebases and guiding development teams during Code Reviews.

These analyses are driven by automated Static Code Analysis rules. You can add your own rules or use detekt rules for analysis as well.

The Plugin configures the different properties required for SonarQube plugin to work properly. For example, the path of the Jacoco xml reports etc. Check here.

This repo uses sonarcloud.io which is free for open-source projects and is a cloud hosted solution. But in most cases, there would be a private hosted SonarQube server running in the infra. Just configure the Plugin with correct values.

Refer this github action if you feel lost.

A word about CI ⚙️

Irrespective of any CI tool, in theory, we need to run some gradle tasks. These gradle tasks are for most cases either run Unit and/or UI tests. Post that some static code analysis which could be either ktlint or detekt or something on similar lines.

Here is the minimum gradle tasks that needs to be run

./gradlew clean connectedDebugAndroidTest jacocoTestDebugUnitTestReport sonarqube

Ofcourse you have to make sure that an emulator/device is up and running in order to run the UI test cases.

If everything is set up properly, you should be able to see the analysis report on the configured SonarQube instance.

Minimum requirements

• Gradle version: v6.x
• Android Studio: v4.0

Known limitations

• Currently there is no way to combine the jacoco reports across different modules. This plugin might help.
• Cannot skip SonarQube analysis for a particular module.
• Not tested with Roboelectric framework.

References

• Managing dependencies in multi-module setup
• buildSrc Trick
• Modularization Tips
• Code coverage in practice
• Android Gradle Plugin Reference - Not sure if this is being maintained