Monitoring Android Codebase
By: Fajar Ulin Nuha
Tags: AndroidDev, Software Engineering, Andriod App Development, Android

Being an Android Engineer as a team is not merely about implementing features, debugging, or creating tests, but we also need to think about how to maintain our codebase and development environment.

For example, when you start an Android project, you simply need to set up a hello-world project and implement a feature. But things start becoming big in just a couple of months, and you would start adding more entities to your development environment. You start adding CI/CD systems. Then, you start refactoring the code. In our case, we have more than 50 engineers working in the same codebase altogether. Our codebase is just changing constantly.

This is just a sample screenshot from our Github about how much code changes in just 1 week.

The data shown above is just so overwhelming. How can we manage a codebase wherein each week new modules are created, new dependencies are incorporated, and a new app bundle is introduced? If this is not taken carefully, we might make bad decisions by assuming something. We need to see the big picture by seeing from the high ground.

We need to see facts, not assumptions.

One of our principles is that we want to be a Data-Driven Developer, in which we judge and make decisions based on data. For instance, is a module big enough, so it needs to be broken down into another module? How big is it? What part of it makes it so big? Is it the resource or the code? To answer these questions, we can not just feel how big it is, but we need to know the facts in numbers.

For that, we develop a data infrastructure that collects metrics from our codebase. These data metrics might be but are not limited to: modules number, Kotlin percentage, resource size, app size, dynamic feature module number, performance time, etc. In fact, we have hundreds of metrics that we can get insight from.

Data Architecture

Alright, we are just Android Engineers who need a simple approach. We are not talking about data architecture for the enterprise. We are just talking about data architecture for practical use. So here is 3 essentials process when we want to play with data.

rules number 1: KISS

In this blog post, we want to share our approach to providing data for our development environment. We will break down each process and share what technology stack we use to tackle each problem.

1. Collecting Data

The main source for this data collection is the codebase itself.

There are many kinds of data we can get from our source code. We can get source code information, such as source code size, source code history. In more advance, we can get per module dependencies behavior, app bundle information, and many more.

For the simplest example: To get how many Android modules in the project, we can loop to the root project and count the Android folder. Actually, we can do it in so many ways. Yes, we can do it in a java program, shell, python script, or Gradle plugin. Anything is possible. But for gathering dependency and module’s data, we prefer to create a custom Gradle Plugin to retrieve, because we can get better data integrity in terms of dependency and build configuration.

Pseudocode to get all module name in the Android project:

this can be translated to Gradle Plugin

The above code will give output the CSV file like below:

output.csv:

ModuleName,ModulePath

home,feature/home

search,feature/search

product,feature/product

image_picker,libraries/image_picker

…

The output may not always be in the CSV format. However, we recommend the output should be in a file. A JSON format file is also great. This file can later become the input for the next step: Storing Data.

2. Storing Data

Once the data collection is ready, we might be able to analyze directly. However, sometimes, we want to compare today’s data and last month’s data and see any significant difference.

If we do not store this data, we are losing the ability to compare the historical data. Therefore, storing data is important.

There are many options for data storage. We can use the database: SQL, MySQL, InfluxDB, etc. Or we can also put the data in the Google Sheets, which is more intuitive and easy to learn.

3. Visualizing Data

Once the data is stored in a database or spreadsheet, we need to visualize the data to analyze the data better.

Again, we have so many options to do this. We can use any visualization dashboard tools: Google Data Studio, Grafana, Tableau, or Kibana.