Configurar sua versão

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O sistema de build do Android compila os recursos e o código-fonte do app e os empacota em APKs ou Android App Bundles que você pode testar, implantar, assinar e distribuir. O Android Studio usa o Gradle (em inglês), um kit de ferramentas de build avançado, para automatizar e gerenciar o processo, permitindo que você defina configurações de build personalizadas e flexíveis. Cada configuração de build pode definir o próprio conjunto de códigos e recursos, reutilizando as partes comuns a todas as versões do app. O plug-in do Android para Gradle trabalha com o kit de ferramentas de build para fornecer processos e configurações ajustáveis que são específicos para criar e testar apps Android.

O Gradle e o plug-in do Android são executados de forma independente do Android Studio. Isso significa que você pode criar seus apps Android pelo Android Studio, pela linha de comando da sua máquina ou usando máquinas em que o Android Studio não está instalado (como servidores de integração contínua). Se você não estiver usando o Android Studio, veja como criar e executar seu app pela linha de comando. A saída do build é a mesma, quer você esteja criando o projeto em uma linha de comando, em uma máquina remota ou usando o Android Studio.

Observação: como o Gradle e o plug-in do Android são executados de forma independente do Android Studio, é necessário atualizar as ferramentas de build separadamente. Leia as notas da versão para saber como atualizar o Gradle e o plug-in do Android.

A flexibilidade do sistema de build do Android permite realizar configurações de build personalizadas sem modificar os arquivos de origem principais do app. Esta seção ajuda a entender como o sistema de build do Android funciona e como ele pode ajudar a personalizar e automatizar várias configurações de build. Se quiser saber mais sobre como implantar seu app, consulte Criar e executar no Android Studio. Para começar a criar configurações de build personalizadas imediatamente usando o Android Studio, consulte Configurar variantes de build.

O processo de build

O processo de build envolve muitas ferramentas e processos que convertem seu projeto em um pacote de aplicativo Android (APK, na sigla em inglês) ou Android App Bundle (AAB). Como esse processo é bastante flexível, é útil entender como ele funciona.

Figura 1. Processo de build de um módulo típico de app Android.

O processo de build de um módulo típico de app Android, conforme mostrado na Figura 1, é realizado de acordo com as etapas gerais abaixo:

  1. Os compiladores convertem seu código-fonte em arquivos DEX (Dalvik Executable), que incluem o bytecode executado em dispositivos Android, e todo o restante em recursos compilados.
  2. O Packager combina os arquivos DEX e os recursos compilados em um APK ou AAB, dependendo do destino de build escolhido. Antes que seu app possa ser instalado em um dispositivo Android ou distribuído para uma loja, como o Google Play, o APK ou o AAB precisa ser assinado.
  3. O Packager assina o APK ou o AAB usando o keystore de lançamento ou de depuração:
    1. Se você estiver criando uma versão de depuração do app, ou seja, um app apenas para teste e caracterização de perfil, o Packager vai assiná-lo com o keystore de depuração. O Android Studio configura novos projetos automaticamente com um keystore de depuração.
    2. Se você estiver criando uma versão de lançamento do app que pretende lançar externamente, o Packager vai assiná-lo com o keystore de lançamento que você precisa configurar. Para criar um keystore de lançamento, veja como assinar seu app no Android Studio.
  4. Antes de gerar seu APK final, o Packager usa a ferramenta zipalign para otimizar seu app para que ele ocupe menos memória quando for executado em um dispositivo.

No final do processo de build, você terá um APK ou AAB de depuração ou de lançamento que pode ser usando para implantar, testar ou lançar o app para usuários externos.

Glossário de build do Android

O Gradle e o plug-in do Android 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, ao passo que o tipo de build de lançamento pode reduzir, ofuscar e assinar seu 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, veja como Configurar tipos de build.
Variações de produtos
As variações de produtos representam diferentes versões do app que podem ser lançadas para os usuários, como versões pagas ou gratuitas. 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, veja como 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. Usando variantes de build, você pode criar a versão de depuração das suas variações de produto durante o desenvolvimento ou versões de lançamento assinadas das suas variações de produto para distribuição. Apesar de não ser necessário configurar as variantes de build diretamente, é preciso configurar os tipos de build e as variações de produto que as formam. A criação de outros tipos de build ou variações de produtos também faz com que outras variantes de build sejam criadas. Para saber como 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 se 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, o Gradle combina as configurações de manifesto.
Dependências
O sistema de build gerencia as dependências do projeto pelo seu sistema de arquivos local e pelos repositórios remotos. Isso evita a necessidade de 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 do build e ele pode assinar seus APKs 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 não assina a versão de lançamento a menos que você defina explicitamente uma configuração de assinatura para esse build. Se você não tem uma chave de lançamento, é possível gerar uma de acordo com a descrição apresentada em Assinar o app.
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 compilação aplica o conjunto de regras adequado para reduzir seu código e recursos usando as ferramentas de redução integradas, como o R8.
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. Lançar um único AAB é a abordagem recomendada, já que oferece a divisão por idioma, além da densidade de tela e da ABI, reduzindo a complexidade de precisar fazer upload de vários artefatos para o Google Play.

