Modular Development Tool for Android Client: Challenges and Solutions

Author: vivo Internet Client Team - Wang Zhenyu

This article describes the pain points of Android client modular development and presents a comprehensive solution implemented by the ModularDevTool, including its design ideas, key features, and integration steps.

Background

As the number of business features grows, most Android client projects adopt a modular architecture, splitting the codebase into multiple independent repositories. The article shows an example architecture of the vivo website, which consists of 13 separate modules, each stored in its own repository.

Pain Points

Fully isolated repositories improve code management but introduce several problems:

Complex and error‑prone operations when pulling multiple sub‑repositories and debugging integrated code.

Two integration methods (Maven snapshot vs. direct code include) each have drawbacks such as low efficiency, cumbersome Gradle configuration, and potential dependency conflicts.

Difficulty tracing issues because the relationship between AAR packages and source code is unclear.

During version release, developers must manually update versions, commit changes, trigger Maven publishing, and configure CI for each sub‑module.

Solution Overview

The team built ModularDevTool, a combination of shell scripts and a Gradle plugin, to automate the repetitive tasks in both development and release phases.

Key Features – Development Phase

Centralized management of all sub‑repositories (checkout, branch switching, version handling) from the main repository.

Develop all modules within a single Android Studio project.

One‑click switching between code dependency and Maven dependency, supporting mixed modes.

During compilation, the tool outputs each sub‑module’s version and corresponding commit ID for easy traceability.

Key Features – Release Phase

Modify sub‑module versions only in the main repository; sub‑modules do not need individual changes.

CI can be configured with a single main‑project job that compiles sub‑modules in dependency order, uploads AARs to Maven, and builds the final APK.

Three CI build modes: OnlyApp : Build only the main app (requires sub‑modules already published to Maven). publishSnapshot : Build and upload snapshot AARs for sub‑modules, then build the app. publishRelease : Build and upload release AARs for sub‑modules, then build the app.

Tool Structure

The tool consists of a vsub.sh script and a Gradle plugin ( modular_dev_plugin ). The repository layout includes:

submodules/ : Stores the checked‑out code of each sub‑module.

repositories.xml : Configures each repository’s name, Maven group, modules, artifact IDs, versions, priority, development branch, and commit ID.

Example repositories.xml snippet:

<?xml version="1.0" encoding="utf-8" ?>
<repositories>
    <!-- A repository represents a code base, which may contain multiple modules -->
    <repository>
        <name>lib模块</name>
        <group>com.vivo.space.lib</group>
        <modules>
            <module>
                <artifactid>vivospace_lib</artifactid>
                <version>5.9.8.0-SNAPSHOT</version>
                <priority>0</priority>
            </module>
        </modules>
        <repo>ssh://$user@smartgit:xxxx/VivoCode/xxxx_lib</repo>
        <devbranch>feature_5.9.0.0_xxx_dev</devbranch>
        <commitid>cbd4xxxxxx69d1</commitid>
    </repository>
    ...
</repositories>

The vsub.sh script provides entry points such as:

./vsub.sh sync : Pull all sub‑module code into submodules/ .

./vsub.sh publish : One‑click compile all sub‑modules, generate AARs, and upload to Maven.

Sample implementation of the -pull command:

cd submodules
path=$currPath
files=$(ls $path)
for fileName in $files
do
    if [ ! -d $fileName ]
    then
        continue
    fi
    cd $fileName
    echo -e "\033[33mEntering $fileName\033[0m"
    git pull --rebase
    cd ..
done

Project Build Features

Sync : Pulls sub‑modules, switches to the configured development branch, or checks out a specific commit ID with the -c flag for CI environments.

Sub‑module Dependency Handling : Replaces manual settings.gradle and build.gradle edits with a local.properties file where each module’s dependency mode is defined (0 = Maven, 1 = code).

Publish : Automates snapshot or release publishing based on version strings, respects the priority order defined in repositories.xml , and ensures the correct branch or commit is used.

Integration Steps

Add the modular_dev_plugin Gradle plugin to the main repository.

Apply the settings plugin in settings.gradle and the tools and base plugins in the app module’s build.gradle .

Place repositories.xml and the vsub.sh script in the root of the main repository.

Each sub‑module also applies the modular_dev_plugin and the publish plugin.

Replace concrete version numbers in intermediate sub‑modules with the placeholder "unified" ; the tool substitutes the actual version from repositories.xml during build.

dependencies {
    // Replace concrete version with placeholder
    api "com.vivo.space.lib:vivospace_lib:unified"
}

After these steps, the ModularDevTool is fully integrated.

Current Development Workflow

Clone the main app repository, checkout the target development branch, and open the project in Android Studio.

Update repositories.xml to set the desired devbranch and version for each sub‑module.

Run ./vsub.sh sync to fetch all sub‑module code.

Adjust local.properties to specify Maven or code dependency for each sub‑module, then sync the project.

Conclusion

The ModularDevTool has been used in vivo Wallet, vivo website, and other large‑scale projects for several years. It streamlines multi‑module development, eliminates manual dependency configuration, supports multiple build modes, and provides one‑click packaging. The tool has significantly improved development efficiency, enabled parallel iteration of three+ business lines, and reduced code conflicts by more than 50%.