Plugins are modules that provide additional functionality to the build system in Android Studio. They can help you perform tasks such as code analysis, testing, or building and deploying your app.

New Plugin Convention

The new plugin convention for Android Studio was introduced in version 3.0 of the Android Gradle plugin, which was released in 2017. While the new plugin convention was officially introduced in Android Studio 3.0, it is still being used and recommended in recent versions of Android Studio.

To define plugins in the build.gradle file, you can add the plugin’s ID to the plugins block.

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id 'com.android.application' version '7.4.2' apply false
    id 'com.android.library' version '7.4.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.8.0' apply false
}

In this example, the plugins block is used to define three different plugins: ‘com.android.application’, ‘com.android.library’, and ‘org.jetbrains.kotlin.android’. Each plugin is identified by its unique ID, and a specific version is specified as well. The ‘apply false’ statement means that the plugin is not applied to the current module yet — it will only be applied when explicitly called later on in the file.

Once you’ve defined your plugins in the build.gradle file, you can fetch them from the settings file. The settings file is typically located in the root directory of your project, and is named settings.gradle. You can add the following code to the settings.gradle file to fetch your plugins:

pluginManagement {
    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "AutoSilentDriveMvvm"
include ':app'

This is an example of the new convention for the settings.gradle file in Android Studio, which includes the pluginManagement and dependencyResolutionManagement blocks.

In the pluginManagement block, repositories are defined where Gradle can search for plugin versions. In this example, gradlePluginPortal(), google(), and mavenCentral() are included as repositories. These repositories provide access to a wide range of plugins that can be used in your Android project.

In the dependencyResolutionManagement block, repositories for dependency resolution are defined. The repositoriesMode is set to FAIL_ON_PROJECT_REPOS, which means that if a repository is defined in a module’s build.gradle file that conflicts with one of the repositories defined here, the build will fail. This helps to ensure that dependencies are resolved consistently across all modules in the project.

Finally, the rootProject.name and include statements are used to specify the name of the root project and the modules that are included in the project. In this example, there is only one module, :app, but you can include multiple modules by adding additional include statements.

Advantages Over Traditional Way

The new convention of defining plugins in the build.gradle file and fetching them from the settings file in Android Studio was introduced to improve the modularity and maintainability of the build system.

Traditionally, plugins were defined in a separate file called “buildscript.gradle” and fetched from a separate “build.gradle” file. This approach made it difficult to manage and update plugins, especially in large projects with many dependencies.

By defining plugins in the build.gradle file, the build system becomes more modular and easier to maintain. Each module can specify its own set of plugins, and the build system can handle transitive dependencies automatically.

Fetching plugins from the settings file also provides a central location for managing and updating plugin versions. This approach ensures that all modules use the same version of a plugin, which helps to avoid conflicts and makes it easier to upgrade to newer versions of a plugin.

Disadvantages

1. Complexity: The new convention adds some complexity to the build system, especially for developers who are not familiar with Gradle or Android Studio. This complexity can make it harder to understand and troubleshoot issues that arise during the build process.
2. Learning Curve: The new convention requires developers to learn a new way of managing plugins, which can take time and effort. Developers who are used to the traditional approach may find it challenging to adapt to the new convention.
3. Migration: Migrating an existing project from the traditional approach to the new convention can be time-consuming and error-prone. Developers may need to update multiple files and dependencies, which can introduce new issues and require extensive testing.