Arquivos de configuração de build

Para criar configurações de build personalizadas, você precisa mudar um ou mais arquivos de configuração de build, ou arquivos build.gradle. Esses arquivos de texto simples usam a Domain Specific Language (DSL) para descrever e manipular a lógica de build que usa o Groovy (em inglês), que é uma linguagem dinâmica para a Java Virtual Machine (JVM). Não é preciso conhecer o Groovy para começar a configurar seu build, já que o plug-in do Android para Gradle apresenta a maior parte dos elementos DSL necessários. Para saber mais sobre a DSL do plug-in do Android, leia a documentação de referência da DSL (link em inglês).

Ao iniciar um novo projeto, o Android Studio cria automaticamente alguns arquivos para você, conforme mostrado na Figura 2, e os preenche com base em padrões razoáveis.

Figura 2. Estrutura de projeto padrão de um módulo de app para Android.

Existem alguns arquivos de configuração de build do Gradle que fazem parte da estrutura de projeto padrão de um app Android. Antes de começar a configurar seu build, é importante entender o escopo e o propósito de cada um desses arquivos, além dos elementos DSL básicos que eles precisam definir.

Arquivo de configurações do Gradle

O arquivo settings.gradle, localizado no diretório raiz do projeto, define as configurações de repositório e informa ao Gradle os módulos que vão ser incluídos ao criar seu app. Para a maior parte dos projetos, o arquivo tem esta aparência por padrão:

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. The code below
     * defines 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’

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. The code below
     * defines 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")

Projetos com vários módulos precisam especificar cada módulo a ser incluído no build final.

Arquivo de build de nível superior

O arquivo build.gradle de nível superior, localizado no diretório raiz do projeto, define dependências que se aplicam a todos os módulos do seu projeto. Por padrão, o arquivo de build de nível superior usa o bloco plugins para definir as dependências do Gradle que são comuns a todos os módulos do projeto. Além disso, o arquivo de build de nível superior contém código para limpar o diretório do build. O exemplo de código a seguir descreve as configurações padrão e os elementos de DSL encontrados no arquivo build.gradle de nível superior após a criação de um novo projeto.

Groovy

plugins {

    /**
     * You should 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. You should not use `apply false` in sub-projects.
     * For more information, see
     * Applying external plugins with same version to subprojects.
     */

    id 'com.android.application' version '7.3.0' apply false
    id 'com.android.library' version '7.3.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.7.20' apply false
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

Kotlin

plugins {

    /**
     * You should 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. You should not use `apply false` in sub-projects.
     * For more information, see
     * Applying external plugins with same version to subprojects.
     */

    id("com.android.application") version "7.1.0-beta02" apply false
    id("com.android.library") version "7.1.0-beta02" apply false
    id("org.jetbrains.kotlin.android") version "1.5.30" apply false
}

tasks.register("clean", Delete::class) {
    delete(rootProject.buildDir)
}

Configurar propriedades para todo o projeto

Para projetos do Android que incluem diversos módulos, pode ser útil definir algumas propriedades no nível do projeto e as compartilhar em todos os módulos. Você pode fazer isso adicionando propriedades extras (em inglês) ao bloco ext no arquivo build.gradle de nível superior.

Groovy

// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
    sdkVersion = 28
    // You can also create properties to specify versions for dependencies.
    // Having consistent versions between modules can avoid conflicts with behavior.
    supportLibVersion = "28.0.0"
    ...
}
...

Kotlin

// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
  extra["compileSdkVersion"] = 28
  // You can also create properties to specify versions for dependencies.
  // Having consistent versions between modules can avoid conflicts with behavior.
  extra["supportLibVersion"] = "28.0.0"
...
}
...

Para acessar essas propriedades em um módulo no mesmo projeto, use a sintaxe abaixo no arquivo build.gradle do módulo. Saiba mais sobre esse arquivo na próxima seção.

