Refactor common build logic into a set of Gradle plugins

[liutikas]

Creates androidify.applicationPlugin, androidify.libraryPlugin, and androidify.composeLibraryPlugin that picks up common logic from build.gradle.kts files and reduces duplication it build logic

Test: ./gradlew testDebugUnitTest -x app:testDebugUnitTest
Fixes #172

[gemini-code-assist]

Summary of Changes

Hello @liutikas, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the project's Gradle build system by extracting common Android build configurations into a set of reusable custom Gradle plugins. This change significantly reduces boilerplate code in individual module build.gradle.kts files, making the build configuration more consistent, easier to manage, and less prone to errors across the entire project. The new plugins centralize settings for Android applications, libraries, and Compose-enabled libraries.

Highlights

• New Gradle Plugins: Introduced three custom Gradle plugins: androidify.applicationPlugin, androidify.libraryPlugin, and androidify.composeLibraryPlugin. These plugins encapsulate common Android build configurations, such as SDK versions, Java compatibility, Kotlin JVM target, and Compose setup.
• Reduced Build Logic Duplication: Existing build.gradle.kts files across various modules (app, core, feature, wear, watchface) have been significantly simplified. Redundant configurations for compileSdk, minSdk, targetSdk, javaVersion, jvmTarget, compose build features, and testInstrumentationRunner have been removed, as they are now centrally managed by the new plugins.
• Dedicated Build Logic Module: A new build-plugin module has been added to the project. This module serves as a dedicated location for housing the custom Gradle plugins, improving the modularity, organization, and maintainability of the build system.
• Version Catalog Enhancements: The gradle/libs.versions.toml file has been updated to include a targetSdk version and new aliases for the custom androidify plugins, along with dependencies required for the build-logic module itself.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request does an excellent job of refactoring common Gradle build logic into a set of convention plugins. This greatly reduces code duplication across the various build.gradle.kts files and improves the overall maintainability of the build process. The new build-plugin module is well-structured. I've identified a couple of minor omissions in the new plugins that should be addressed to ensure build configurations remain consistent with their state before this refactoring. Overall, this is a solid improvement.

[riggaroo]

Is it possible to pull these numbers from libs.versions.toml?

[ducrohet]

The whole point of declaring compileSdk (and minSdk and targetSdk) in settings.gradle is so that it does not need to be set in each subproject, so there's no need to put the values in the catalog file.