Il sistema di compilazione di Android compila le risorse dell'app, il codice sorgente e i pacchetti in APK o Android App Bundle che puoi testare, implementare, firmare distribuire.
Android Studio utilizza Gradle, un toolkit di creazione avanzato, per automatizzare e gestire il processo di creazione, permettendoti di definire configurazioni di build. Ogni configurazione di compilazione può definire il proprio set di codice e risorse, riutilizzando le parti comuni a tutte le versioni dell'app. Il plug-in Android per Gradle funziona con il toolkit di creazione per fornire processi e impostazioni configurabili specifiche per la creazione e il test App per Android.
Gradle e il plug-in Android Gradle vengono eseguiti indipendentemente da Android Studio. Questo puoi creare le tue app Android da Android Studio, dalla riga di comando della tua macchina o su quelli in cui Android Studio come i server di integrazione continua.
Se non utilizzi Android Studio, puoi scoprire come creare ed eseguire un'app la riga di comando. L'output della build è lo stesso indipendentemente dal fatto che creando un progetto dalla riga di comando, su una macchina remota Android Studio.
Nota:poiché Gradle e il plug-in Android Gradle vengono eseguiti indipendentemente 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 Gradle.
La flessibilità del sistema di build Android consente di creare creare configurazioni senza modificare i file di origine principali dell'app. Questo pagina ti aiuta a capire come funziona il sistema di compilazione di Android e come può aiutarti a personalizzare e automatizzare più configurazioni di build. Se Per saperne di più sul deployment della tua app, consulta l'articolo Creare ed eseguire un'app. Per iniziare a creare modelli creare subito le configurazioni usando Android Studio, vedi Configurare la build delle varianti.
Il processo di compilazione
Il processo di compilazione coinvolge molti strumenti e processi che convertono il tuo progetto in un Android Application Package (APK) o Android App Bundle (AAB).
Il plug-in Android per Gradle svolge gran parte del processo di compilazione per te, ma può essere utile per comprendere alcuni aspetti del processo di compilazione in modo da poter per soddisfare i tuoi requisiti.
Progetti diversi possono avere obiettivi di build diversi. Ad esempio, la creazione di un una libreria di terze parti produce Android Archive (AAR) o Java Archive (JAR) librerie. Tuttavia, un'app è il tipo più comune di progetto e la creazione di un'app produce un APK o AAB di debug o di rilascio della tua app che puoi implementare, oppure rilasciarle agli utenti esterni.
Questa pagina è incentrata sullo sviluppo di app, ma molti dei passaggi e dei concetti di build sono comuni alla maggior parte dei tipi di build.
Glossario di Android Build
Gradle e il plug-in Android Gradle ti consentono di configurare i seguenti aspetti della tua build:
- Tipi di build
-
I tipi di build definiscono determinate proprietà utilizzate da Gradle durante la creazione e pacchettizzando l'app. I tipi di build sono in genere configurati fasi del ciclo di vita dello sviluppo.
Ad esempio, il tipo di build di debug attiva le 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 release chiave per la distribuzione.
Devi definire almeno un tipo di build per creare la tua app. Android Studio crea i tipi di build di debug e release per impostazione predefinita. Per iniziare a personalizzare le impostazioni dei pacchetti per la tua app, scopri come per configurare build di classificazione.
- Sapori del prodotto
- I sapori dei prodotti rappresentano versioni diverse della tua app che puoi per gli utenti, ad esempio le versioni senza costi e a pagamento. Puoi personalizzare versioni dei prodotti per utilizzare codice e risorse differenti durante la condivisione e riutilizzare le parti comuni a tutte le versioni dell'app. Prodotto I gusti sono facoltativi e devi crearli manualmente. Per iniziare a creare diverse versioni dell'app, scopri come configurare sapori dei prodotti.
- Varianti della build
- Una variante di build è un prodotto incrociato tra tipo di build e versione di prodotto. è la configurazione utilizzata da Gradle per creare la tua app. Utilizzando le varianti di build, puoi creare la versione di debug delle versioni di prodotto durante lo sviluppo e versioni con release firmate delle versioni dei tuoi prodotti da distribuire. Anche se non configuri direttamente le varianti di build, devi configurare i tipi di creazione e le varianti di prodotto che li compongono. Creazione build aggiuntiva in corso... di tipo o sapore dei prodotti creano anche altre varianti della build. Per ulteriori informazioni su come creare e gestire le varianti di build, leggi l'articolo Configurare le varianti di build. panoramica.
- Voci del file manifest
- Puoi specificare i valori per alcune proprietà del file manifest nella build configurazione delle varianti. Questi valori di build sostituiscono i valori esistenti in del file manifest. Ciò è utile se vuoi generare più varianti della tua app con un altro nome, una versione minima dell'SDK o un altro nome versione SDK target. Se sono presenti più manifest, strumento di unione unisce le impostazioni del file manifest.
- Dipendenze
- Il sistema di compilazione gestisce le dipendenze del progetto dal file system locale e da repository remoti. Ciò significa che non devi manualmente cercare, scaricare e copiare pacchetti binari delle tue dipendenze della directory di un progetto. Per ulteriori informazioni, consulta la sezione Aggiungere build delle dipendenze.
- Firma
- Il sistema di compilazione consente di specificare le impostazioni di firma nella build e può firmare automaticamente l'app durante la creazione e il processo di sviluppo. Il sistema di compilazione firma la versione di debug con una chiave predefinita e utilizzando credenziali note per evitare la richiesta di password in fase di build nel tempo. Il sistema di compilazione non firma la versione della release a meno che tu definire in modo esplicito una configurazione di firma per questa build. In caso contrario avere una chiave di rilascio, puoi generarne una come descritto nella sezione Firmare l'app. Build di release firmate sono necessarie per la distribuzione di app tramite la maggior parte degli store.
- Riduzione del codice e delle risorse
- Il sistema di compilazione consente di specificare un file di regole ProGuard diverso per ciascuna variante della build. Quando crea la tua app, il sistema di compilazione applica l'insieme di regole appropriato per ridurre il codice e le risorse usando gli strumenti integrati di riduzione come 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 compilazione ti consente di creare automaticamente diversi APK che ciascuna contiene solo il codice e le risorse necessarie per una specifica densità di schermo o ABI (Application Binary Interface). Per ulteriori informazioni, vedi Crea più APK. Tuttavia, il rilascio di un singolo AAB l'approccio consigliato, in quanto offre la suddivisione per lingua, oltre a densità dello schermo e ABI, evitando la necessità di caricare più elementi in Google Play. Tutte le nuove app inviate dopo agosto 2021 per l'uso degli AAB.
Versioni Java nelle build di Android
Che il codice sorgente sia scritto in Java, Kotlin o entrambi, è necessario scegliere un linguaggio JDK o Java, per la tua build. Vedi Versioni Java nelle build di Android per maggiori dettagli.
Creare file di configurazione
Per creare configurazioni di build personalizzate devi apportare modifiche a uno o più file di configurazione di compilazione. Questi utilizzano un linguaggio specifico del dominio (DSL, Domain Specific Language) per descrivere e e manipolare la logica di build Script Kotlin, che è un sapore della lingua kotlin. Puoi anche utilizzare Groovy, che è un per la Java Virtual Machine (JVM), per configurare le tue build.
Non è necessario conoscere lo script Kotlin o Groovy per iniziare perché il plug-in Android per Gradle introduce la maggior parte degli elementi DSL di cui hai bisogno. Per ulteriori informazioni sul plug-in Android Gradle DSL, leggi l'articolo documentazione di riferimento DSL. Lo script Kotlin si basa anche sul sottostante Gradle Kotlin DSL.
Quando avvii un nuovo progetto, Android Studio crea automaticamente alcuni questi file per te e li compila in base a valori predefiniti appropriati. Il 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 struttura di progetto standard per un'app per Android. Prima di iniziare configurazione della build, è importante comprenderne l'ambito e lo scopo di ciascuno di questi file e degli elementi DSL di base che definiscono.
Il file Gradle Wrapper
Il wrapper Gradle (gradlew) è una piccola applicazione inclusa nel tuo
codice sorgente che scarica e avvia Gradle stesso.
Ciò consente un'esecuzione della build più coerente. Gli sviluppatori scaricano
ed eseguire gradlew. Questa operazione scarica il Gradle richiesto
e avvia Gradle per creare la tua applicazione.
Il file gradle/wrapper/gradle-wrapper.properties
contiene una proprietà, distributionUrl, che descrive la versione
Gradle viene utilizzato 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) oppure
settings.gradle (per Groovy DSL) si trova nella directory principale
della directory di un progetto. Questo file di impostazioni definisce il repository a livello di progetto
impostazioni e indica a Gradle quali moduli deve includere durante la creazione
dell'app. I progetti multimodulo devono specificare ogni modulo che deve essere
la 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")
Alla moda
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) oppure
build.gradle (per Groovy DSL) si trova nella directory principale
della directory di un progetto. In genere definisce le versioni comuni dei plug-in utilizzati
per moduli nel tuo progetto.
Il seguente esempio di codice descrive le impostazioni predefinite e gli elementi DSL in lo script di build di primo livello dopo aver creato 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.6.0" apply false
id("com.android.library") version "8.6.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}
Alla moda
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.6.0' apply false
id 'com.android.library' version '8.6.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}
Il file di build a livello di modulo
build.gradle.kts a livello di modulo (per Kotlin DSL) oppure
build.gradle (per Groovy DSL) si trova in ogni
Directory project/module/. Ti permette di
configurare le impostazioni di compilazione per il modulo specifico in cui si trova. Configurazione in corso...
queste impostazioni di compilazione consentono
di fornire opzioni di pacchetti personalizzate,
ulteriori tipi di build e versioni di prodotti e sostituisce le impostazioni nel
File manifest dell'app o script di build di primo livello di main/.
Impostazioni SDK Android
Il file di build a livello di modulo per l'applicazione include impostazioni che indicano Le versioni dell'SDK Android utilizzate durante la compilazione, la selezione dei comportamenti della piattaforma e specificando la versione minima su cui viene eseguita l'applicazione.
-
compileSdk -
L'
compileSdkdetermina quali API Android e Java vengono disponibili durante la compilazione del codice sorgente. Per utilizzare la versione più recente 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 salvaguardare in modo condizionale l'uso delle funzionalità più recenti o l'uso . Librerie di compatibilità con AndroidX per usare le funzionalità più recenti con un Livelli API Android.
Ogni SDK per 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 il livello API Java disponibile in base alla versione dell'SDK Android. Le API Java più recenti sono supportate sulle versioni precedenti di Android tramite desugaring, che deve essere abilitato nella tua build.
Android Studio mostra avvisi in caso di conflitto tra
compileSdkcon la versione corrente di Android Studio, AGP o con la libreria del tuo progetto requisiti delle dipendenze. -
minSdk -
Il
minSdkspecifica la versione più bassa di Android che che la tua app sia supportata. L'impostazione diminSdklimita quali possono installare la tua app.Il supporto di versioni precedenti di Android potrebbe richiedere controlli più condizionali nel tuo codice o nell'utilizzo di più librerie di compatibilità AndroidX. Dovresti pesare il costo di manutenzione del supporto delle versioni inferiori percentuale di utenti che utilizzano ancora quelle versioni precedenti. Consulta le grafico delle versioni nella procedura guidata del nuovo progetto di Android Studio per le percentuali di utilizzo della versione corrente.
Quando modifichi il codice in Android Studio o esegui i controlli durante la tua build, lint ti avvisa in caso di API che utilizzi e che non sono in
minSdk. Dovresti risolvere il problema entro il giorno rendendo condizionali le nuove funzionalità oppure utilizzando .Appcompatper la compatibilità con le versioni precedenti. -
targetSdk -
targetSdkha due scopi:- Imposta il comportamento di runtime dell'applicazione.
- Attesta la versione di Android rispetto alla quale hai eseguito il test.
Se esegui su un dispositivo che utilizza una versione superiore di Android il tuo
targetSdk, Android esegue la tua app in modalità di compatibilità che si comporta in modo simile alla versione precedente indicata neltargetSdk. Ad esempio, quando l'API 23 ha introdotto il runtime di autorizzazioni, non tutte le app erano pronte ad adottarlo immediatamente. Se impostitargetSdksu 22, queste app potrebbero essere eseguite su Dispositivi con l'API 23 senza autorizzazioni di runtime e potrebbero utilizzare funzionalità incluse nell'ultima versione dicompileSdk. Google Play il criterio di distribuzione applica criteri aggiuntivi sul livello API target.Il valore di
targetSdkdeve essere minore o uguale a a quella dicompileSdk.
Nota: i valori di compileSdk e targetSdk
non devono essere necessariamente uguali. Tieni presenti i seguenti principi di base:
compileSdkti dà accesso a nuove APItargetSdkimposta il comportamento di runtime della tua apptargetSdkdeve essere inferiore o uguale acompileSdk
Script di build del modulo dell'app di esempio
Questo esempio di script di compilazione del modulo dell'app per Android illustra alcuni degli elementi e delle 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.7.0")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Alla moda
/**
* 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'])
}
File delle proprietà Gradle
Gradle include anche due file delle proprietà, che si trovano nel progetto principale , che puoi usare per specificare le impostazioni del toolkit di build di Gradle stesso:
-
gradle.properties - Qui puoi configurare le impostazioni Gradle a livello di progetto, come Dimensione massima dell'heap del daemon Gradle. Per saperne di più, consulta Ambiente di creazione.
-
local.properties -
Configura le proprietà dell'ambiente locale per il sistema di compilazione, tra cui il
seguenti:
ndk.dir: percorso verso l'NDK. Questa proprietà è stata ritirato. Tutte le versioni scaricate dell'NDK vengono installate nell'ndkall'interno della directory dell'SDK Android.sdk.dir: percorso dell'SDK per Android.cmake.dir- Percorso verso CMake.ndk.symlinkdir- In Android Studio 3.5 e versioni successive, crea un collegamento simbolico all'NDK che può essere più breve del Percorso NDK.
.
Rimappa l'NDK a un percorso più breve (solo Windows)
In Windows, gli strumenti nella cartella NDK installata, ad esempio ld.exe, vengono visualizzati
percorsi lunghi. Gli strumenti non supportano bene i percorsi lunghi.
Per creare un percorso più breve, imposta la proprietà in local.properties
ndk.symlinkdir per richiedere che il plug-in Android Gradle crei un collegamento simbolico a
l'NDK. Il percorso di quel link simbolico può essere più breve della cartella NDK esistente.
Ad esempio, ndk.symlinkdir = C:\ genera il seguente link simbolico:
C:\ndk\19.0.5232133
Sincronizza il progetto con i file Gradle
Quando apporti modifiche ai file di configurazione di compilazione del progetto, Android Studio richiede la sincronizzazione dei file di progetto, importare le modifiche alla configurazione della build ed eseguire alcuni controlli per assicurarti configurazione non crea errori di build.
Per sincronizzare i file di progetto, fai clic su Sync Now (Sincronizza ora) nel
barra delle notifiche che appare quando apporti una modifica, come mostrato
figura 1 o fai clic su Sincronizza progetto 
dalla barra dei menu. Se Android Studio rileva errori nei tuoi
configurazione: ad esempio, il codice sorgente utilizza funzionalità API che
disponibile in un livello API superiore a compileSdkVersion
nella finestra Messaggi viene descritto il problema.
Set di origini
Android Studio raggruppa logicamente codice sorgente e risorse per ogni modulo
in set di origini. Quando crei un nuovo modulo, Android Studio
crea un set di origini main/ all'interno del modulo. Il percorso di un modulo
Il set di codice sorgente main/ include il codice e le risorse utilizzati da tutti i relativi
creare varianti.
Le directory aggiuntive del set di origini sono facoltative e Android
Studio non li crea automaticamente quando configuri una nuova build
varianti di prodotto. Tuttavia, la creazione di set di origini, come in main/, aiuta
organizzare i file e le risorse che Gradle dovrebbe usare solo quando
versioni della tua app:
-
src/main/ - Questo set di origine include codice e risorse comuni a tutte le varianti della build.
-
src/buildType/ - Crea questo set di origini in modo da includere codice e risorse solo per uno specifico un tipo di build.
-
src/productFlavor/ -
Crea questo set di origini in modo da includere codice e risorse solo per uno specifico
sapore del prodotto.
Nota: se configuri la build in modo da combinare più persone versioni di prodotto, puoi creare directory di set di origini per combinazione di sapori di prodotto tra le varie dimensioni:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Crea questo set di origini in modo da includere codice e risorse solo per uno specifico la variante build.
Ad esempio, per generare il comando "fullDebug" all'ultima versione della tua app, il sistema di compilazione unisce codice, impostazioni e risorse dai seguenti set di origini:
-
src/fullDebug/(il set di origini delle varianti della build) -
src/debug/(il set di origini del tipo di build) -
src/full/(l'insieme di origini flavor del prodotto) -
src/main/(insieme di origini principali)
Nota:quando crei un nuovo file o una nuova directory in Android Studio, usa File > Nuove opzioni di menu da creare per uno specifico set di origini. Gli insiemi di origini tra cui puoi scegliere si basano sulle configurazioni della build e Android Studio crea automaticamente le directory richieste, se non esistono già.
Se set di origini diversi contengono versioni diverse dello stesso file, Gradle utilizza il seguente ordine di priorità per decidere quale file utilizzare. Origine gli insiemi a sinistra eseguono l'override dei file e delle impostazioni degli insiemi di origine al A destra:
variante di build > tipo di build > versione del prodotto > set di sorgenti principali > delle dipendenze di libreria.
Ciò consente a Gradle di usare file specifici per la variante della build stanno provando a creare riutilizzando attività, logica dell'applicazione e le risorse comuni ad altre versioni dell'app.
Quando unisci più manifest, Gradle utilizza lo stesso ordine di priorità, quindi ogni variante di build può e definire vari componenti o autorizzazioni nel manifest finale. Per ulteriori informazioni Per saperne di più sulla creazione di insiemi di origini personalizzati, consulta Creare set di origini.
Cataloghi delle versioni
Se la build contiene più moduli con dipendenze comuni, avere più progetti indipendenti con dipendenze comuni, utilizzi un catalogo delle versioni o distinta base (BOM) a e specificare le versioni comuni.
Altri sistemi di compilazione
La creazione di app per Android con Bazel possibili, ma non ufficialmente supportati. Android Studio non per supportare i progetti Bazel.
Per comprendere meglio gli attuali limiti della creazione con Bazel, consulta il problemi noti.