Groovy

android {
    // Use the following syntax to access properties you defined at the project level:
    // rootProject.ext.property_name
    compileSdkVersion rootProject.ext.compileSdkVersion
    ...
}
...
dependencies {
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    ...
}

Kotlin

android {
    // Use the following syntax to access properties you defined at the project level:
    // rootProject.extra["property_name"]
    compileSdk = rootProject.extra["sdkVersion"]

    // Alternatively, you can access properties using a type safe delegate:
    val sdkVersion: Int by rootProject.extra
    ...
    compileSdk = sdkVersion
}
...
dependencies {
    implementation("com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}")
    ...
}

Observação: embora o Gradle permita definir propriedades de todo o projeto no nível do módulo, evite fazer isso. Essa ação vincula os módulos que compartilham as propriedades. A vinculação de módulos dificulta a exportação posterior de um módulo como projeto independente e impede que o Gradle use a execução paralela de projetos para agilizar os builds que têm vários módulos (em inglês).

Arquivo de build de módulo

O arquivo build.gradle de módulo, localizado em cada diretório project/module/, permite definir configurações de build para o módulo específico em que ele se encontra. A definição dessas configurações permite disponibilizar opções de empacotamento personalizadas, como tipos de build e variações de produtos extras, além de substituir as configurações no manifesto do app main/ ou no arquivo build.gradle de nível superior.

Este arquivo build.gradle de exemplo de módulo de um app Android descreve alguns elementos DSL básicos e algumas configurações que você precisa conhecer.

Groovy

/**
 * The first line in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android block available to specify
 * Android-specific build options.
 */

