Il sistema di build di Android compila le risorse e il codice sorgente dell'app e le 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 compilazione:
Tipi di build
I tipi di build definiscono determinate proprietà utilizzate da Gradle durante la compilazione e il packaging dell'app. In genere, i tipi di build sono 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.
Per compilare l'app, devi definire almeno un tipo di build. Android Studio crea i tipi di build di debug e release per impostazione predefinita. Per iniziare a personalizzare le impostazioni di pacchettizzamento per la tua app, scopri come configurare i tipi di compilazione.
Versioni del prodotto
Le varianti del prodotto rappresentano le 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, condividendo e riutilizzando le 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 i flavor dei prodotti.
Creare varianti
Una variante di build è un prodotto combinato di tipo di build e variante di prodotto ed è la configurazione utilizzata da Gradle per compilare l'app. Con le varianti di build,
puoi compilare la versione di debug delle varianti di prodotto durante lo sviluppo
e le versioni release firmate delle varianti di prodotto per la distribuzione.
Anche se non configuri direttamente le varianti di build, configuri i tipi di build e le versioni del prodotto che le formano. La creazione di tipi di build o varianti di prodotto aggiuntivi comporta anche la creazione di varianti di build aggiuntive. Per scoprire come creare e gestire le varianti di build, consulta la panoramica su come configurare le varianti di build.
Voci del manifest
Puoi specificare valori per alcune proprietà del file manifest nella configurazione della variante di compilazione. Questi valori di compilazione 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 diversa. 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 manualmente
cercare, scaricare e copiare i pacchetti binari delle dipendenze nella directory del progetto. Per scoprire di più, consulta Aggiungere dipendenze di compilazione.
Firma
Il sistema di compilazione ti consente di specificare le impostazioni di firma nella configurazione della compilazione e può firmare automaticamente la tua app durante la procedura di compilazione. Il sistema di compilazione firma la versione di debug con una chiave e un certificato predefiniti utilizzando credenziali note per evitare la richiesta di una password al momento della compilazione. Il sistema di build non firma la versione di release, a meno che non
definisci esplicitamente una configurazione di firma per questa build. Se non hai una chiave di release, puoi generarne una come descritto in Firmare l'app. Le build di release firmate sono obbligatorie per la distribuzione delle 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 di ProGuard diverso per ogni variante di compilazione. Durante la compilazione dell'app, il sistema di compilazione applica il
insieme di regole appropriato per ridurre il codice e le risorse utilizzando i propri 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 diversi APK che contengono ciascuno solo il codice e le risorse necessarie per una specifica densità dello schermo o ABI (Application Binary Interface).
Per ulteriori informazioni, consulta
Creare più APK. Tuttavia, la pubblicazione di un singolo AAB è
l'approccio consigliato, in quanto offre la suddivisione per lingua oltre che per
densità dello schermo e 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 Java nelle build Android
Indipendentemente dal fatto che il codice sorgente sia scritto in Java, Kotlin o in entrambi,
in diversi punti devi scegliere una versione del linguaggio JDK o Java per la tua build. Per maggiori dettagli, consulta la sezione Versioni Java nelle build Android.
File di configurazione di compilazione
La creazione di configurazioni di compilazione personalizzate richiede di 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 compilazione utilizzando lo script Kotlin, 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 compilazione, perché il plug-in Gradle per Android introduce la maggior parte degli elementi DSL di cui hai bisogno. Per scoprire di più sul DSL del plug-in Android Gradle, consulta la
documentazione di riferimento del DSL. Lo script Kotlin si basa anche sul
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, consulta la struttura di build di Android.
Il file Gradle Wrapper
Il wrapper Gradle (gradlew) è una piccola applicazione inclusa nel codice sorgente che scarica e avvia Gradle stesso.
In questo modo, l'esecuzione della compilazione è più coerente. Gli sviluppatori scaricano il codice sorgente dell'applicazione ed eseguono gradlew. Verrà scaricata la distribuzione Gradle necessaria e verrà avviato Gradle per compilare l'applicazione.
Il file gradle/wrapper/gradle-wrapper.properties contiene una proprietà, distributionUrl, che descrive la versione di Gradle utilizzata per eseguire la compilazione.
Il file settings.gradle.kts (per il DSL Kotlin) o
settings.gradle (per il DSL Groovy) si trova nella directory
principale del progetto. Questo file di impostazioni definisce le impostazioni del repository a livello di progetto e comunica a Gradle quali moduli includere durante la compilazione dell'app. I progetti multi-modulo devono specificare ogni modulo da includere nella compilazione finale.
Per la maggior parte dei progetti, il file ha il seguente aspetto per impostazione predefinita:
Il file build.gradle.kts di primo livello (per il DSL Kotlin) o il file build.gradle (per il DSL Groovy) 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 compilazione di primo livello dopo la creazione di un nuovo progetto:
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 compilazione per il modulo specifico in cui si trova. La configurazione di queste impostazioni di compilazione ti consente di fornire opzioni di pacchetti personalizzati, ad esempio tipi di compilazione e varianti di prodotto aggiuntivi, e di eseguire l'override delle impostazioni nel manifest dell'app main/ o nello script di compilazione di primo livello.
Impostazioni SDK Android
Il file di compilazione a livello di modulo per l'applicazione include impostazioni che indicano le versioni dell'SDK Android utilizzate durante la compilazione, la selezione dei comportamenti della piattaforma e 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 al momento della compilazione del codice sorgente. Per utilizzare le funzionalità Android più recenti, 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 codice sorgente Java o Kotlin
mostra il livello dell'API Java disponibile in base alla versione dell'SDK Android.
Le API Java più recenti sono supportate nelle versioni precedenti di Android tramite la desugaring, che deve essere attivata nella compilazione.
Android Studio mostra avvisi se compileSdk è in conflitto con la versione corrente di Android Studio, AGP o con i requisiti di dipendenza della libreria del progetto.
minSdk
minSdk specifica la versione minima di Android che vuoi supportare per la tua app. L'impostazione minSdk limita 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 bilanciare il costo di manutenzione del supporto delle versioni precedenti rispetto alla percentuale di utenti che le utilizzano ancora. Consulta il grafico delle versioni nella procedura guidata Nuovo progetto di Android Studio per conoscere le percentuali di utilizzo delle versioni correnti.
Quando modifichi il codice in Android Studio o esegui controlli durante la compilazione, lint ti avvisa delle API che utilizzi e che non sono disponibili nel minSdk. Per risolvere il problema,
imposta le funzionalità più recenti come agevolate o utilizza
Appcompat per la compatibilità con le versioni precedenti.
targetSdk
targetSdk ha due scopi:
Imposta il comportamento di runtime dell'applicazione.
Indica la versione di Android su cui hai eseguito il test.
Se esegui l'app su un dispositivo che utilizza una versione di Android successiva a quella del tuo targetSdk, Android esegue l'app in una 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.
Impostando targetSdk su 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 di compileSdk. Le norme di distribuzione di Google Play applicano
norme aggiuntive a livello di API target.
Il valore di targetSdk deve essere minore o uguale
a quello di compileSdk.
Nota: i valori di compileSdk e targetSdk
non devono essere necessariamente uguali. Tieni presente i seguenti principi di base:
compileSdk ti consente di accedere a nuove API
targetSdk imposta il comportamento di runtime dell'app
targetSdk deve essere inferiore o uguale a compileSdk
Script di compilazione del modulo dell'app di esempio
Questo script di compilazione del modulo dell'app per Android di esempio illustra alcuni degli elementi e delle impostazioni di DSL di base:
Gradle include anche due file di proprietà, situati nella directory del progetto principale, che puoi utilizzare per specificare le impostazioni per lo stesso set di strumenti di compilazione Gradle:
gradle.properties
Qui puoi configurare le impostazioni Gradle a livello di progetto, ad esempio la dimensione massima dell'heap del daemon Gradle. Per ulteriori informazioni, consulta Ambiente di compilazione.
local.properties
Configura le proprietà dell'ambiente locale per il sistema di compilazione, tra cui:
ndk.dir - Percorso del NDK. Questa proprietà è stata ritirata. Le eventuali versioni scaricate dell'NDK vengono installate nella directory
ndk all'interno della directory Android SDK.
sdk.dir: percorso dell'SDK Android.
cmake.dir: percorso a CMake.
ndk.symlinkdir - In Android Studio 3.5 e versioni successive,
viene creato un link simbolico all'NDK che può essere più breve del percorso dell'NDK installato.
Rimappare 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 Gradle per Android crei un link simbolico al
NDK. Il percorso del 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 di build nel progetto,
Android Studio richiede di sincronizzare i file del progetto in modo da poterli eseguire
importare le modifiche alla configurazione di 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 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 il codice sorgente utilizza funzionalità dell'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 compilazione in Android Studio.
Set di origini
Android Studio raggruppa logicamente il codice sorgente e le risorse per ogni modulo in set di origini. Quando crei un nuovo modulo, Android Studio
crea un insieme di origini main/ all'interno del modulo. Il set di origini main/ di un modulo include il codice e le risorse utilizzate da tutte le relative varianti di build.
Le directory degli insiemi di origine aggiuntivi sono facoltative e Android Studio non le crea automaticamente quando configuri nuove varianti di build. Tuttavia, la creazione di insiemi di origine, simile a main/, aiuta
a organizzare i file e le risorse che Gradle deve utilizzare solo durante la compilazione di determinate
versioni dell'app:
src/main/
Questo insieme di origini include il codice e le risorse comuni a tutte le varianti di build.
src/buildType/
Crea questo insieme 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 un sapore di prodotto specifico.
Nota:se configuri la compilazione per combinare più gusti dei prodotti, puoi creare directory degli insiemi di origine per ogni combinazione di gusti dei prodotti tra le dimensioni dei gusti: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" dell'app, il sistema di compilazione unisce codice, impostazioni e risorse dai seguenti set di origine:
src/fullDebug/ (il set di origine della variante di compilazione)
src/debug/ (il set di origine del tipo di compilazione)
src/full/ (l'origine della versione prodotto impostata)
src/main/ (l'insieme di origini principale)
Nota:quando crei un nuovo file o una nuova directory in Android Studio, utilizza le opzioni di menu File > Nuovo per crearlo per un insieme di origini specifico. Gli insiemi di origini tra cui puoi scegliere si basano sulle configurazioni di compilazione e Android Studio crea automaticamente le directory richieste se non esistono già.
Se insiemi di origine 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 dei set di origini a destra:
build variant > build type > product flavor > main source set >
library dependencies
In questo modo, Gradle può utilizzare i file specifici della variante di build che stai tentando di creare, riutilizzando al contempo attività, logica di applicazione e risorse comuni ad altre versioni dell'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 origini personalizzati, consulta Creare set di origini.
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 compilazione
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 compilazione 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.