Il sistema di build di Android compila le risorse e il codice sorgente dell'app e li pacchettizza in APK o Android App Bundle che puoi testare, distribuire, firmare e distribuire.
In Panoramica della build Gradle e Struttura della build Android, abbiamo discusso i concetti di build e la struttura di un'app per Android. Ora è il momento di configurare la build.
Glossario delle 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à utilizzate da Gradle durante la creazione e il packaging della tua app. I tipi di build vengono in genere configurati per 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 potrebbe 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 di 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 versioni prodotto rappresentano diverse versioni della tua app che puoi rilasciare agli utenti, ad esempio versioni senza costi e a pagamento. Puoi personalizzare le versioni prodotto in modo da utilizzare codice e risorse diversi, condividendo e riutilizzando le parti comuni a tutte le versioni della tua app. Le versioni prodotto sono facoltative e devi crearle manualmente. Per iniziare a creare versioni diverse della tua app, scopri come configurare le versioni prodotto.
- Varianti di build
- Una variante di compilazione è un prodotto incrociato di tipo di build e versione prodotto ed è la configurazione utilizzata da Gradle per creare l'app. Utilizzando le varianti di compilazione, puoi creare la versione di debug delle versioni prodotto durante lo sviluppo e le versioni di release firmate delle versioni prodotto per la distribuzione. Anche se non configuri direttamente le varianti di compilazione, configuri i tipi di compilazione e le versioni prodotto che le formano. La creazione di tipi di compilazione o versioni prodotto aggiuntivi comporta anche la creazione di varianti di compilazione aggiuntive. Per scoprire come creare e gestire le varianti di compilazione, leggi la panoramica Configura le varianti di compilazione.
- Voci del manifest
- Puoi specificare i valori per alcune proprietà del file manifest nella configurazione della variante di compilazione. 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 dei manifest.
- Dipendenze
- Il sistema di build 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 tue dipendenze nella directory del progetto. Per saperne di più, consulta Aggiungi 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 il processo di build. Il sistema di build firma la versione di debug con una chiave e un certificato predefiniti utilizzando credenziali note per evitare una richiesta di password al momento della build. Il sistema di build non firma la versione di 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 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 compilazione. Durante la creazione dell'app, il sistema di build applica l'insieme di regole appropriato per ridurre il codice e le risorse utilizzando i suoi 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 compilazione ti consente di creare automaticamente APK diversi, ognuno dei quali contiene solo il codice e le risorse necessari per una densità dello schermo o un'Application Binary Interface (ABI) specifica. Per saperne di più, consulta Crea più APK. Tuttavia, il rilascio di un singolo AAB è l'approccio consigliato, in quanto offre la suddivisione per lingua oltre alla densità dello schermo e all'ABI, evitando al contempo la necessità di caricare più elementi 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, devi scegliere una versione del JDK o del linguaggio Java per la build in diverse posizioni. Per maggiori dettagli, consulta Versioni di Java nelle build Android.
File di configurazione di compilazione
Per creare configurazioni di compilazione personalizzate, devi apportare 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 build utilizzando lo script Kotlin, che è 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 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 di cui hai bisogno. 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 sul DSL Kotlin per 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, consulta 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. In questo modo 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 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 di impostazioni di Gradle
Il file settings.gradle.kts (per il DSL Kotlin) o il file settings.gradle (per il DSL Groovy) 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 includere durante la creazione dell'app. I progetti multimodulo devono specificare ogni modulo che deve essere incluso 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")
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. 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.4.0" apply false id("com.android.library") version "9.4.0" apply false id("org.jetbrains.kotlin.android") version "2.4.10" 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 '9.4.0' apply false id 'com.android.library' version '9.4.0' apply false id 'org.jetbrains.kotlin.android' version '2.4.10' apply false }
Il file di build a livello di modulo
Il file build.gradle.kts (per il DSL Kotlin) o build.gradle (per il DSL Groovy) a livello di modulo si trova in ogni directory project/module/. Ti 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 pacchettizzazione personalizzate, come tipi di build e versioni prodotto aggiuntivi, e di eseguire l'override delle 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.
-
compileSdk -
compileSdkdetermina quali API Android e Java sono disponibili durante la compilazione del codice sorgente. Per utilizzare le funzionalità Android più recenti, utilizza 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 utilizzare le librerie di compatibilità AndroidX per utilizzare le funzionalità più recenti con livelli API Android inferiori.
Ogni SDK Android fornisce un sottoinsieme di API Java da utilizzare nell'applicazione. La tabella nella sezione Quali API Java posso utilizzare nel mio codice sorgente Java o Kotlin mostra quale livello 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.
Se devi eseguire la compilazione in base a un livello API secondario specifico, utilizza la sintassi del blocco
compileSdkespansa e specifica unminorApiLevel:Kotlin
android { compileSdk { version = release(36) { minorApiLevel = 1 } } }
Alla moda
android { compileSdk { version = release(36) { minorApiLevel = 1 } } }
Android Studio visualizza avvisi se
compileSdkè in conflitto con la versione corrente di Android Studio, AGP o i requisiti di dipendenza della libreria del progetto. -
minSdk -
minSdkspecifica la versione più recente di Android che vuoi che la tua app supporti. L'impostazioneminSdklimita i dispositivi su cui è possibile 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à AndroidX. Devi valutare il costo di manutenzione per il supporto delle versioni precedenti rispetto alla percentuale di utenti che le utilizzano ancora. Consulta il grafico delle versioni nella procedura guidata per i nuovi progetti di Android Studio per conoscere le percentuali di utilizzo delle versioni attuali.
Quando modifichi il codice in Android Studio o esegui controlli durante la build, lint ti avviserà delle API che utilizzi che non sono disponibili in
minSdk. Per risolvere questi problemi, rendi condizionali le funzionalità più recenti o utilizzaAppcompatper la compatibilità con le versioni precedenti. -
targetSdk -
targetSdkha due scopi:- Imposta il comportamento di runtime dell'applicazione.
- Attesta la versione di Android con cui hai eseguito i test.
Se l'esecuzione avviene su un dispositivo che utilizza una versione di Android successiva alla
targetSdk, Android esegue l'app in una modalità di compatibilità che si comporta in modo simile alla versione precedente indicata nellatargetSdk. 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 su dispositivi con API 23 senza utilizzare le autorizzazioni di runtime e potrebbero utilizzare le funzionalità incluse nell'ultima versione dicompileSdk. Le norme di distribuzione di Google Play applicano norme aggiuntive sul livello API target.Il valore di
targetSdknon è collegato al valore dicompileSdk. Ad esempio, puoi avere un valore ditargetSdksuperiore, uguale o inferiore acompileSdk.
Nota: i valori di compileSdk e targetSdk non devono necessariamente essere uguali. Tieni presente i seguenti principi di base:
compileSdkti dà accesso a nuove APItargetSdkimposta il comportamento di runtime dell'app
Script di build del modulo dell'app di esempio
Questo script di build del modulo dell'app per Android di esempio 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 = 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.8.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 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. */ 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.8.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
File delle proprietà di Gradle
Gradle include anche due file di proprietà, che si trovano nella directory root del progetto, che puoi utilizzare per specificare le impostazioni per il toolkit di build Gradle stesso:
-
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:
ndk.dir: il percorso dell'NDK. Questa proprietà è stata ritirata. Tutte le versioni scaricate dell'NDK vengono installate nella directoryndkall'interno della directory dell'SDK Android.sdk.dir: percorso dell'SDK Android.cmake.dir: il 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 dell'NDK installato.
Rimappa l'NDK a un percorso più breve (solo Windows)
In Windows, gli strumenti nella cartella NDK installata, come ld.exe, hanno 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 per Gradle crei un collegamento simbolico all'NDK. Il percorso del collegamento simbolico può essere più breve della cartella NDK esistente.
Ad esempio, ndk.symlinkdir = C:\ genera il seguente collegamento simbolico:
C:\ndk\19.0.5232133
Sincronizza il progetto con i file Gradle
Quando apporti modifiche ai file di configurazione di compilazione nel progetto, Android Studio richiede di sincronizzare i file di progetto in modo da poter importare le modifiche alla configurazione di compilazione ed eseguire alcuni controlli per assicurarsi che la configurazione non crei errori di compilazione.
Per sincronizzare i file di progetto, fai clic su Sincronizza ora nella barra di notifica che viene visualizzata quando apporti una modifica, come mostrato nella figura 2, oppure fai clic su Sincronizza progetto 
nella 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, il problema viene descritto nella finestra Messaggi.
Set di risorse
Android Studio raggruppa logicamente il codice sorgente e le risorse per ogni modulo in set di risorse. Quando crei un nuovo modulo, Android Studio crea un set di risorse main/ all'interno del modulo. Il set di risorse main/ di un modulo include il codice e le risorse utilizzati da tutte le sue varianti di compilazione.
Le directory dei set di risorse aggiuntive sono facoltative e Android Studio non le crea automaticamente quando configuri nuove varianti di build. Tuttavia, la creazione di set di risorse, simili a main/, aiuta a organizzare i file e le risorse che Gradle deve utilizzare solo durante la creazione di determinate versioni dell'app:
-
src/main/ - Questo set di risorse include codice e risorse comuni a tutte le varianti di compilazione.
-
src/buildType/ - Crea questo set di risorse per includere codice e risorse solo per un tipo di build specifico.
-
src/productFlavor/ -
Crea questo set di risorse per includere codice e risorse solo per una versione prodotto specifica.
Nota:se configuri la build in modo da combinare più versioni prodotto, puoi creare directory di set di risorse per ogni combinazione di versioni prodotto tra le dimensioni versioni:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Crea questo set di risorse per includere codice e risorse solo per una variante di compilazione specifica.
Ad esempio, per generare la versione "fullDebug" della tua app, il sistema di build unisce codice, impostazioni e risorse dei seguenti set di risorse:
-
src/fullDebug/(il set di risorse della variante di compilazione) -
src/debug/(il set di risorse del tipo di build) -
src/full/(il set di risorse della versione prodotto) -
src/main/(il set di risorse 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 o la directory per un set di risorse specifico. I set di risorse tra cui puoi scegliere si basano sulle configurazioni di compilazione e Android Studio crea automaticamente le directory richieste se non esistono già.
Se set di risorse diversi 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:
variante di compilazione > tipo di build > versione prodotto > set di risorse principale > dipendenze della libreria
In questo modo, Gradle può utilizzare file specifici per la variante di compilazione che stai tentando di creare, riutilizzando al contempo attività, logica dell'applicazione e risorse comuni ad altre versioni della tua app.
Quando unisci più manifest, Gradle utilizza lo stesso ordine di priorità in modo che ogni variante di compilazione possa definire componenti o autorizzazioni diversi nel manifest finale. Per scoprire di più sulla creazione di set di risorse personalizzati, consulta Crea set di risorse.
Cataloghi delle versioni
Se la tua 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 base (BOM) per specificare le versioni comuni.
Altri sistemi di build
La creazione di app per Android con Bazel è possibile, ma non è supportata ufficialmente. Android Studio non supporta ufficialmente i progetti Bazel.
Per comprendere meglio le limitazioni attuali della creazione con Bazel, consulta i problemi noti.