Configura la tua build

Il sistema di build Android compila le risorse dell'app e il codice sorgente e li pacchettizza in APK o Android App Bundle che puoi testare, eseguire il deployment, firmare e distribuire.

Android Studio utilizza Gradle, un toolkit avanzato per lo sviluppo, per automatizzare e gestire il processo di compilazione e consentirti di definire configurazioni di build flessibili e personalizzate. Ogni configurazione di build può definire un 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 Android.

Gradle e il plug-in Android per Gradle vengono eseguiti indipendentemente da Android Studio. Ciò significa che puoi creare app per Android da Android Studio, dalla riga di comando del tuo computer o sulle macchine 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 sia 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 per Gradle vengono eseguiti in modo indipendente da 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 compilazione 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. Per saperne di più sul deployment della tua app, consulta Creare ed eseguire un'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, ma può essere utile per comprendere determinati aspetti del processo di compilazione in modo da poter regolare la build in base ai tuoi requisiti.

Progetti diversi possono avere obiettivi di build diversi. Ad esempio, la build di 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 genera un APK o AAB di debug o di release dell'app che puoi eseguire il deployment, il test o il rilascio per gli utenti esterni.

Questa pagina è dedicata allo 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 per Gradle ti aiutano a configurare i seguenti aspetti della build:

Tipi di build

I tipi di build definiscono determinate proprietà che Gradle utilizza durante la creazione e la pacchettizzazione della tua app. In genere, i tipi di build sono configurati per diverse fasi del ciclo di vita di sviluppo.

Ad esempio, il tipo di build di debug attiva opzioni di debug e firma l'app con la chiave di debug, mentre il tipo di build di release potrebbe ridurre, offuscare e firmare la tua app con una chiave di rilascio per la distribuzione.

Devi definire almeno un tipo di build per creare l'app. Android Studio crea i tipi di build di debug e release per impostazione predefinita. Per iniziare a personalizzare le impostazioni di pacchetto per la tua app, scopri come configurare i tipi di build.

Sapori di prodotto
Le versioni di prodotto rappresentano diverse versioni dell'app che puoi rilasciare per gli 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 dell'app. Le versioni dei prodotti sono facoltative e devi crearle manualmente. Per iniziare a creare versioni diverse dell'app, scopri come configurare le versioni dei prodotti.
Creare varianti
Una variante build è composta da più prodotti tra tipo di build e versione di prodotto ed è la configurazione utilizzata da Gradle per creare la tua app. Utilizzando le varianti 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 direttamente le varianti di build, devi configurare i tipi di build e le versioni di prodotto che le formano. La creazione di tipi di build o versioni di prodotto aggiuntive crea anche 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 file manifest
Puoi specificare i valori per alcune proprietà del file manifest nella configurazione della variante 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 target 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 dei progetti dal file system locale e da 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 Aggiungere dipendenze di build.
Firma
Il sistema di build ti 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 una password al momento della build. 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 release, puoi generarne una come descritto nella sezione Firmare l'app. Le build di release firmate sono necessarie per la distribuzione di app tramite la maggior parte degli store.
Riduzione di codice e risorse
Il sistema di compilazione ti consente di specificare un file di regole ProGuard diverso per ogni variante di build. Durante la creazione dell'app, il sistema di build applica l'insieme appropriato di regole per ridurre il codice e le risorse utilizzando gli strumenti integrati, ad esempio 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, ciascuno contenente solo il codice e le risorse necessari per una specifica densità dello schermo o un'ABI (Application Binary Interface) specifica. Per maggiori informazioni, consulta la pagina Creare più APK. Tuttavia, l'approccio consigliato è il rilascio di un singolo AAB, poiché offre la suddivisione per lingua, oltre alla densità dello schermo e all'ABI, senza dover caricare più elementi su Google Play. Tutte le nuove app inviate dopo agosto 2021 devono utilizzare gli AAB.

Versioni Java nelle build Android

Sia che il codice sorgente sia scritto in Java, Kotlin o entrambi, esistono diverse posizioni in cui devi scegliere una versione del linguaggio JDK o Java per la tua build. Per i dettagli, consulta Versioni Java nelle build Android.

File di configurazione di compilazione

Per creare configurazioni di build personalizzate, devi apportare modifiche a uno o più file di configurazione di compilazione. Questi file di testo normale utilizzano Domain Specific Language (DSL) per descrivere e manipolare la logica di build utilizzando lo script Kotlin, che è un sapore del linguaggio Kotlin. Puoi anche utilizzare Groovy, 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, perché il plug-in Android per Gradle introduce la maggior parte degli elementi DSL necessari. Per scoprire di più sul plug-in DSL per Android per Gradle, 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 completa in base a valori predefiniti validi. 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

Esistono alcuni file di configurazione di compilazione Gradle che fanno parte della struttura standard del progetto per un'app per Android. Prima di iniziare a configurare la build, è importante comprendere l'ambito e lo scopo di ognuno 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. Questo crea un'esecuzione della build più coerente. Gli sviluppatori scaricano l'origine dell'applicazione ed eseguono gradlew. Questa operazione scarica la distribuzione Gradle richiesta e avvia Gradle per creare la tua 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 di 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 di impostazioni definisce le impostazioni del repository a livello di progetto e informa Gradle quali moduli deve includere durante la creazione dell'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 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. 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 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 tuo 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.1.0" apply false
    id("com.android.library") version "8.1.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.1.0' apply false
    id 'com.android.library' version '8.1.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.20' apply false
}