Android Modularization with ARouter

The Problem

As Android apps grow, monolithic codebases become unmaintainable. Teams step on each other, build times increase, and feature boundaries blur.

The Solution: Feature Modules + ARouter

TripBuddy Android demonstrates a modular architecture with clear boundaries:

app/
├── shared/          # KMP: models, Ktor client, repository
├── app_common/      # Base classes, ARouter setup, ServiceLocator
├── feature_home/
├── feature_companion/
├── feature_place/
├── feature_player/
└── feature_favorites/

KMP Shared Layer

Business models, API client, and repository logic live in a Kotlin Multiplatform shared module. This enables future iOS sharing while keeping Android UI platform-specific.

ARouter for Navigation

Inter-module navigation uses ARouter annotations instead of direct Activity imports:

• Each feature module registers its routes independently
• The app module only knows route paths, not implementation classes
• Features can be developed and tested in isolation

ServiceLocator Pattern

app_common provides a centralized ServiceLocator for dependency injection across modules, avoiding circular dependencies between feature modules.

Benefits

1. Parallel development — Teams work on separate feature modules
2. Faster builds — Gradle only rebuilds changed modules
3. Clear ownership — Each module has defined public APIs
4. Testability — Features can be unit tested without the full app

When to Use This Pattern

Modularization pays off when:

• The app has 3+ distinct feature areas
• Multiple developers work simultaneously
• You need to lazy-load features or build flavors
• Clean architecture boundaries matter for long-term maintenance

This is the architecture pattern that separates senior Android architects from feature developers.