plugins {
  id 'com.android.application'
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

    /**
     * The app's namespace. Used primarily to access app resources.
     */

    namespace 'com.example.myapp'

    /**
     * compileSdkVersion specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdkVersion 28

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants, and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 15

        // Specifies the API level used to test the app.
        targetSdkVersion 28

        // Defines the version number of your app.
        versionCode 1

        // Defines a user-friendly version name for your app.
        versionName "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies Proguard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default Proguard rules file.
         */

        release {
              minifyEnabled true // Enables code shrinking for the release build type.
              proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This allows you to create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store, or an Android device, simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions "tier"
    productFlavors {
        free {
            dimension "tier"
            applicationId 'com.example.myapp.free'
        }

        paid {
            dimension "tier"
            applicationId 'com.example.myapp.paid'
        }
    }
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation project(":lib")
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

Kotlin

/**
 * The first section in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android block available to specify
 * Android-specific build options.
 */

plugins {
    id("com.android.application")
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

   /**
    * The app's namespace. Used primarily to access app resources.
    */

    namespace = "com.example.myapp"

    /**
     * compileSdkVersion specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdk = 28

    /**
     * buildToolsVersion specifies the version of the SDK build tools, command-line
     * utilities, and compiler that Gradle should use to build your app. You need to
     * download the build tools using the SDK Manager.
     *
     * This property is optional because the plugin uses a recommended version of
     * the build tools by default.
     */

    buildToolsVersion = "30.0.2"

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants, and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdk = 15

        // Specifies the API level used to test the app.
        targetSdk = 28

        // Defines the version number of your app.
        versionCode = 1

        // Defines a user-friendly version name for your app.
        versionName = "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies Proguard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default Proguard rules file.
         */

        getByName("release") {
            isMinifyEnabled = true // Enables code shrinking for the release build type.
            proguardFiles(
                getDefaultProguardFile("proguard-android.txt"),
                "proguard-rules.pro"
            )
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This allows you to create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store, or an Android device, simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions = "tier"
    productFlavors {
        create("free") {
            dimension = "tier"
            applicationId = "com.example.myapp.free"
        }

        create("paid") {
            dimension = "tier"
            applicationId = "com.example.myapp.paid"
        }
    }
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation(project(":lib"))
    implementation("com.android.support:appcompat-v7:28.0.0")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

Arquivos de propriedades do Gradle

O Gradle também contém dois arquivos de propriedades, localizados no diretório raiz do projeto, que são úteis para especificar configurações para o próprio kit de ferramentas de build do Gradle:

gradle.properties
Nesse arquivo, é possível definir configurações do Gradle para todo o projeto, como o tamanho máximo de heap do daemon. Para saber mais, consulte o Ambiente de build.
local.properties
Configura as propriedades de ambiente local do sistema de build, incluindo as seguintes:
  • ndk.dir: caminho para o NDK. Essa propriedade foi descontinuada. Todas as versões do NDK transferidas por download serão instaladas no diretório ndk do Android SDK.
  • sdk.dir: caminho para o SDK.
  • cmake.dir: caminho para o CMake.
  • ndk.symlinkdir: no Android Studio 3.5 e versões mais recentes, cria um link simbólico para o NDK que pode ser mais curto que o caminho do NDK instalado.

Remapear o NDK para um caminho mais curto (somente Windows)

O problema mais comum com caminhos longos do Windows é que ferramentas como ld.exe na pasta do NDK acabam com caminhos muito profundos sem um bom suporte.

Em local.properties, é possível definir a propriedade ndk.symlinkdir para solicitar que o plug-in do Gradle crie um link simbólico para o NDK. O caminho desse link simbólico pode ser menor que a pasta do NDK existente. Por exemplo, ndk.symlinkdir = C:\ resultará no seguinte link simbólico: C:\ndk\19.0.5232133

Sincronizar o projeto com arquivos do Gradle

Quando você muda os arquivos de configuração de build do seu projeto, o Android Studio exige a sincronização dos arquivos para permitir a importação das mudanças e a execução de algumas verificações, garantindo que as configurações não criem erros de build.

Para sincronizar os arquivos do projeto, clique em Sync Now na barra de notificações que aparece quando você faz mudanças (conforme mostrado na Figura 3) ou clique em Sync Project na barra de menus. Se o Android Studio perceber erros na sua configuração, por exemplo, se o código-fonte usar recursos da API que só estão disponíveis em um nível de API mais recente que sua compileSdkVersion, a janela Messages vai aparecer com uma descrição do problema.

Figura 3. Sincronização do projeto com arquivos de configuração de build no Android Studio.

Conjuntos de origem

O Android Studio agrupa o código-fonte e os recursos de maneira lógica para cada módulo, criando conjuntos de origem. O conjunto de origem main/ de um módulo contém os códigos e recursos usados por todas as variantes de build dele. Outros diretórios de conjuntos de origem são opcionais e não são criados automaticamente pelo Android Studio quando você configura novas variantes de build. No entanto, a criação de conjuntos de origem, de maneira semelhante ao main/, ajuda a organizar os arquivos e recursos que o Gradle vai usar apenas ao criar algumas versões do app.

src/main/
Esse conjunto de origem inclui os códigos e recursos comuns a todas as variantes de build.
src/buildType/
Crie esse conjunto de origem para incluir os códigos e recursos somente de um tipo de build específico.
src/productFlavor/
Crie esse conjunto de origem para incluir os códigos e recursos de uma variação de produto específica.

Observação: caso seu build seja configurado para combinar diversas variações de produto, você vai poder criar diretórios de conjuntos de origem para cada combinação de variações de produto entre as dimensões de variações: src/productFlavor1ProductFlavor2/

src/productFlavorBuildType/
Crie esse conjunto de origem para incluir os códigos e recursos de uma variante de build específica.

Por exemplo, para gerar a versão "fullDebug" do app, o sistema de build combina códigos, configurações e recursos dos seguintes conjuntos de origem:

  • src/fullDebug/ (o conjunto de origem da variante de build)
  • src/debug/ (o conjunto de origem do tipo de build)
  • src/full/ (o conjunto de origem da variação de produto)
  • src/main/ (o conjunto de origem principal)

Observação: ao criar um novo arquivo ou diretório no Android Studio usando as opções de menu File > New, é possível criá-lo para um conjunto de origem específico. Os conjuntos de origem disponíveis para escolha se baseiam nas suas configurações de build, e o Android Studio cria os diretórios necessários automaticamente caso eles ainda não existam.

Caso conjuntos de origem diferentes contenham versões diferentes do mesmo arquivo, o Gradle vai usar a seguinte ordem de prioridade para decidir qual arquivo utilizar. Os conjuntos de origem à esquerda modificam os arquivos e as configurações dos conjuntos de origem à direita:

variante de build > tipo de build > variação de produto > conjunto de origem principal > dependências de biblioteca

Isso permite que o Gradle use arquivos específicos da variante de build que você está tentando criar reutilizando atividades, lógica de app e recursos comuns a outras versões do seu app. Ao combinar diversos manifestos, o Gradle usa a mesma ordem de prioridade. Dessa forma, cada variante de build pode definir diferentes componentes ou permissões no manifesto final. Para saber mais sobre a criação de conjuntos de origem personalizados, acesse Criar conjuntos de origem para variantes de build.