Configura la tua build

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.3.0" apply false
    id("com.android.library") version "8.3.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.20" 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.3.0' apply false
    id 'com.android.library' version '8.3.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.20' apply false
}