android-build-logic-gradlelisted

# Android Build Logic and Gradle ## Core Principles - Shared build rules belong in build logic, not copied across modules. - Prefer convention plugins over large repeated `build.gradle.kts` blocks. - Use version catalogs for dependency and version management. - Keep module build files small, declarative, and predictable. - Optimize build logic for clarity first, then performance. --- ## Recommended Ownership A modular Android repo typically keeps shared build logic in: ```text :build-logic -> convention plugins -> shared Gradle configuration helpers -> plugin dependency setup ``` Application and library modules should mostly apply plugins and declare only module-specific dependencies/options. See the **android-module-structure** skill for the broader architecture view. --- ## Convention Plugins Use convention plugins for repeated setup such as: - Android application defaults - Android library defaults - feature module defaults - Compose setup - Koin setup - Room/KSP setup - Kotlin serialization setup - test stack defaults Example plugin names: - `android-application` - `android-library` - `android-feature` - `domain-module` - `compose` - `koin` - `room` A module should read more like configuration selection than low-level build wiring. --- ## Version Catalogs Use `libs.versions.toml` for: - library coordinates - plugin coordinates - shared versions - bundles when they improve clarity Rules: - avoid hardcoded versions in module build files - keep aliases