Il sistema di build di Android compila le risorse delle app e il codice sorgente e li pacchettizza in APK o Android App Bundle che puoi testare, sottoporre a deployment, firmare e distribuire.
Android Studio utilizza Gradle, un toolkit avanzato per la creazione, per automatizzare e gestire il processo di compilazione e definire configurazioni flessibili e personalizzate. Ogni configurazione di build può definire il proprio set di codice e risorse riutilizzando le parti comuni a tutte le versioni dell'app. Il plug-in Android Gradle funziona con il toolkit di build per fornire processi e impostazioni configurabili specifici per la creazione e il test di app per Android.
Gradle e il plug-in Android per Gradle vengono eseguiti indipendentemente da Android Studio. Ciò significa che puoi creare le tue app per Android da Android Studio, dalla riga di comando del computer o sui computer su cui Android Studio non è installato, ad esempio i server di integrazione continua.
Se non utilizzi Android Studio, puoi scoprire come creare ed eseguire la tua app dalla riga di comando. L'output della build è lo stesso indipendentemente dal fatto che tu stia creando un progetto dalla riga di comando, su una macchina remota o utilizzando Android Studio.
Nota: poiché Gradle e il plug-in Android Gradle vengono eseguiti in modo indipendente rispetto ad Android Studio, devi aggiornare gli strumenti di creazione separatamente. Leggi le note di rilascio per scoprire come aggiornare Gradle e il plug-in Android per Gradle.
La flessibilità del sistema di build Android consente di creare configurazioni di build personalizzate senza modificare i file di origine principali dell'app. Questa pagina ti aiuta a capire come funziona il sistema di build Android e come può aiutarti a personalizzare e automatizzare più configurazioni di build. Se vuoi saperne di più sul deployment della tua app, consulta Creare ed eseguire la tua app. Per iniziare subito a creare configurazioni di build personalizzate utilizzando Android Studio, consulta Configurare le varianti di build.
Il processo di compilazione
Il processo di compilazione prevede molti strumenti e processi che convertono il progetto in un Android Application Package (APK) o Android App Bundle (AAB).
Il plug-in Android per Gradle si occupa di gran parte del processo di compilazione al posto tuo, ma può essere utile comprendere alcuni aspetti di questo processo in modo da poter regolare la build in base ai tuoi requisiti.
Progetti diversi possono avere obiettivi di build diversi. Ad esempio, la build per una libreria di terze parti produce librerie Android Archive (AAR) o Java Archive (JAR). Tuttavia, un'app è il tipo di progetto più comune e la build di un progetto di app produce un APK o AAB di debug o release dell'app di cui puoi eseguire il deployment, testarlo o rilasciarlo a utenti esterni.
Questa pagina è incentrata sullo sviluppo di app, ma molti passaggi e concetti sono comuni alla maggior parte dei tipi di build.
Glossario di build Android
Gradle e il plug-in Android Gradle consentono di configurare i seguenti aspetti della build:
- Tipi di build
-
I tipi di build definiscono determinate proprietà utilizzate da Gradle durante la creazione e la pacchettizzazione dell'app. I tipi di build sono in genere configurati per diverse fasi del ciclo di vita di sviluppo.
Ad esempio, il tipo di build di debug abilita le opzioni di debug e firma l'app con la chiave di debug, mentre il tipo di build della 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 release per impostazione predefinita. Per iniziare a personalizzare le impostazioni di pacchettizzazione per la tua app, scopri come configurare i tipi di build.
- sapori dei prodotti
- Le varianti di prodotto rappresentano versioni diverse della tua app che puoi rilasciare agli utenti, ad esempio versioni senza costi e a pagamento. Puoi personalizzare le versioni dei prodotti in modo da utilizzare risorse e codice diversi, condividendo e riutilizzando le parti comuni a tutte le versioni della tua app. Le versioni dei prodotti sono facoltative e devi crearle manualmente. Per iniziare a creare versioni diverse della tua app, scopri come configurare le versioni dei prodotti.
- Creare varianti
- Una variante di build è composta da più prodotti tra tipi di build e versioni di prodotto ed è 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 le versioni di release firmate delle versioni di prodotto per la distribuzione. Anche se non configuri le varianti di build direttamente, sei tu a configurare i tipi di build e le versioni di prodotto che le formano. La creazione di tipi di build o versioni di prodotti aggiuntivi comporta anche la creazione di varianti di build aggiuntive. Per informazioni su come creare e gestire le varianti di build, consulta la panoramica su come configurare le varianti di build.
- Voci del file manifest
- Puoi specificare i valori per alcune proprietà del file manifest nella configurazione della variante della build. Questi valori di build sostituiscono i valori esistenti nel file manifest. Questo è utile se vuoi generare più varianti della tua app con un nome dell'applicazione, una versione minima dell'SDK o una versione dell'SDK di destinazione diversi. Quando sono presenti più manifest, lo strumento di unione dei manifest unisce le impostazioni del manifest.
- Dipendenze
- Il sistema di build gestisce le dipendenze del progetto dal tuo 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 scoprire di più, consulta Aggiungere dipendenze build.
- Firma
- Il sistema di compilazione consente di specificare le impostazioni di firma nella configurazione della build e può firmare automaticamente la tua app durante il processo di compilazione. Il sistema di build firma la versione di debug con una chiave e un certificato predefiniti utilizzando credenziali note per evitare la richiesta di password al momento della creazione. Il sistema di compilazione non firma la versione della release a meno che tu non definisca esplicitamente una configurazione di firma per questa build. Se non hai una chiave di rilascio, puoi generarne una come descritto nella sezione Firma dell'app. Le build di release firmate sono necessarie per la distribuzione di app tramite la maggior parte degli store.
- Contrazione di codice e risorse
- Il sistema di build consente di specificare un file di regole ProGuard diverso per ogni variante di build. Durante la creazione dell'app, il sistema di compilazione applica l'insieme di regole appropriato per ridurre il codice e le risorse utilizzando gli strumenti di riduzione integrati, come R8. La riduzione del codice e delle risorse può aiutarti a ridurre le dimensioni dell'APK o dell'AAB.
- Supporto di più APK
- Il sistema di build consente di creare automaticamente diversi APK contenenti ognuno solo il codice e le risorse necessari per una specifica densità dello schermo o ABI (Application Binary Interface). Per maggiori informazioni, consulta la sezione Creare più APK. Tuttavia, l'approccio consigliato è il rilascio di un singolo AAB, in quanto offre la suddivisione per lingua oltre alla densità dello schermo e all'ABI, evitando al contempo di caricare più artefatti su Google Play. Tutte le nuove app inviate dopo agosto 2021 devono utilizzare gli AAB.
Versioni Java nelle build Android
Che il codice sorgente sia scritto in Java, Kotlin o entrambi, è necessario scegliere una versione in linguaggio JDK o Java per la build in diverse posizioni. Per maggiori dettagli, consulta Versioni Java nelle build Android.
File di configurazione di compilazione
Per creare configurazioni di compilazione personalizzate è necessario apportare modifiche a uno o più file di configurazione di compilazione. Questi file di testo normale utilizzano DSL (Domain Specific Language) per descrivere e manipolare la logica di compilazione utilizzando lo script Kotlin, un sapore del linguaggio Kotlin. Puoi anche utilizzare Groovy, che è un linguaggio dinamico per la Java Virtual Machine (JVM), per configurare le tue build.
Non è necessario conoscere lo script Kotlin o Groovy per iniziare a configurare la build, poiché 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 la documentazione di riferimento DSL. Lo script Kotlin si basa anche sul sottostante Gradle Kotlin DSL.
Quando inizi un nuovo progetto, Android Studio crea automaticamente alcuni di questi file e li compila in base a valori predefiniti appropriati. La struttura del file di progetto ha il seguente layout:
└── MyApp/ # Project ├── gradle/ │ └── wrapper/ │ └── gradle-wrapper.properties ├── build.gradle(.kts) ├── settings.gradle(.kts) └── app/ # Module │ ├── build.gradle(.kts) │ ├── build/ │ ├── libs/ │ └── src/ │ └── main/ # Source set │ ├── java/ │ │ └── com.example.myapp │ ├── res/ │ │ ├── drawable/ │ │ ├── values/ │ │ └── ... │ └── AndroidManifest.xml
Alcuni file di configurazione di compilazione Gradle fanno parte della struttura standard dei progetti per un'app per Android. Prima di iniziare a configurare la build, è importante comprendere l'ambito e lo scopo di ciascuno di questi file e gli elementi DSL di base che definiscono.
Il file Gradle Wrapper
Il wrapper Gradle (gradlew
) è una piccola applicazione inclusa nel codice sorgente che scarica e avvia Gradle stesso.
Ciò crea un'esecuzione della build più coerente. Gli sviluppatori scaricano l'origine dell'applicazione ed eseguono gradlew
. Viene scaricata la distribuzione Gradle richiesta e viene avviata 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 delle impostazioni Gradle
Il file settings.gradle.kts
(per Kotlin DSL) o
il file settings.gradle
(per Groovy DSL) si trova nella directory
principale del progetto. Questo file delle impostazioni definisce le impostazioni del repository a livello di progetto e informa Gradle quali moduli deve includere quando viene creata l'app. I progetti con più moduli devono specificare ogni modulo che deve essere inviato alla build finale.
Per la maggior parte dei progetti, il file sarà simile al seguente per impostazione predefinita:
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. The code below * defines the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
trendy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. The code below * defines the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
Il file di build di primo livello
Il file build.gradle.kts
di primo livello (per il Kotlin DSL) o
il file build.gradle
(per il 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 "8.5.0" apply false id("com.android.library") version "8.5.0" apply false id("org.jetbrains.kotlin.android") version "1.9.23" apply false }
trendy
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id 'com.android.application' version '8.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
Il file di build a livello di modulo
Il file build.gradle.kts
a livello di modulo (per Kotlin DSL) o
build.gradle
(per Groovy DSL) 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 pacchettizzazione personalizzate, ad esempio tipi di build e versioni di prodotto aggiuntivi, e di sostituire le impostazioni nel manifest dell'app main/
o nello script di build di primo livello.
Impostazioni SDK Android
Il file di build a livello di modulo dell'applicazione include impostazioni che indicano le versioni dell'SDK Android utilizzate durante la compilazione, la selezione del comportamento della piattaforma e la specifica della versione minima su cui viene eseguita l'applicazione.
-
compileSdk
-
compileSdk
determina quali API Android e Java sono disponibili durante la compilazione del codice sorgente. Per utilizzare le funzionalità Android più recenti, usa l'SDK Android più recente durante la compilazione.Alcune API della piattaforma Android potrebbero non essere disponibili nei livelli API precedenti. Puoi proteggere in modo condizionale l'utilizzo delle funzionalità più recenti o utilizzare le librerie di compatibilità AndroidX per usare funzionalità più recenti con livelli API Android inferiori.
Ogni SDK Android fornisce un sottoinsieme di API Java da utilizzare nella tua applicazione. La tabella alla pagina 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 il desugaring, che deve essere abilitato nella build.
Android Studio mostra avvisi se
compileSdk
è in conflitto con la versione corrente di Android Studio, AGP o con i requisiti di dipendenza dalla libreria del progetto. -
minSdk
-
Il campo
minSdk
specifica la versione più bassa di Android che vuoi sia supportata dalla tua app. L'impostazione diminSdk
limita i dispositivi che possono installare la tua app.Il supporto di versioni precedenti di Android potrebbe richiedere controlli condizionali più nel codice o ulteriori utilizzi delle librerie di compatibilità AndroidX. Ti consigliamo di valutare il costo della manutenzione per il supporto di versioni precedenti confrontandolo con la percentuale di utenti che utilizzano ancora le versioni precedenti. Controlla il grafico delle versioni nella procedura guidata del nuovo progetto di Android Studio per conoscere le percentuali attuali di utilizzo della versione.
Quando modifichi il codice in Android Studio o esegui controlli durante la build, lint ti avvisa della presenza di API che utilizzi e non disponibili in
minSdk
. Per risolvere il problema, rendendo le funzionalità più recenti condizionali o utilizzandoAppcompat
per garantire la compatibilità con le versioni precedenti. -
targetSdk
-
targetSdk
ha due scopi:- Imposta il comportamento di runtime dell'applicazione.
- che attesta la versione di Android rispetto alla quale è stato eseguito il test.
Se esegui su un dispositivo che utilizza una versione di Android superiore a quella di
targetSdk
, Android esegue la tua app in una modalità di compatibilità che funziona in modo simile alla versione precedente indicata intargetSdk
. Ad esempio, quando l'API 23 ha introdotto il modello di autorizzazioni di runtime, non tutte le app erano pronte per adottarlo immediatamente. Se il criteriotargetSdk
viene impostato su 22, le app potrebbero essere eseguite su dispositivi API 23 senza autorizzazioni di runtime e potrebbero utilizzare le funzionalità incluse nell'ultima versione dicompileSdk
. I criteri di distribuzione di Google Play applicano criteri aggiuntivi sul livello API di destinazione.Il valore di
targetSdk
deve essere inferiore o uguale a quello dicompileSdk
.
Nota: i valori di compileSdk
e targetSdk
non devono essere uguali. Tieni presente i seguenti principi di base:
compileSdk
ti consente di accedere a nuove APItargetSdk
imposta il comportamento di runtime della tua apptargetSdk
deve essere inferiore o uguale acompileSdk
Script di build del modulo dell'app di esempio
Questo script di build per moduli di app per Android di esempio illustra alcuni elementi e impostazioni DSL di base:
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace = "com.example.myapp" /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk = 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdk = 21 // Specifies the API level used to test the app. targetSdk = 33 // Defines the version number of your app. versionCode = 1 // Defines a user-friendly version name for your app. versionName = "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ getByName("release") { isMinifyEnabled = true // Enables code shrinking for the release build type. proguardFiles( getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" ) } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store, or an Android device, simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions += "tier" productFlavors { create("free") { dimension = "tier" applicationId = "com.example.myapp.free" } create("paid") { dimension = "tier" applicationId = "com.example.myapp.paid" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation(project(":lib")) implementation("androidx.appcompat:appcompat:1.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
trendy
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace 'com.example.myapp' /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdk 21 // Specifies the API level used to test the app. targetSdk 33 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store, or an Android device, simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation project(":lib") implementation 'androidx.appcompat:appcompat:1.7.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
File delle proprietà Gradle
Gradle include anche due file di proprietà, situati nella directory principale del progetto, che puoi utilizzare per specificare le impostazioni per il toolkit di build Gradle stesso:
-
gradle.properties
- Qui puoi configurare le impostazioni Gradle a livello di progetto, ad esempio la dimensione heap massima del daemon Gradle. Per ulteriori informazioni, consulta Ambiente di creazione.
-
local.properties
-
Configura le proprietà dell'ambiente locale per il sistema di compilazione, incluse le seguenti:
ndk.dir
- Percorso per l'NDK. Questa proprietà è stata deprecata. Tutte le versioni scaricate dell'NDK vengono installate nella directoryndk
all'interno della directory dell'SDK Android.sdk.dir
: percorso dell'SDK 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ù corto del percorso NDK installato.
Rimappa l'NDK su un percorso più breve (solo Windows)
In Windows, gli strumenti nella cartella NDK installata, come ld.exe
, presentano percorsi lunghi. Gli strumenti non supportano bene percorsi lunghi.
Per creare un percorso più breve, in local.properties
imposta la proprietà
ndk.symlinkdir
per richiedere al plug-in Android Gradle di creare un collegamento simbolico
all'NDK. Il percorso di tale collegamento simbolico può essere più breve rispetto alla 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 nel tuo progetto, Android Studio richiede la sincronizzazione dei file di progetto in modo che possa importare le modifiche alla configurazione della build 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 1, 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 soltanto in un livello API superiore a quello di compileSdkVersion
, la finestra Messaggi descrive il problema.
Set di origini
Android Studio raggruppa logica il codice sorgente e le risorse per ogni modulo
in set di origini. Quando crei un nuovo modulo, Android Studio crea un set di origine main/
all'interno del modulo. Il set di origine main/
di un modulo include il codice e le risorse utilizzati da tutte le sue varianti di build.
Le directory aggiuntive dei set di origine 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 file e risorse che Gradle dovrebbe utilizzare solo durante la creazione di determinate versioni della tua app:
-
src/main/
- Questo set di origini include codice e risorse comuni a tutte le varianti della 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 per includere codice e risorse solo per una tipologia di prodotto specifica.
Nota: se configuri la build per combinare più versioni di prodotto, puoi creare directory dei set di origine per ogni combinazione di versioni di prodotto tra le dimensioni flavor:
src/productFlavor1ProductFlavor2/
. -
src/productFlavorBuildType/
- Crea questo set di origini in modo da includere codice e risorse solo per una variante di build specifica.
Ad esempio, per generare la versione "fullDebug" dell'app, il sistema di build unisce codice, impostazioni e risorse dei seguenti set di origini:
-
src/fullDebug/
(il set di origine delle varianti di build) -
src/debug/
(il set di origine del tipo di build) -
src/full/
(l'insieme di origine dei gusti del prodotto) -
src/main/
(l'insieme di origine principale)
Nota: quando crei un nuovo file o una nuova directory in Android Studio, utilizza le opzioni di menu File > Nuovo per creare il file per un set di origine specifico. I set di origine tra cui puoi scegliere si basano sulle configurazioni della build e 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. I set di origini a sinistra sostituiscono i file e le impostazioni degli insiemi di origini a destra:
variante di build > tipo di build > versione di prodotto > set di origine principale > dipendenze di libreria
In questo modo Gradle può utilizzare file specifici per la variante di build che stai cercando di creare riutilizzando 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 build possa definire componenti o autorizzazioni diversi nel manifest finale. Per scoprire di più sulla creazione di set di origini personalizzati, consulta Creare set di origini.
Cataloghi delle versioni
Se la build contiene più moduli con dipendenze comuni o hai più progetti indipendenti con dipendenze comuni, ti consigliamo di utilizzare un catalogo delle versioni o una distinta base (BOM) per specificare le versioni comuni.
Altri sistemi di compilazione
La creazione di app Android con Bazel è possibile, ma non è ufficialmente supportata. Android Studio non supporta ufficialmente i progetti Bazel.
Per comprendere meglio gli attuali limiti della creazione con Bazel, consulta i problemi noti.