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.
O Android Studio usa o Gradle (link 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 para Gradle são executados de forma independente do Android Studio. Isso significa que você pode criar seus apps Android no Android Studio, na 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 na 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 pelo Android Studio.
Observação: como o Gradle e o Plug-in do Android para Gradle são executados de forma independente do Android Studio, é necessário atualizar as ferramentas de build separadamente. Leia as notas da versão para aprender a atualizar o Gradle e o Plug-in do Android para Gradle.
A flexibilidade do sistema de build do Android permite criar configurações de build personalizadas sem modificar os arquivos de origem principais do app. Esta página 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 a implantação do app, consulte Criar e executar o app. Para já começar a criar configurações de build personalizadas com o Android Studio, leia 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) ou em um Android App Bundle (AAB).
O Plug-in do Android para Gradle realiza grande parte desse processo de build, mas entender alguns aspectos desse processo pode ser útil para conseguir ajustar o build da maneira que você achar necessário.
Projetos diferentes podem ter metas de build distintas. Por exemplo, o build de uma biblioteca de terceiros produz bibliotecas Android Archive (AAR) ou Java Archive (JAR). Contudo, o tipo de projeto mais comum é o app. O build de um projeto de app gera um APK ou AAB de depuração ou de lançamento, que pode ser implantado, testado ou lançado para usuários externos.
Esta página se concentra no desenvolvimento de apps, mas muitas das etapas e dos conceitos apresentados são comuns na maioria dos tipos de 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.
- Compatibilidade com 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
Não importa se o código-fonte foi escrito em Java, Kotlin ou ambos, há vários lugares em que você precisa escolher uma versão da linguagem JDK ou Java para o build. Consulte Versões do Java em builds do Android para mais detalhes.
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. Esses arquivos de texto simples usam a linguagem específica de domínio (DSL, na sigla em inglês) para descrever e manipular a lógica de build usando o script Kotlin, que é uma variação da linguagem Kotlin. Também é possível usar o Groovy, que é uma linguagem dinâmica para a Java Virtual Machine (JVM), para configurar suas builds.
Não é necessário conhecer o script Kotlin ou o Groovy para começar a configurar seu build, já que o Plug-in do Android para Gradle introduz 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 de DSL. O script Kotlin também depende da DSL Kotlin do 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 sensíveis. A estrutura do arquivo do projeto tem o seguinte layout:
└── MyApp/ # Project ├── gradle/ │ └── wrapper/ │ └── gradle-wrapper.properties ├── build.gradle(.kts) ├── settings.gradle(.kts) └── app/ # Module │ ├── build.gradle(.kts) │ ├── build/ │ ├── libs/ │ └── src/ │ └── main/ # Source set │ ├── java/ │ │ └── com.example.myapp │ ├── res/ │ │ ├── drawable/ │ │ ├── values/ │ │ └── ... │ └── AndroidManifest.xml
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 e os elementos DSL básicos que eles definem.
Arquivo Wrapper do Gradle
O wrapper do Gradle (gradlew
) é um pequeno aplicativo incluído no
código-fonte que faz o download e inicia o Gradle.
Isso cria uma execução de build mais consistente. Os desenvolvedores fazem o download da
origem 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
o arquivo settings.gradle
(para a DSL do Groovy) fica localizado no diretório
raiz do projeto. Esse arquivo define as configurações do repositório no nível do projeto
e informa ao Gradle quais módulos ele precisa incluir ao criar o
app. Projetos de vários módulos precisam especificar cada módulo que será incluído 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. 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")
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'
Arquivo de build de nível superior
O arquivo build.gradle.kts
(para a DSL do Kotlin) ou
o arquivo build.gradle
(para a DSL do Groovy) de nível superior fica localizado no diretório
raiz do projeto. Normalmente, ela define as versões comuns de plug-ins usados
pelos módulos no seu projeto.
O exemplo de código a seguir descreve as configurações padrão e os elementos 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.5.0" apply false id("com.android.library") version "8.5.0" apply false id("org.jetbrains.kotlin.android") version "1.9.23" 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.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
Arquivo de build de módulo
O arquivo build.gradle.kts
(para a DSL do Kotlin) ou
build.gradle
(para a DSL do Groovy) está localizado em cada
diretório project/module/
. Esse arquivo 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 script de build de nível superior.
Configurações do SDK do Android
O arquivo de build de módulo do app inclui configurações que indicam as versões do SDK do Android usadas na compilação, seleção de comportamentos da plataforma e especificação da versão mínima em que o aplicativo pode ser executado.
-
compileSdk
-
O
compileSdk
determina quais APIs do Android e Java estão disponíveis ao compilar seu código-fonte. Para usar os recursos mais recentes do Android, use o SDK mais recente do Android ao compilar.Algumas APIs da Plataforma Android podem não estar disponíveis em níveis de API mais antigos. Você pode proteger condicionalmente o uso de recursos mais recentes ou usar bibliotecas de compatibilidade do AndroidX para usar recursos mais recentes com níveis mais baixos da API do Android.
Cada SDK do Android fornece um subconjunto de APIs Java para uso no seu aplicativo. A tabela em Quais APIs Java posso usar no meu código-fonte Java ou Kotlin mostra qual nível da API Java está disponível com base na versão do SDK do Android. As APIs Java mais recentes têm suporte em versões anteriores do Android pela simplificação, que precisa ser ativada no build.
O Android Studio exibirá avisos se o
compileSdk
entrar em conflito com a versão atual do Android Studio, o AGP ou os requisitos de dependência da biblioteca do projeto. -
minSdk
-
O
minSdk
especifica a versão mais antiga do Android a que você quer que seu app ofereça suporte. A definição deminSdk
restringe quais dispositivos podem instalar o app.O suporte a versões anteriores do Android pode exigir mais verificações condicionais no código ou mais uso das bibliotecas de compatibilidade do AndroidX. Compare o custo de manutenção do suporte a versões anteriores em relação à porcentagem de usuários que ainda usam essas versões. Consulte o gráfico de versões no Assistente de novo projeto do Android Studio para conferir as porcentagens atuais de uso da versão.
Ao editar o código no Android Studio ou executar verificações durante o build, o lint vai avisar sobre APIs usadas que não estão disponíveis no
minSdk
. Para corrigir esses problemas, torne os recursos mais recentes condicionais ou useAppcompat
para compatibilidade com versões anteriores. -
targetSdk
-
O
targetSdk
tem dois propósitos:- Define o comportamento do tempo de execução do aplicativo.
- Ela atesta com qual versão do Android você foi testado.
Se você executar em um dispositivo que usa uma versão mais recente do Android que a
targetSdk
, o Android executará o app em um modo de compatibilidade que se comporta de maneira semelhante à versão anterior indicada natargetSdk
. Por exemplo, quando a API 23 introduziu o modelo de permissões de execução, nem todos os apps estavam prontos para adotá-lo imediatamente. Ao definirtargetSdk
como 22, esses apps poderão ser executados em dispositivos com a API 23 sem usar permissões de execução e poderão usar recursos incluídos na versão mais recente docompileSdk
. A política de distribuição do Google Play aplica outras políticas ao nível desejado da API.O valor de
targetSdk
precisa ser menor ou igual ao decompileSdk
.
Observação:os valores de compileSdk
e targetSdk
não precisam ser os mesmos. Lembre-se dos seguintes princípios básicos:
compileSdk
dá acesso a novas APIs.targetSdk
define o comportamento do tempo de execução do app.targetSdk
precisa ser menor ou igual acompileSdk
Exemplo de script de build do módulo de app
Este script de build de exemplo de módulo de app Android descreve alguns elementos DSL básicos e configurações:
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * 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" /** * compileSdk 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 = 33 /** * 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 = 21 // Specifies the API level used to test the app. targetSdk = 33 // 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 lets you 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" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * 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("androidx.appcompat:appcompat:1.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
Groovy
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * 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' /** * compileSdk 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 33 /** * 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 21 // Specifies the API level used to test the app. targetSdk 33 // 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 lets you 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' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * 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 'androidx.appcompat:appcompat:1.7.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
Arquivos de propriedades do Gradle
O Gradle também contém dois arquivos de propriedades, localizados no diretório raiz do projeto, que podem ser usados 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 (link em inglês).
-
local.properties
-
Configura as propriedades de ambiente local do sistema de build, incluindo:
ndk.dir
: caminho para o NDK. Essa propriedade foi descontinuada. Todas as versões do NDK transferidas por download são instaladas no diretóriondk
do SDK do Android.sdk.dir
: caminho para o SDK do Android.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)
No Windows, as ferramentas na pasta do NDK instalada, como ld.exe
, acabam com
caminhos longos. As ferramentas não são bem compatíveis com caminhos longos.
Para criar um caminho mais curto, em local.properties
, configure a propriedade
ndk.symlinkdir
e solicite que o Plug-in do Android para 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:\
resulta no seguinte link simbólico:
C:\ndk\19.0.5232133
Sincronizar o projeto com arquivos do Gradle
Quando você faz mudanças nos arquivos de configuração do build no seu projeto, o Android Studio exige a sincronização dos arquivos para que ele possa importar as mudanças e executar algumas verificações, garantindo que a configuração não crie erros de build.
Para sincronizar os arquivos do projeto, clique em Sync Now na
barra de notificações exibida ao fazer mudanças, como mostrado na
Figura 1, ou clique em Sync Project
na barra de menus. Se o Android Studio encontrar erros na sua
configuração, por exemplo, se o código-fonte usar recursos de API que só estão
disponíveis em um nível de API mais recente que seu
compileSdkVersion
,
a janela Messages vai descrever o problema.
![](https://developer.android.google.cn/static/images/tools/as-gradlesync.png?authuser=5&hl=pt)
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. Quando você cria um novo módulo, o Android Studio
cria um conjunto de origem main/
nele. O conjunto de origem
main/
de um módulo inclui os códigos e os 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 exclusivos de um tipo de build específico.
-
src/productFlavor/
-
Crie esse conjunto de origem para incluir os códigos e recursos exclusivos de uma variação
de produto específica.
Observação:se você configurar seu build para combinar diversas variações de produtos, 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 exclusivos de uma variante de build específica.
Por exemplo, para gerar a versão "fullDebug" do app, o sistema de build mescla códigos, configurações e recursos dos seguintes conjuntos de origem:
-
src/fullDebug/
(o conjunto de origem da variante de compilação) -
src/debug/
(o conjunto de origem do tipo de compilação) -
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, use as opções de menu File > New para fazer a criação dele 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.
Se conjuntos de origem diferentes contiverem versões distintas do mesmo arquivo, o Gradle vai usar a seguinte ordem de prioridade para decidir qual arquivo usar. Os conjuntos de origem à esquerda substituem 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 aplicativo e recursos comuns a outras versões do 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 como criar conjuntos de origem personalizados, consulte Criar conjuntos de origem.
Catálogos de versões
Se o build contém vários módulos com dependências comuns ou você tem vários projetos independentes com dependências comuns, recomendamos usar um catálogo de versões ou lista de materiais (BoM) para especificar as versões comuns.
Outros sistemas de build
A criação de apps Android com o Bazel é possível, mas não é oficialmente compatível. O Android Studio não tem suporte oficial para projetos do Bazel.
Se quiser entender melhor as limitações atuais para a criação de apps com o Bazel, consulte os problemas conhecidos (link em inglês).