Configura la tua build

Il sistema di compilazione di Android compila le risorse dell'app, il codice sorgente e i pacchetti in APK o Android App Bundle che puoi testare, implementare, firmare distribuire.

Android Studio utilizza Gradle, un toolkit di creazione avanzato, per automatizzare e gestire il processo di creazione, permettendoti di definire configurazioni di build. Ogni configurazione di compilazione può definire il proprio set di codice e risorse, riutilizzando le parti comuni a tutte le versioni dell'app. Il plug-in Android per Gradle funziona con il toolkit di creazione per fornire processi e impostazioni configurabili specifiche per la creazione e il test App per Android.

Gradle e il plug-in Android Gradle vengono eseguiti indipendentemente da Android Studio. Questo puoi creare le tue app Android da Android Studio, dalla riga di comando della tua macchina o su quelli in cui Android Studio come i server di integrazione continua.

Se non utilizzi Android Studio, puoi scoprire come creare ed eseguire un'app la riga di comando. L'output della build è lo stesso indipendentemente dal fatto che creando un progetto dalla riga di comando, su una macchina remota Android Studio.

Nota:poiché Gradle e il plug-in Android Gradle vengono eseguiti indipendentemente 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 Gradle.

La flessibilità del sistema di build Android consente di creare creare configurazioni senza modificare i file di origine principali dell'app. Questo pagina ti aiuta a capire come funziona il sistema di compilazione di Android e come può aiutarti a personalizzare e automatizzare più configurazioni di build. Se Per saperne di più sul deployment della tua app, consulta l'articolo Creare ed eseguire un'app. Per iniziare a creare modelli creare subito le configurazioni usando Android Studio, vedi Configurare la build delle varianti.

Il processo di compilazione

Il processo di compilazione coinvolge molti strumenti e processi che convertono il tuo progetto in un Android Application Package (APK) o Android App Bundle (AAB).

Il plug-in Android per Gradle svolge gran parte del processo di compilazione per te, ma può essere utile per comprendere alcuni aspetti del processo di compilazione in modo da poter per soddisfare i tuoi requisiti.

Progetti diversi possono avere obiettivi di build diversi. Ad esempio, la creazione di un una libreria di terze parti produce Android Archive (AAR) o Java Archive (JAR) librerie. Tuttavia, un'app è il tipo più comune di progetto e la creazione di un'app produce un APK o AAB di debug o di rilascio della tua app che puoi implementare, oppure rilasciarle agli utenti esterni.

Questa pagina è incentrata sullo sviluppo di app, ma molti dei passaggi e dei concetti di build sono comuni alla maggior parte dei tipi di build.

Glossario di Android Build

Gradle e il plug-in Android Gradle ti consentono di configurare i seguenti aspetti della tua build:

Tipi di build

I tipi di build definiscono determinate proprietà utilizzate da Gradle durante la creazione e pacchettizzando l'app. I tipi di build sono in genere configurati 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 la tua app con una release chiave 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 dei pacchetti per la tua app, scopri come per configurare build di classificazione.

