Plugins são módulos que fornecem funcionalidade adicional ao sistema de compilação no Android Studio. Eles podem ajudá-lo a executar tarefas como análise de código, teste ou criação e implantação de seu aplicativo.

A nova convenção de plug-in para Android Studio foi introduzida na versão 3.0 do plug-in Android Gradle , lançada em 2017 . Embora a nova convenção de plug-ins tenha sido introduzida oficialmente no Android Studio 3.0, ela ainda está sendo usada e recomendada em versões recentes do Android Studio .

Para definir plug-ins no arquivo build.gradle, você pode adicionar o ID do plug-in ao bloco de plug-ins.

// 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
}

Depois de definir seus plug-ins no arquivo build.gradle, você pode buscá-los no arquivo de configurações . O arquivo de configurações geralmente está localizado no diretório raiz do seu projeto e é denominado settings.gradle . Você pode adicionar o seguinte código ao arquivo settings.gradle para buscar seus plugins:

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

No pluginManagementbloco, são definidos os repositórios onde o Gradle pode pesquisar as versões do plug-in. Neste exemplo, gradlePluginPortal(), google()e mavenCentral()estão incluídos como repositórios. Esses repositórios fornecem acesso a uma ampla variedade de plug-ins que podem ser usados ​​em seu projeto Android.

No dependencyResolutionManagementbloco são definidos repositórios para resolução de dependências. O repositoriesModeé definido como FAIL_ON_PROJECT_REPOS, o que significa que, se um repositório for definido no arquivo build.gradle de um módulo que entrar em conflito com um dos repositórios definidos aqui, a compilação falhará. Isso ajuda a garantir que as dependências sejam resolvidas de forma consistente em todos os módulos do projeto .

Por fim, as instruções rootProject.namee includesão usadas para especificar o nome do projeto raiz e os módulos incluídos no projeto. Neste exemplo, há apenas um módulo, :app, mas você pode incluir vários módulos adicionando includeinstruções adicionais.

Vantagens sobre a forma tradicional

A nova convenção de definir plug-ins no arquivo build.gradle e buscá-los no arquivo de configurações no Android Studio foi introduzida para melhorar a modularidade e a capacidade de manutenção do sistema de compilação .

Tradicionalmente, os plugins eram definidos em um arquivo separado chamado “buildscript.gradle” e obtidos de um arquivo “build.gradle” separado. Essa abordagem dificultou o gerenciamento e a atualização de plug-ins, especialmente em grandes projetos com muitas dependências.

Ao definir plug-ins no arquivo build.gradle, o sistema de compilação torna-se mais modular e mais fácil de manter. Cada módulo pode especificar seu próprio conjunto de plug-ins e o sistema de construção pode lidar com dependências transitivas automaticamente.

A busca de plug-ins do arquivo de configurações também fornece um local central para gerenciar e atualizar as versões do plug-in. Essa abordagem garante que todos os módulos usem a mesma versão de um plug-in, o que ajuda a evitar conflitos e facilita a atualização para versões mais recentes de um plug-in .

Desvantagens

1. Complexidade: a nova convenção adiciona alguma complexidade ao sistema de compilação, especialmente para desenvolvedores que não estão familiarizados com Gradle ou Android Studio. Essa complexidade pode dificultar a compreensão e a solução de problemas que surgem durante o processo de compilação.
2. Curva de aprendizado: a nova convenção exige que os desenvolvedores aprendam uma nova maneira de gerenciar plug-ins, o que pode levar tempo e esforço. Os desenvolvedores acostumados com a abordagem tradicional podem achar difícil se adaptar à nova convenção .
3. Migração: migrar um projeto existente da abordagem tradicional para a nova convenção pode ser demorado e propenso a erros . Os desenvolvedores podem precisar atualizar vários arquivos e dependências , o que pode apresentar novos problemas e exigir testes extensivos .