Configurar sua compilação

O sistema de build do Android compila os recursos e o código-fonte do app e os coloca em APKs ou Android App Bundles que podem ser testados, implantados, assinados e distribuídos.

Nas seções Visão geral do build do Gradle e Estrutura de build do Android, discutimos os conceitos de build e a estrutura de um app Android. Agora é hora de configurar o build.

Glossário de build do Android

O Gradle e o Plug-in do Android para Gradle ajudam a configurar estes aspectos do build:

Tipos de build

Os tipos de build definem algumas propriedades que o Gradle usa ao criar e empacotar seu app. Geralmente, eles são configurados para diferentes fases do ciclo de desenvolvimento.

Por exemplo, o tipo de build de depuração oferece opções de depuração e assina o app com a chave de depuração. Já o de lançamento pode reduzir, ofuscar e assinar o app com uma chave de lançamento para distribuição.

É necessário definir pelo menos um tipo de build para criar seu app. Por padrão, o Android Studio cria os tipos de build de depuração e lançamento. Para começar a personalizar as configurações de empacotamento do app, aprenda a configurar tipos de build.

Variações de produtos
As variações de produto representam diferentes versões do app que podem ser lançadas para os usuários, como versões pagas e sem custos. Você pode personalizar as variações de produtos para usar códigos e recursos diferentes, ao mesmo tempo que compartilha e reutiliza as partes comuns a todas as versões do app. As variações de produto são opcionais e precisam ser criadas manualmente. Para começar a criar diferentes versões do app, aprenda a configurar variações de produtos.
Variantes de build
Uma variante de build é o produto resultante da combinação de um tipo de build e uma variação de produto. Essa é a configuração que o Gradle usa para criar seu app. Com as variantes de build, você pode criar a versão de depuração das suas variações de produto durante o desenvolvimento, além de criar versões de lançamento assinadas dessas variações para distribuição. Embora as variantes de build não sejam configuradas diretamente, é necessário configurar os tipos de build e as variações de produto que compõem essas variantes. A criação de outros tipos de build ou variações de produtos também faz com que outras variantes sejam criadas. Para aprender a criar e gerenciar variantes de build, leia a visão geral sobre como Configurar variantes de build.
Entradas do manifesto
Você pode especificar valores para algumas propriedades do arquivo de manifesto na configuração da variante de build. Eles substituem os valores existentes no arquivo de manifesto. Isso é útil quando você quer gerar diversas variantes do seu app com um nome diferente, versão mínima do SDK ou versão de destino do SDK. Quando há vários manifestos, a ferramenta de combinação de manifestos combina as configurações de manifesto.
Dependências
O sistema de build gerencia as dependências do projeto no sistema de arquivos local e nos repositórios remotos. Isso significa que não é necessário pesquisar, fazer o download e copiar manualmente pacotes binários das suas dependências para o diretório do projeto. Para saber mais, consulte Adicionar dependências de build.
Assinaturas
O sistema de build permite especificar opções de assinatura nas configurações e pode assinar seu app automaticamente durante o processo de build. O sistema assina a versão de depuração com uma chave e um certificado padrão, usando credenciais conhecidas para evitar solicitações de senha no momento do build. O sistema só assina a versão de lançamento se você define explicitamente uma configuração de assinatura para esse build. Caso você não tenha uma chave de lançamento, é possível gerar uma de acordo com a descrição apresentada em Assinar o app. A maioria das app stores exigem builds de lançamento assinados para que os apps sejam distribuídos.
Redução de código e recursos
O sistema de build permite especificar um arquivo de regras do ProGuard diferente para cada variante de build. Ao criar seu app, o sistema de build aplica o conjunto de regras adequado para reduzir seu código e recursos usando as ferramentas de redução integradas, como o R8. Reduzir o código e os recursos pode ajudar a diminuir o tamanho do APK ou AAB.
Suporte a vários APKs
O sistema de build permite criar diferentes APKs automaticamente, cada um contendo apenas os códigos e recursos necessários para uma densidade de tela ou Interface binária do aplicativo (ABI) específica. Para saber mais, consulte Criar vários APKs. No entanto, o recomendado é lançar apenas um ABB, já que ele oferece a divisão por idioma, a densidade de tela e a ABI sem que seja necessário fazer upload de vários artefatos para o Google Play. Todos os apps enviados depois de agosto de 2021 precisam usar AABs.

Versões Java em builds do Android

Se o código-fonte for escrito em Java, Kotlin ou ambos, há vários lugares em que você precisa escolher uma versão do JDK ou do Java para o build. Consulte Versões Java em builds do Android para mais detalhes.

Arquivos de configuração de compilação

Para criar configurações de build personalizadas, você precisa mudar um ou mais arquivos de configuração de build. Esses arquivos de texto simples usam uma linguagem específica do domínio (DSL) para descrever e manipular a lógica de build usando o script Kotlin, uma variação da linguagem Kotlin. Também é possível usar o Groovy, que é uma linguagem dinâmica para a máquina virtual Java (JVM), para configurar seus builds.

Você não precisa conhecer o script Kotlin ou o Groovy para começar a configurar seu build, já que o Plug-in do Android para Gradle apresenta a maioria dos elementos DSL necessários. Para saber mais sobre a DSL do Plug-in do Android para Gradle, leia a documentação de referência da DSL. O script Kotlin também depende da DSL do Kotlin para Gradle (link em inglês).

Ao iniciar um novo projeto, o Android Studio cria automaticamente alguns desses arquivos para você e os preenche com base em padrões razoáveis. Para uma visão geral dos arquivos criados, consulte Estrutura do build do Android.

O arquivo Gradle Wrapper

O wrapper do Gradle (gradlew) é um pequeno aplicativo incluído no código-fonte que faz o download e inicia o próprio Gradle. Isso cria uma execução de build mais consistente. Os desenvolvedores fazem o download da fonte do aplicativo e executam gradlew. Isso faz o download da distribuição necessária do Gradle e inicia o Gradle para criar seu aplicativo.

O arquivo gradle/wrapper/gradle-wrapper.properties contém uma propriedade, distributionUrl, que descreve qual versão do Gradle é usada para executar o build.

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

Arquivo de configurações do Gradle

O arquivo settings.gradle.kts (para a DSL do Kotlin) ou settings.gradle (para a DSL do Groovy) fica localizado no diretório raiz do projeto. Esse arquivo de configurações define as configurações de repositório do projeto e informa ao Gradle quais módulos ele deve incluir ao criar seu app. Projetos com vários módulos precisam especificar cada um dos que serão incluídos no build final.

Por padrão, o arquivo fica assim na maior parte dos projetos:

Kotlin

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
      google()
      mavenCentral()
  }
}
rootProject.name = "My Application"
include(":app")

Groovy

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "My Application"
include ':app'

Arquivo de build de nível superior

O arquivo build.gradle.kts de nível superior (para a DSL do Kotlin) ou build.gradle (para a DSL do Groovy) está localizado no diretório raiz do projeto. Ele normalmente define as versões comuns de plug-ins usados por módulos no projeto.

O exemplo de código a seguir descreve as configurações padrão e os elementos de DSL no script de build de nível superior após a criação de um novo projeto:

Kotlin

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id("com.android.application") version "8.10.0" apply false
    id("com.android.library") version "8.10.0" apply false
    id("org.jetbrains.kotlin.android") version "2.1.20" apply false
}

Groovy

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id 'com.android.application' version '8.10.0' apply false
    id 'com.android.library' version '8.10.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.1.20' apply false
}