Sapori del prodotto
I sapori dei prodotti rappresentano versioni diverse della tua app che puoi per gli utenti, ad esempio le versioni senza costi e a pagamento. Puoi personalizzare versioni dei prodotti per utilizzare codice e risorse differenti durante la condivisione e riutilizzare le parti comuni a tutte le versioni dell'app. Prodotto I gusti sono facoltativi e devi crearli manualmente. Per iniziare a creare diverse versioni dell'app, scopri come configurare sapori dei prodotti.
Varianti della build
Una variante di build è un prodotto incrociato tra tipo di build e versione di prodotto. è 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 versioni con release firmate delle versioni dei tuoi prodotti da distribuire. Anche se non configuri direttamente le varianti di build, devi configurare i tipi di creazione e le varianti di prodotto che li compongono. Creazione build aggiuntiva in corso... di tipo o sapore dei prodotti creano anche altre varianti della build. Per ulteriori informazioni su come creare e gestire le varianti di build, leggi l'articolo Configurare le varianti di build. panoramica.
Voci del file manifest
Puoi specificare i valori per alcune proprietà del file manifest nella build configurazione delle varianti. Questi valori di build sostituiscono i valori esistenti in del file manifest. Ciò è utile se vuoi generare più varianti della tua app con un altro nome, una versione minima dell'SDK o un altro nome versione SDK target. Se sono presenti più manifest, strumento di unione unisce le impostazioni del file manifest.
Dipendenze
Il sistema di compilazione gestisce le dipendenze del progetto dal file system locale e da repository remoti. Ciò significa che non devi manualmente cercare, scaricare e copiare pacchetti binari delle tue dipendenze della directory di un progetto. Per ulteriori informazioni, consulta la sezione Aggiungere build delle dipendenze.
Firma
Il sistema di compilazione consente di specificare le impostazioni di firma nella build e può firmare automaticamente l'app durante la creazione e il processo di sviluppo. Il sistema di compilazione firma la versione di debug con una chiave predefinita e utilizzando credenziali note per evitare la richiesta di password in fase di build nel tempo. Il sistema di compilazione non firma la versione della release a meno che tu definire in modo esplicito una configurazione di firma per questa build. In caso contrario avere una chiave di rilascio, puoi generarne una come descritto nella sezione Firmare l'app. Build di release firmate sono necessarie per la distribuzione di app tramite la maggior parte degli store.
Riduzione del codice e delle risorse
Il sistema di compilazione consente di specificare un file di regole ProGuard diverso per ciascuna variante della build. Quando crea la tua app, il sistema di compilazione applica l'insieme di regole appropriato per ridurre il codice e le risorse usando gli strumenti integrati di riduzione 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 diversi APK che ciascuna contiene solo il codice e le risorse necessarie per una specifica densità di schermo o ABI (Application Binary Interface). Per ulteriori informazioni, vedi Crea più APK. Tuttavia, il rilascio di un singolo AAB l'approccio consigliato, in quanto offre la suddivisione per lingua, oltre a densità dello schermo e ABI, evitando la necessità di caricare più elementi in Google Play. Tutte le nuove app inviate dopo agosto 2021 per l'uso degli AAB.

Versioni Java nelle build di Android

Che il codice sorgente sia scritto in Java, Kotlin o entrambi, è necessario scegliere un linguaggio JDK o Java, per la tua build. Vedi Versioni Java nelle build di Android per maggiori dettagli.

Creare file di configurazione

Per creare configurazioni di build personalizzate devi apportare modifiche a uno o più file di configurazione di compilazione. Questi utilizzano un linguaggio specifico del dominio (DSL, Domain Specific Language) per descrivere e e manipolare la logica di build Script Kotlin, che è un sapore della lingua kotlin. Puoi anche utilizzare Groovy, che è un per la Java Virtual Machine (JVM), per configurare le tue build.

Non è necessario conoscere lo script Kotlin o Groovy per iniziare perché 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 l'articolo documentazione di riferimento DSL. Lo script Kotlin si basa anche sul sottostante Gradle Kotlin DSL.

Quando avvii un nuovo progetto, Android Studio crea automaticamente alcuni questi file per te e li compila in base a valori predefiniti appropriati. Il 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 struttura di progetto standard per un'app per Android. Prima di iniziare configurazione della build, è importante comprenderne l'ambito e lo scopo di ciascuno di questi file e degli elementi DSL di base che definiscono.

Il file Gradle Wrapper

Il wrapper Gradle (gradlew) è una piccola applicazione inclusa nel tuo codice sorgente che scarica e avvia Gradle stesso. Ciò consente un'esecuzione della build più coerente. Gli sviluppatori scaricano ed eseguire gradlew. Questa operazione scarica il Gradle richiesto e avvia Gradle per creare la tua applicazione.

Il file gradle/wrapper/gradle-wrapper.properties contiene una proprietà, distributionUrl, che descrive la versione Gradle viene utilizzato 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) oppure settings.gradle (per Groovy DSL) si trova nella directory principale della directory di un progetto. Questo file di impostazioni definisce il repository a livello di progetto impostazioni e indica a Gradle quali moduli deve includere durante la creazione dell'app. I progetti multimodulo devono specificare ogni modulo che deve essere la 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")

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. 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) oppure build.gradle (per Groovy DSL) si trova nella directory principale della directory di un progetto. In genere definisce le versioni comuni dei plug-in utilizzati per moduli nel tuo progetto.

Il seguente esempio di codice descrive le impostazioni predefinite e gli elementi DSL in lo script di build di primo livello dopo aver creato 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.6.0" apply false
    id("com.android.library") version "8.6.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.23" 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 '8.6.0' apply false
    id 'com.android.library' version '8.6.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}