Configura la build
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il sistema di compilazione Android compila le risorse e il codice sorgente dell'app e li pacchettizza
in APK o Android App Bundle che puoi testare, implementare, firmare e
distribuire.
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à utilizzate da Gradle durante la creazione e
il packaging dell'app. I tipi di build vengono in genere configurati per le diverse
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 può ridurre, offuscare e firmare l'app con una chiave di release
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 di pacchettizzazione per la tua app, scopri come
configurare i tipi di
build.
Versioni prodotto
Le varianti del prodotto rappresentano diverse versioni della tua app che puoi
rilasciare agli utenti, ad esempio le versioni senza costi e a pagamento. Puoi
personalizzare le varianti di prodotto per utilizzare codice e risorse diversi durante la condivisione
e il riutilizzo delle parti comuni a tutte le versioni dell'app. Le varianti di prodotto
sono facoltative e devi crearle manualmente. Per iniziare a creare
diverse versioni della tua app, scopri come configurare
le varianti del prodotto.
Varianti di build
Una variante di build è un prodotto incrociato di tipo di build e versione prodotto ed è la configurazione che Gradle utilizza per creare la tua app. Utilizzando le varianti di build, puoi creare la versione di debug delle tue versioni prodotto durante lo sviluppo e le versioni di rilascio firmate delle tue versioni prodotto per la distribuzione.
Sebbene non configuri direttamente le varianti di build, configuri i
tipi di build e le varianti di prodotto che le compongono. La creazione di tipi di build
o varianti di prodotto aggiuntive crea anche varianti di build aggiuntive. Per scoprire
come creare e gestire le varianti di build, leggi la panoramica Configurare le varianti di build.
Voci del manifest
Puoi specificare i valori per alcune proprietà del file manifest nella configurazione
della variante di build. Questi valori di build sostituiscono i valori esistenti nel
file manifest. Questa opzione è utile se vuoi generare più varianti
della tua app con un nome dell'applicazione, una versione minima dell'SDK o
una versione dell'SDK di destinazione diversi. Quando sono presenti più manifest, lo strumento
di unione dei manifest
unisce le impostazioni dei manifest.
Dipendenze
Il sistema di compilazione gestisce le dipendenze del progetto dal file system locale
e dai repository remoti. Ciò significa che non devi cercare, scaricare e copiare manualmente i pacchetti binari delle 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 di build e può firmare automaticamente la tua app durante la procedura di build. Il sistema di compilazione firma la versione di debug con una chiave e
un certificato predefiniti utilizzando credenziali note per evitare la richiesta di password al momento della compilazione. Il sistema di build non firma la versione di rilascio 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 in Firma l'app. Le build di release firmate
sono necessarie per distribuire le app tramite la maggior parte degli store.
Riduzione del codice e delle risorse
Il sistema di compilazione ti consente di specificare un file di regole ProGuard diverso per
ogni variante di build. Quando crei l'app, il sistema di compilazione applica il
set di regole appropriato per ridurre
le dimensioni del codice e delle risorse utilizzando gli strumenti di riduzione integrati, 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 build ti consente di creare automaticamente APK diversi che
contengono solo il codice e le risorse necessari
per una densità dello schermo o un'interfaccia binaria dell'applicazione (ABI) specifica.
Per saperne di più, consulta
Creare 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ù artefatti su Google Play. Tutte le nuove app inviate dopo agosto 2021
devono utilizzare gli AAB.
Versioni di Java nelle build Android
Indipendentemente dal fatto che il codice sorgente sia scritto in Java, Kotlin o entrambi,
ci sono diversi punti in cui devi scegliere una versione JDK o del linguaggio Java
per la tua build. Per maggiori dettagli, consulta la sezione Versioni di Java nelle build di Android.
File di configurazione di compilazione
La creazione di configurazioni di compilazione personalizzate richiede modifiche a uno o più file di configurazione di compilazione. Questi file di testo normale utilizzano un linguaggio specifico del dominio (DSL) per descrivere e manipolare la logica di compilazione utilizzando Kotlin Script, una variante del linguaggio Kotlin. Puoi anche utilizzare Groovy, un linguaggio dinamico per la Java Virtual Machine (JVM), per configurare le build.
Non è necessario conoscere Kotlin Script o Groovy per iniziare a configurare la build, perché il plug-in Android Gradle introduce la maggior parte degli elementi DSL necessari. Per scoprire di più sul DSL del plug-in Android per Gradle, consulta la
documentazione di riferimento del DSL. Lo script Kotlin si basa anche sulla
DSL Kotlin di Gradle sottostante
Quando avvii un nuovo progetto, Android Studio crea automaticamente alcuni di questi file e li compila in base a valori predefiniti ragionevoli. Per una panoramica dei file creati, vedi Struttura della build Android.
Il file Gradle Wrapper
Il wrapper Gradle (gradlew) è una piccola applicazione inclusa nel codice sorgente che scarica e avvia Gradle.
In questo modo, l'esecuzione della build è più coerente. Gli sviluppatori scaricano il codice sorgente dell'applicazione ed eseguono gradlew. Viene scaricata la distribuzione Gradle richiesta e viene avviato Gradle per creare l'applicazione.
Il file gradle/wrapper/gradle-wrapper.properties
contiene una proprietà, distributionUrl, che descrive la versione di
Gradle utilizzata per eseguire la build.
Il file settings.gradle.kts (per Kotlin DSL) o
settings.gradle (per Groovy DSL) si trova nella directory
root del progetto. Questo file di impostazioni definisce le impostazioni del repository a livello di progetto e indica a Gradle quali moduli deve includere durante la creazione dell'app. I progetti multimodulo devono specificare ogni modulo da includere nella 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. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */repositories{gradlePluginPortal()google()mavenCentral()}}dependencyResolutionManagement{/** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories{google()mavenCentral()}}rootProject.name="My Application"include(":app")
Groovy
pluginManagement{/** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */repositories{gradlePluginPortal()google()mavenCentral()}}dependencyResolutionManagement{/** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories{google()mavenCentral()}}rootProject.name="My Application"include':app'
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 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"9.1.0"applyfalseid("com.android.library")version"9.1.0"applyfalseid("org.jetbrains.kotlin.android")version"2.3.10"applyfalse}
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'9.1.0'applyfalseid'com.android.library'version'9.1.0'applyfalseid'org.jetbrains.kotlin.android'version'2.3.10'applyfalse}
Il file di build a livello di modulo
Il file build.gradle.kts (per Kotlin DSL) o
build.gradle (per Groovy DSL) a livello di modulo si trova in ogni
directory project/module/. Consente di
configurare le impostazioni di build per il modulo specifico in cui si trova. La configurazione
di queste impostazioni di build ti consente di fornire opzioni di packaging personalizzate, ad esempio
tipi di build e varianti di prodotto aggiuntivi, e di ignorare le impostazioni nel
manifest dell'app main/ o nello script di build di primo livello.
Impostazioni dell'SDK Android
Il file di build a livello di modulo per la tua applicazione include impostazioni che indicano
le versioni dell'SDK Android utilizzate durante la compilazione, la selezione dei comportamenti della piattaforma e
la specifica della versione minima su cui viene eseguita l'applicazione.
Figura 1. SDK Android in una build
compileSdk
compileSdk determina quali API Android e Java sono disponibili durante la compilazione del codice sorgente. Per utilizzare le funzionalità più recenti di Android, utilizza l'SDK Android più recente durante la compilazione.
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 il livello API Java disponibile in base alla versione dell'SDK Android.
Le API Java più recenti sono supportate nelle versioni precedenti di Android tramite
desugaring, che deve essere
abilitato nella build.
Android Studio mostra avvisi se il tuo compileSdk è in conflitto
con la versione corrente di Android Studio, AGP o i requisiti di dipendenza della libreria del progetto.
minSdk
minSdk specifica la versione più bassa di Android che
vuoi che la tua app supporti. L'impostazione minSdk limita i dispositivi che possono installare la tua app.
Il supporto delle versioni precedenti di Android potrebbe richiedere più controlli condizionali
nel codice o un maggiore utilizzo delle librerie di compatibilità AndroidX. Devi
valutare il costo di manutenzione del supporto delle versioni precedenti rispetto alla
percentuale di utenti che utilizzano ancora queste versioni. Consulta il
grafico delle versioni nella procedura guidata Nuovo progetto di Android Studio
per le percentuali di utilizzo delle versioni attuali.
Quando modifichi il codice in Android Studio o esegui controlli durante
la build, lint ti avvisa delle API che utilizzi e che non sono disponibili
in minSdk. Devi risolvere questi problemi
rendendo condizionali le funzionalità più recenti o utilizzando
Appcompat per la compatibilità con le versioni precedenti.
targetSdk
targetSdk ha due scopi:
Imposta il comportamento di runtime dell'applicazione.
Attesta la versione di Android su cui hai eseguito il test.
Se la tua app viene eseguita su un dispositivo che utilizza una versione di Android successiva a quella del tuo targetSdk, Android esegue l'app in modalità di compatibilità, che si comporta in modo simile alla versione precedente indicata nel tuo targetSdk. Ad esempio, quando l'API 23 ha introdotto il modello di autorizzazioni di runtime, non tutte le app erano pronte ad adottarlo immediatamente.
Se imposti targetSdk su 22, queste app potrebbero essere eseguite su
dispositivi API 23 senza utilizzare le autorizzazioni di runtime e potrebbero utilizzare le funzionalità
incluse nell'ultima versione di compileSdk. Le norme di distribuzione di Google Play impongono
norme aggiuntive sul livello API target.
Il valore di targetSdk non è collegato al valore di
compileSdk. Ad esempio, puoi avere un valore di
targetSdk superiore, uguale o inferiore a
compileSdk.
Nota:i valori di compileSdk e targetSdk
non devono essere uguali. Tieni presente i seguenti principi di base:
compileSdk ti dà accesso a nuove API
targetSdk imposta il comportamento di runtime della tua app
Script di build del modulo dell'app di esempio
Questo script di build del modulo dell'app per Android di esempio delinea 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=36/** * 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=23// Specifies the API level used to test the app.targetSdk=36// 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.1")implementation(fileTree(mapOf("dir"to"libs","include"tolistOf("*.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{jvmToolchain11}/** * 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. */compileSdk36/** * 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.minSdk23// Specifies the API level used to test the app.targetSdk36// Defines the version number of your app.versionCode1// 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{minifyEnabledtrue// Enables code shrinking for the release build type.proguardFilesgetDefaultProguardFile('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{implementationproject(":lib")implementation'androidx.appcompat:appcompat:1.7.1'implementationfileTree(dir:'libs',include:['*.jar'])}
File delle proprietà di Gradle
Gradle include anche due file di proprietà, che si trovano nella directory radice del progetto, che puoi utilizzare per specificare le impostazioni per lo stesso toolkit di build Gradle:
gradle.properties
Qui puoi configurare le impostazioni di Gradle a livello di progetto, ad esempio
la dimensione massima dell'heap del daemon Gradle. Per saperne di più, consulta Ambiente di build.
local.properties
Configura le proprietà dell'ambiente locale per il sistema di build, tra cui
le seguenti:
ndk.dir: percorso dell'NDK. Questa proprietà è stata
ritirata. Le versioni scaricate dell'NDK vengono installate nella
directory ndk all'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 collegamento simbolico all'NDK che può essere più breve del percorso NDK installato.
Rimappare l'NDK a un percorso più breve (solo Windows)
In Windows, gli strumenti nella cartella NDK installata, ad esempio 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 che il plug-in Android Gradle crei un link simbolico all'NDK. Il percorso di questo 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
Sincronizzare 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 da poter
importare le modifiche alla configurazione della build ed eseguire alcuni controlli per assicurarsi che la
configurazione non crei errori di build.
Per sincronizzare i file di progetto, fai clic su Sincronizza ora nella
barra di notifica visualizzata quando apporti una modifica, come mostrato nella
Figura 2, oppure fai clic su Sincronizza progetto
dalla barra dei menu. Se Android Studio rileva errori nella configurazione, ad esempio se il codice sorgente utilizza funzionalità API disponibili solo in un livello API superiore a compileSdkVersion, la finestra Messaggi descrive il problema.
Figura 2. Sincronizza il progetto con i file di configurazione
della build in Android Studio.
Set di risorse
Android Studio raggruppa logicamente il codice sorgente e le risorse per ogni modulo
in set di origine. Quando crei un nuovo modulo, Android Studio
crea un set di origini main/ all'interno del modulo. Il set di origini main/ di un modulo include il codice e le risorse utilizzati da tutte le sue varianti di build.
Le directory dei set di origini aggiuntivi sono facoltative e Android
Studio non le crea automaticamente quando configuri nuove varianti di build. Tuttavia, la creazione di set di origini, simili a main/, consente di organizzare i file e le risorse che Gradle deve utilizzare solo durante la creazione di determinate versioni dell'app:
src/main/
Questo insieme di origini include codice e risorse comuni a tutte le varianti di build.
src/buildType/
Crea questo set di origini per includere codice e risorse solo per un tipo di build specifico.
src/productFlavor/
Crea questo set di origini in modo che includa codice e risorse solo per una
variante di prodotto specifica.
Nota:se configuri la build in modo da combinare più
varianti di prodotto, puoi creare directory di set di origini per ogni
combinazione di varianti di prodotto tra le dimensioni delle varianti:
src/productFlavor1ProductFlavor2/.
src/productFlavorBuildType/
Crea questo set di origini 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 dai seguenti set di origini:
src/fullDebug/ (il set di origini della variante di build)
src/debug/ (il set di origini del tipo di build)
src/full/ (il set di origini delle versioni prodotto)
src/main/ (il set di origini principale)
Nota:quando crei un nuovo file o una nuova directory in Android
Studio, utilizza le opzioni del menu File > Nuovo per crearlo
per un insieme di origini specifico. I set di origini che puoi scegliere si basano
sulle configurazioni di build e Android Studio crea automaticamente le
directory richieste se non esistono già.
Se diversi set di origini contengono versioni diverse dello stesso file, Gradle
utilizza il seguente ordine di priorità per decidere quale file utilizzare. I set di risorse a sinistra sostituiscono i file e le impostazioni dei set di risorse a destra:
build variant > build type > product flavor > main source set >
library dependencies
In questo modo, Gradle può utilizzare file specifici della variante di build che
stai tentando di creare, riutilizzando attività, logica dell'applicazione e
risorse comuni ad altre versioni della tua app.
Quando unisce 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 insiemi di fonti personalizzati, leggi Creare insiemi di fonti.
Cataloghi delle versioni
Se la build contiene più moduli con dipendenze comuni o se hai più progetti indipendenti con dipendenze comuni, ti consigliamo di utilizzare un catalogo delle versioni o una distinta materiali (BOM) per specificare le versioni comuni.
Altri sistemi di compilazione
La creazione di app per Android con Bazel è
possibile, ma non ufficialmente supportata. Android Studio non supporta
ufficialmente i progetti Bazel.
Per comprendere meglio le limitazioni attuali della creazione con Bazel, consulta i
problemi noti.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
dalla barra dei menu. Se Android Studio rileva errori nella configurazione, ad esempio se il codice sorgente utilizza funzionalità API disponibili solo in un livello API superiore a 