Il sistema di build Android compila le risorse dell'app e il codice sorgente e li pacchettizza in APK o Android App Bundle che puoi testare, eseguire il deployment, firmare e distribuire.
Android Studio utilizza Gradle, un toolkit avanzato per lo sviluppo, per automatizzare e gestire il processo di compilazione e consentirti di definire configurazioni di build flessibili e personalizzate. Ogni configurazione di build può definire un proprio set di codice e risorse riutilizzando le parti comuni a tutte le versioni dell'app. Il plug-in Android Gradle funziona con il toolkit di build per fornire processi e impostazioni configurabili specifici per la creazione e il test di app Android.
Gradle e il plug-in Android per Gradle vengono eseguiti indipendentemente da Android Studio. Ciò significa che puoi creare app per Android da Android Studio, dalla riga di comando del tuo computer o sulle macchine su cui Android Studio non è installato, ad esempio i server di integrazione continua.
Se non utilizzi Android Studio, puoi scoprire come creare ed eseguire la tua app dalla riga di comando. L'output della build è lo stesso sia che tu stia creando un progetto dalla riga di comando, su una macchina remota o utilizzando Android Studio.
Nota:poiché Gradle e il plug-in Android per Gradle vengono eseguiti in modo indipendente da Android Studio, devi aggiornare gli strumenti di creazione separatamente. Leggi le note di rilascio per scoprire come aggiornare Gradle e il plug-in Android per Gradle.
La flessibilità del sistema di compilazione Android consente di creare configurazioni di build personalizzate senza modificare i file di origine principali dell'app. Questa pagina ti aiuta a capire come funziona il sistema di build Android e come può aiutarti a personalizzare e automatizzare più configurazioni di build. Per saperne di più sul deployment della tua app, consulta Creare ed eseguire un'app. Per iniziare subito a creare configurazioni di build personalizzate utilizzando Android Studio, consulta Configurare le varianti di build.
Il processo di compilazione
Il processo di compilazione prevede molti strumenti e processi che convertono il progetto in un Android Application Package (APK) o Android App Bundle (AAB).
Il plug-in Android per Gradle si occupa di gran parte del processo di compilazione, ma può essere utile per comprendere determinati aspetti del processo di compilazione in modo da poter regolare la build in base ai tuoi requisiti.
Progetti diversi possono avere obiettivi di build diversi. Ad esempio, la build di una libreria di terze parti produce librerie Android Archive (AAR) o Java Archive (JAR). Tuttavia, un'app è il tipo di progetto più comune e la build di un progetto genera un APK o AAB di debug o di release dell'app che puoi eseguire il deployment, il test o il rilascio per gli utenti esterni.
Questa pagina è dedicata allo sviluppo di app, ma molti passaggi e concetti sono comuni alla maggior parte dei tipi di build.
Glossario di build Android
Gradle e il plug-in Android per Gradle ti aiutano a configurare i seguenti aspetti della build:
- Tipi di build
-
I tipi di build definiscono determinate proprietà che Gradle utilizza durante la creazione e la pacchettizzazione della tua app. In genere, i tipi di build sono configurati per diverse fasi del ciclo di vita di sviluppo.
Ad esempio, il tipo di build di debug attiva opzioni di debug e firma l'app con la chiave di debug, mentre il tipo di build di release potrebbe ridurre, offuscare e firmare la tua app con una chiave di rilascio per la distribuzione.
Devi definire almeno un tipo di build per creare l'app. Android Studio crea i tipi di build di debug e release per impostazione predefinita. Per iniziare a personalizzare le impostazioni di pacchetto per la tua app, scopri come configurare i tipi di build.
- Sapori di prodotto
- Le versioni di prodotto rappresentano diverse versioni dell'app che puoi rilasciare per gli utenti, ad esempio versioni senza costi e a pagamento. Puoi personalizzare le versioni dei prodotti in modo da utilizzare risorse e codice diversi, condividendo e riutilizzando le parti comuni a tutte le versioni dell'app. Le versioni dei prodotti sono facoltative e devi crearle manualmente. Per iniziare a creare versioni diverse dell'app, scopri come configurare le versioni dei prodotti.
- Creare varianti
- Una variante build è composta da più prodotti tra tipo di build e versione di prodotto ed è la configurazione utilizzata da Gradle per creare la tua app. Utilizzando le varianti build, puoi creare la versione di debug delle versioni di prodotto durante lo sviluppo e le versioni di release firmate delle versioni di prodotto per la distribuzione. Anche se non configuri direttamente le varianti di build, devi configurare i tipi di build e le versioni di prodotto che le formano. La creazione di tipi di build o versioni di prodotto aggiuntive crea anche varianti di build aggiuntive. Per scoprire come creare e gestire le varianti di build, consulta la panoramica su come configurare le varianti di build.
- Voci del file manifest
- Puoi specificare i valori per alcune proprietà del file manifest nella configurazione della variante build. Questi valori di build sostituiscono i valori esistenti nel file manifest. Questo è utile se vuoi generare più varianti della tua app con un nome dell'applicazione, una versione minima dell'SDK o una versione dell'SDK target diversi. Quando sono presenti più manifest, lo strumento di unione dei manifest unisce le impostazioni del manifest.
- Dipendenze
- Il sistema di build gestisce le dipendenze dei progetti dal file system locale e da repository remoti. Ciò significa che non devi cercare, scaricare e copiare manualmente i pacchetti binari delle tue dipendenze nella directory del progetto. Per saperne di più, consulta Aggiungere dipendenze di build.
- Firma
- Il sistema di build ti consente di specificare le impostazioni di firma nella configurazione della build e può firmare automaticamente la tua app durante il processo di compilazione. Il sistema di build firma la versione di debug con una chiave e un certificato predefiniti utilizzando credenziali note per evitare la richiesta di una password al momento della build. Il sistema di compilazione non firma la versione della release a meno che tu non definisca esplicitamente una configurazione di firma per questa build. Se non hai una chiave di release, puoi generarne una come descritto nella sezione Firmare l'app. Le build di release firmate sono necessarie per la distribuzione di app tramite la maggior parte degli store.
- Riduzione di codice e risorse
- Il sistema di compilazione ti consente di specificare un file di regole ProGuard diverso per ogni variante di build. Durante la creazione dell'app, il sistema di build applica l'insieme appropriato di regole per ridurre il codice e le risorse utilizzando gli strumenti integrati, ad esempio R8. La riduzione del codice e delle risorse può contribuire a ridurre le dimensioni dell'APK o dell'AAB.
- Supporto di più APK
- Il sistema di build ti consente di creare automaticamente diversi APK, ciascuno contenente solo il codice e le risorse necessari per una specifica densità dello schermo o un'ABI (Application Binary Interface) specifica. Per maggiori informazioni, consulta la pagina Creare più APK. Tuttavia, l'approccio consigliato è il rilascio di un singolo AAB, poiché offre la suddivisione per lingua, oltre alla densità dello schermo e all'ABI, senza dover caricare più elementi su Google Play. Tutte le nuove app inviate dopo agosto 2021 devono utilizzare gli AAB.
Versioni Java nelle build Android
Sia che il codice sorgente sia scritto in Java, Kotlin o entrambi, esistono diverse posizioni in cui devi scegliere una versione del linguaggio JDK o Java per la tua build. Per i dettagli, consulta Versioni Java nelle build Android.
File di configurazione di compilazione
Per creare configurazioni di build personalizzate, devi apportare modifiche a uno o più file di configurazione di compilazione. Questi file di testo normale utilizzano Domain Specific Language (DSL) per descrivere e manipolare la logica di build utilizzando lo script Kotlin, che è un sapore del linguaggio Kotlin. Puoi anche utilizzare Groovy, un linguaggio dinamico per la Java Virtual Machine (JVM), per configurare le tue build.
Non è necessario conoscere lo script Kotlin o Groovy per iniziare a configurare la build, perché il plug-in Android per Gradle introduce la maggior parte degli elementi DSL necessari. Per scoprire di più sul plug-in DSL per Android per Gradle, leggi la documentazione di riferimento DSL. Lo script Kotlin si basa anche sul sottostante Gradle Kotlin DSL.
Quando inizi un nuovo progetto, Android Studio crea automaticamente alcuni di questi file e li completa in base a valori predefiniti validi. La struttura del file di progetto ha il seguente 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
Esistono alcuni file di configurazione di compilazione Gradle che fanno parte della struttura standard del progetto per un'app per Android. Prima di iniziare a configurare la build, è importante comprendere l'ambito e lo scopo di ognuno di questi file e gli elementi DSL di base che definiscono.
Il file Gradle Wrapper
Il wrapper Gradle (gradlew) è una piccola applicazione inclusa nel codice sorgente che scarica e avvia Gradle stesso.
Questo crea un'esecuzione della build più coerente. Gli sviluppatori scaricano l'origine dell'applicazione ed eseguono gradlew. Questa operazione scarica la distribuzione Gradle richiesta e avvia Gradle per creare la tua applicazione.
Il file gradle/wrapper/gradle-wrapper.properties
contiene una proprietà, distributionUrl, che descrive quale versione di
gradle viene utilizzata per eseguire la 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
Il file delle impostazioni di Gradle
Il file settings.gradle.kts (per Kotlin DSL) o
il file settings.gradle (per Groovy DSL) si trova nella directory
principale del progetto. Questo file di impostazioni definisce le impostazioni del repository a livello di progetto e informa Gradle quali moduli deve includere durante la creazione dell'app. I progetti con più moduli devono specificare ogni modulo che deve essere inviato alla build finale.
Per la maggior parte dei progetti, il file ha il seguente aspetto per impostazione predefinita:
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")
trendy
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'
Il file di build di primo livello
Il file build.gradle.kts di primo livello (per Kotlin DSL) o
il file build.gradle (per Groovy DSL) si trova nella directory principale
del progetto. In genere definisce le versioni comuni dei plug-in utilizzati dai moduli del tuo progetto.
Il seguente esempio di codice descrive le impostazioni predefinite e gli elementi DSL nello script di build di primo livello dopo la creazione di un nuovo progetto:
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.1.0" apply false
id("com.android.library") version "8.1.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.20" apply false
}
trendy
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.1.0' apply false
id 'com.android.library' version '8.1.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.20' apply false
}
Il file di build a livello di modulo
Il file build.gradle.kts (per Kotlin DSL) o
build.gradle (per Groovy DSL) si trova in ogni
directory project/module/. Consente di configurare le impostazioni della build per il modulo specifico in cui si trova. La configurazione di queste impostazioni di build ti consente di fornire opzioni di pacchettizzazione personalizzate, come tipi di build e versioni di prodotto aggiuntivi, e di eseguire l'override delle impostazioni nel file manifest dell'app main/ o nello script di build di primo livello.
Impostazioni SDK Android
Il file di build a livello di modulo per la tua applicazione include impostazioni che indicano le versioni dell'SDK Android utilizzate per la compilazione, la selezione dei comportamenti della piattaforma e la specifica della versione minima su cui viene eseguita l'applicazione.
-
compileSdk -
compileSdkdetermina quali API Android e Java sono disponibili quando compili il codice sorgente. Per usare le funzionalità più recenti di Android, usa l'SDK Android più recente durante la compilazione.Alcune API della piattaforma Android potrebbero non essere disponibili nei livelli API precedenti. Puoi proteggere in modo condizionale l'utilizzo delle funzionalità più recenti o usare le librerie di compatibilità AndroidX per usare funzionalità più recenti con livelli API Android inferiori.
Ogni SDK Android fornisce un sottoinsieme di API Java da utilizzare nella tua applicazione. La tabella in Quali API Java posso utilizzare nel mio codice sorgente Java o Kotlin mostra quale livello di API Java è disponibile in base alla versione dell'SDK Android. Le API Java più recenti sono supportate nelle versioni precedenti di Android tramite il desugaring, che deve essere abilitato nella build.
Tieni presente che alcune librerie che includi come dipendenze potrebbero impostare un valore minimo per
compileSdk. Se ilcompileSdkè inferiore a questo valore, Gradle segnala un errore di build. -
minSdk -
L'elemento
minSdkspecifica la versione più bassa di Android che vuoi sia supportata dalla tua app. L'impostazione diminSdklimita i dispositivi che possono installare la tua app.Il supporto di versioni precedenti di Android potrebbe richiedere più controlli condizionali nel codice o un maggiore utilizzo delle librerie di compatibilità di AndroidX. Dovresti ponderare i costi di manutenzione relativi al supporto delle versioni precedenti rispetto alla percentuale di utenti che le utilizzano ancora. Controlla il grafico delle versioni nella procedura guidata Nuovo progetto di Android Studio per conoscere le percentuali di utilizzo della versione corrente.
Quando modifichi il codice in Android Studio o esegui controlli durante la build, lint ti avvisa della presenza di API non disponibili in
minSdk. Per risolvere il problema, rendi condizionali le funzionalità più recenti o utilizzaAppcompatper la compatibilità con le versioni precedenti. -
targetSdk -
targetSdkha due scopi:- Imposta il comportamento di runtime della tua applicazione.
- Attesta la versione di Android rispetto a cui hai eseguito il test.
Se utilizzi un dispositivo che utilizza una versione di Android superiore a quella del tuo
targetSdk, Android esegue l'app in una modalità di compatibilità che si comporta in modo simile alla versione precedente indicata intargetSdk. Ad esempio, quando l'API 23 ha introdotto il modello di autorizzazioni di runtime, non tutte le app erano pronte ad adottarlo immediatamente. ImpostandotargetSdksu 22, queste app potrebbero essere eseguite sui dispositivi API 23 senza utilizzare le autorizzazioni di runtime e potrebbero utilizzare le funzionalità incluse nell'ultima versione dicompileSdk. I criteri di distribuzione di Google Play applicano criteri aggiuntivi sul livello API target.Il valore di
targetSdkdeve essere inferiore o uguale a quello dicompileSdk.
Nota: i valori di compileSdk e targetSdk non devono necessariamente essere uguali. Tieni presente i seguenti principi di base:
compileSdkti consente di accedere a nuove APItargetSdkimposta il comportamento di runtime della tua apptargetSdkdeve essere minore o uguale acompileSdk
Script di build del modulo dell'app di esempio
Questo script di build di modulo per app Android di esempio descrive alcuni elementi e impostazioni DSL di base:
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.6.1")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
trendy
/**
* 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.6.1'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
File delle proprietà Gradle
Gradle include anche due file di proprietà, situati nella directory principale del progetto, che puoi utilizzare per specificare le impostazioni per il toolkit di build di Gradle stesso:
-
gradle.properties - Qui puoi configurare le impostazioni Gradle a livello di progetto, come la dimensione heap massima del daemon Gradle. Per ulteriori informazioni, consulta la sezione Ambiente di build.
-
local.properties -
Configura le proprietà dell'ambiente locale per il sistema di build, tra cui:
ndk.dir: percorso per l'NDK. Questa proprietà è stata deprecata. Qualsiasi versione scaricata dell'NDK viene installata nella directoryndkall'interno della directory dell'SDK Android.sdk.dir: percorso dell'SDK Android.cmake.dir- Percorso di CMake.ndk.symlinkdir: in Android Studio 3.5 e versioni successive, crea un link simbolico all'NDK che può essere più breve del percorso NDK installato.
Rimappa l'NDK su un percorso più breve (solo Windows)
In Windows, gli strumenti nella cartella NDK installata, come ld.exe, finiscono con percorsi lunghi. Gli strumenti non supportano bene i percorsi lunghi.
Per creare un percorso più breve, in local.properties imposta la proprietà ndk.symlinkdir per richiedere al plug-in Android per Gradle di creare un link simbolico all'NDK. Il percorso del link simbolico può essere più breve rispetto alla cartella NDK esistente.
Ad esempio, ndk.symlinkdir = C:\ restituisce il seguente link simbolico:
C:\ndk\19.0.5232133
Sincronizza il progetto con i file Gradle
Quando apporti modifiche ai file di configurazione della build nel progetto, Android Studio richiede di sincronizzare i file di progetto in modo che possa importare le modifiche alla configurazione di build ed eseguire alcuni controlli per assicurarti che la configurazione non crei errori di build.
Per sincronizzare i file di progetto, fai clic su Sincronizza ora nella barra delle notifiche visualizzata quando apporti una modifica, come mostrato nella figura 1, oppure fai clic su Sincronizza progetto 
dalla barra dei menu. Se Android Studio rileva errori di configurazione, ad esempio il codice sorgente utilizza funzionalità API disponibili solo in un livello API superiore a quello di compileSdkVersion, il problema viene descritto nella finestra Messaggi.
Set di origini
Android Studio raggruppa logicamente codice sorgente e risorse per ogni modulo in set di origine. Quando crei un nuovo modulo, Android Studio
crea un set di origine main/ all'interno del modulo. Il set di origine main/ di un modulo include il codice e le risorse utilizzati da tutte le sue varianti di build.
Le directory aggiuntive dei set di origini sono facoltative e Android Studio non le crea automaticamente quando configuri nuove varianti della build. Tuttavia, la creazione di set di origini, simili a main/, aiuta a organizzare file e risorse che Gradle dovrebbe utilizzare solo quando crea determinate versioni dell'app:
-
src/main/ - Questo set di origine include codice e risorse comuni a tutte le varianti della build.
-
src/buildType/ - Crea questo set di origine per includere codice e risorse solo per un tipo di build specifico.
-
src/productFlavor/ -
Crea questo set di origine per includere codice e risorse solo per una versione specifica del prodotto.
Nota: se configuri la build in modo da combinare più versioni di prodotto, puoi creare directory del set di codice sorgente per ogni combinazione di versioni di prodotto tra le dimensioni delle varianti:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Crea questo set di origine per includere codice e risorse solo per una variante di build specifica.
Ad esempio, per generare la versione "fullDebug" della tua app, il sistema di build unisce codice, impostazioni e risorse dei seguenti set di origini:
-
src/fullDebug/(il set di origine delle varianti della build) -
src/debug/(il set di origine del tipo di build) -
src/full/(l'insieme di origine dei gusti del prodotto) -
src/main/(l'insieme di origine principale)
Nota:quando crei un nuovo file o una nuova directory in Android Studio, utilizza le opzioni di menu File > Nuovo per creare il file per un set di origine specifico. I set di origine tra cui puoi scegliere si basano sulle configurazioni della build e, se non esistono già, Android Studio crea automaticamente le directory richieste.
Se set di origini diversi contengono versioni diverse dello stesso file, Gradle utilizza il seguente ordine di priorità quando decide quale file utilizzare. I set di origini a sinistra sostituiscono i file e le impostazioni dei set di origini a destra:
build variante > tipo di build > versione di prodotto > set di origine principale > dipendenze di libreria
In questo modo Gradle può utilizzare i file specifici per la variante di build che stai cercando di creare, riutilizzando le attività, la logica dell'applicazione e le risorse comuni ad altre versioni dell'app.
Quando unisci più manifest, Gradle utilizza lo stesso ordine di priorità, in modo che ogni variante di build possa definire componenti o autorizzazioni diversi nel manifest finale. Per scoprire di più sulla creazione di set di origini personalizzati, consulta Creare set di origini.
Cataloghi versioni
Se la build contiene più moduli con dipendenze comuni o hai più progetti indipendenti con dipendenze comuni, ti consigliamo di utilizzare un catalogo delle versioni o una distinta base (BOM) per specificare le versioni comuni.
Altri sistemi di build
La creazione di app Android con Bazel è possibile, ma non ufficialmente supportata. Android Studio non supporta ufficialmente i progetti Bazel.
Per comprendere meglio le attuali limitazioni della creazione con Bazel, consulta i problemi noti.