Configurare le varianti di pubblicazione

Le varianti della pubblicazione ti consentono di creare un'esperienza più personalizzata per i tuoi utenti. Configurando le varianti della pubblicazione puoi pubblicare diverse varianti di build, ognuno con i suoi attributi.

La pubblicazione di più varianti di build della libreria consente all'utente di scegliere funzionalità più adatte alle loro esigenze. Ad esempio, puoi pubblicare diversi artefatti per il debug e release tipi di build. L'artefatto della pubblicazione di debug potrebbe avere codice di logging aggiuntivo e con dipendenze diverse per abilitare questo logging aggiuntivo.

Prima di procedere, assicurati di preparare la raccolta per la nuova uscita.

Utilizzare i metadati del modulo Gradle

Per pubblicare varianti della libreria, devi utilizzare GMM (Gradle Module Metadata). GMM descrive la tua pubblicazione e gestisce gestione delle dipendenze sensibile alle varianti. Per impostazione predefinita, GMM viene pubblicato con la tua raccolta.

I vantaggi dell'utilizzo di GMM includono:

• Se utilizzi GMM con Gradle 6.0 o versioni successive, puoi pubblicare più pubblicazioni varianti o più artefatti, ognuno con i propri attributi e dipendenze. Se utilizzi il file POM di Maven anziché GMM, puoi pubblicare un solo elemento. Se utilizzi un file POM, possono pubblicare altri artefatti utilizzando i classificatori, non possono avere dipendenze proprie.
• Gradle crea automaticamente una variante per la compilazione e una per il runtime, ciascuna con le proprie dipendenze. Potresti pubblicare una variante per la compilazione e una per il runtime, così il consumatore può scegliere in base a quando nella tua raccolta. GMM consente ai consumer di vedere dipendenze diverse per la compilazione in base all'utilizzo da parte della libreria pubblicata api, implementation o compileOnly/runtimeOnly. Consulta Configurazioni di dipendenza per un elenco completo delle dipendenze. È disponibile anche se pubblichi una singola e la variante della pubblicazione.
• Quando utilizzi impianti di prova, puoi pubblicare un'ulteriore variante con metadati abilità che consenta al consumatore di selezionarlo. È disponibile anche se pubblichi una singola variante della pubblicazione.

Informazioni sulle varianti di pubblicazione

Per capire come funzionano le varianti della pubblicazione, è utile avere familiarità con Di Gradle passaggi di base per la pubblicazione. Ecco alcuni concetti chiave della pubblicazione:

• Variante di build: la configurazione utilizzata da Gradle per creare la tua libreria, che è il prodotto incrociato tra tipo di build e sapore di prodotto. Per saperne di più, consulta Glossario di Android Build.
• Artefatto: Un file o una directory prodotto da una build. Nell'ambito della pubblicazione di biblioteche, un artefatto è solitamente un file JAR o AAR.
• Variante di pubblicazione: Un artefatto con attributi, funzionalità e dipendenze associati. Nota che Gradle chiama le varianti della pubblicazione. Tuttavia, sono chiamati varianti di pubblicazione in questi documenti per distinguerle dalle creare varianti.
• Attributo: Gradle utilizza gli attributi per identificare e selezionare le varianti della pubblicazione quando sono disponibili più opzioni. Ad esempio, org.gradle.usage=java-api e org.gradle.jvm.version=11 sono attributi delle varianti.
• Componente software: Un oggetto Gradle che può contenere una o più varianti di pubblicazione e che è pubblicato a un singolo insieme di coordinate Maven (groupdId:artifactId:version). È nel DSL di Gradle Project.getComponents().
• Pubblicazione: Che cosa viene pubblicato nel repository e utilizzato dai consumatori. Le pubblicazioni sono costituite di un componente software e i suoi metadati, ad esempio la sua identità (groupId:artifactId:version)

Il plug-in Android Gradle (AGP) 7.1 introduce una lingua specifica del dominio (DSL) per controllare quali varianti di build vengono utilizzate durante pubblicazione e che vengono ignorati. Il DSL consente di creare istanze SoftwareComponent che contengono uno dei seguenti elementi:

• Una variante di pubblicazione da una variante di build
• Diverse varianti di pubblicazione di diverse varianti di build

Quando si crea un componente software con più varianti di pubblicazione, AGP imposta attributi su ogni variante che consentono al consumatore di selezionare la variante appropriata di cui hanno bisogno. Questi attributi provengono direttamente tipo e gusti utilizzati per creare la variante build. La creazione di un componente con una singola variante di pubblicazione non richiede attributi perché non c'è bisogno di distinguerle.

Creare un componente software con una singola variante di pubblicazione

Il seguente snippet configura un componente software con una singola pubblicazione variante creata dalla variante di build release e aggiunge il JAR di origine come artefatto secondario:

Kotlin

android {
  publishing {
    singleVariant("release") {
        withSourcesJar()
    }
  }
}

Alla moda

android {
  publishing {
    singleVariant('release') {
        withSourcesJar()
    }
  }
}

Puoi creare diversi componenti, ciascuno con una singola variante di pubblicazione, e distribuirle con coordinate Maven diverse. In questo caso, gli attributi non sono impostate sulla variante della pubblicazione. Non puoi capire che questa pubblicazione la variante proviene dalla variante build release esaminando la pubblicazione metadati. Poiché viene coinvolta una sola variante della pubblicazione, non è necessario per facilitare la disambiguazione.

Creare un componente software con più varianti di pubblicazione

Puoi selezionare tutte o un sottoinsieme di varianti di build da inserire in un unico software di strumento di authoring. AGP utilizza automaticamente i nomi dei tipi di build e le versioni dei prodotti e nomi di dimensioni dei prodotti per creare attributi in modo che che consumano pochi progetti, siano in grado di distinguerli.

Per pubblicare tutte le varianti di build in un singolo componente, specifica allVariants() nel blocco multipleVariants{} nel file build.gradle a livello di modulo:

Kotlin

android {
  publishing {
    multipleVariants {
      allVariants()
      withJavadocJar()
    }
  }
}

Alla moda

android {
  publishing {
    multipleVariants {
      allVariants()
      withJavadocJar()
    }
  }
}

In questo modo viene creato un singolo componente denominato default. Assegna un nome al componente altro, usa multipleVariants({name}). In questo caso, tutte le dimensioni relative al tipo di build e alla versione del prodotto vengono utilizzate come attributi.

Puoi anche selezionare le varianti da pubblicare utilizzando includeBuildTypeValues() e includeFlavorDimensionAndValues():

Kotlin

android {
  publishing {
    multipleVariants("custom") {
      includeBuildTypeValues("debug", "release")
      includeFlavorDimensionAndValues(
        dimension = "color",
        values = arrayOf("blue", "pink")
      )
        includeFlavorDimensionAndValues(
          dimension = "shape",
          values = arrayOf("square")
      )
    }
  }
}

Alla moda

android {
  publishing {
    multipleVariants('custom') {
      includeBuildTypeValues('debug', 'release')
      includeFlavorDimensionAndValues(
        /*dimension =*/ 'color',
        /*values =*/ 'blue', 'pink'
      )
      includeFlavorDimensionAndValues(
        /*dimension =*/ 'shape',
        /*values =*/ 'square'
      )
    }
  }
}

In questo esempio, il componente personalizzato contiene tutte le combinazioni (debug, release) per tipo di build, (blue, pink) per la dimensione color, e (square) per la dimensione shape .

Devono essere elencate tutte le dimensioni versioni, anche se pubblichi un solo valore da una dimensione, in modo che AGP sappia quale valore utilizzare per ogni dimensione.

La tabella seguente elenca le varianti della pubblicazione risultanti e le relative attributi associati.

Nota: come specificato nel file di build, le varianti di build che utilizzano valori di shape diversi da square non sono inclusi nei pubblicazione. Per questo motivo, l'attributo della dimensione "Sapore di prodotto" shape non è incluso. Il consumatore non ha bisogno di selezionare un valore per questo . Per ulteriori informazioni su come Gradle dà la priorità ai sapori dei prodotti e quando assegni un nome alle varianti di build, consulta la sezione Combinare più versioni di prodotti. con dimensioni flavor.

Variante	Attributi
blueSquareDebug	com.android.build.api.attributes.BuildTypeAttr="debug" com.android.build.api.attributes.ProductFlavorAttr:color="blue"
blueSquareRelease	com.android.build.api.attributes.BuildTypeAttr="release" com.android.build.api.attributes.ProductFlavorAttr:color="blue"
pinkSquareDebug	com.android.build.api.attributes.BuildTypeAttr="debug" com.android.build.api.attributes.ProductFlavorAttr:color="pink"
pinkSquareRelease	com.android.build.api.attributes.BuildTypeAttr="release" com.android.build.api.attributes.ProductFlavorAttr:color="pink"

In pratica, vengono pubblicate altre varianti. Ad esempio, ciascuna delle varianti precedenti è pubblicata due volte, una per la compilazione e una per runtime, con dipendenze diverse (a seconda che le dipendenze dichiarate utilizza implementation o api) e con un valore diverso per l'attributo org.gradle.Usage. Tuttavia, gli artefatti (file AAR) di queste due varianti sono allo stesso modo.

Per ulteriori informazioni, consulta publishing documentazione dell'API.

Importante: quando pubblichi più varianti della pubblicazione, i nomi dei le dimensioni flavor e flavor dei prodotti diventano parte dell'API di pubblicazione. Quindi, che utilizzano nomi di versioni e dimensioni corrispondenti o utilizzare per aggiungi dipendenze per la build e selezionare manualmente l'elemento necessario. Per i tipi di build, poiché la dimensione sia integrato, solo i nomi dei tipi di build devono corrispondere oppure il progetto consumer deve usa anche i fallback.

Problema di compatibilità per la pubblicazione di librerie multiversione

Un progetto che utilizza AGP 7.0 o versioni precedenti non può utilizzare le librerie multi-versione pubblicate con AGP 7.1 o versioni successive. Si tratta di un problema noto causato da una modifica dell'attributo nome per la dimensione flavor del prodotto da dimensionName a com.android.build.api.attributes.ProductFlavor:dimensionName in AGP 7.1. A seconda della configurazione del progetto, puoi utilizzare missingDimensionStrategy in della vecchia API della variante per risolvere questo problema.

Ad esempio, supponiamo che il progetto dell'applicazione abbia solo un prodotto di versione dimensione sapore:

Kotlin

android {
    applicationVariants.forEach { variant ->
        val flavor = variant.productFlavors[0].name
        val attributePrefix = "com.android.build.api.attributes.ProductFlavor"
        val dimensionName = "version"
        variant.missingDimensionStrategy("$attributePrefix:$dimensionName", flavor)
    }
}

Alla moda

android {
    applicationVariants.forEach { variant ->
        def flavor = variant.getProductFlavors()[0].name
        def attributePrefix = "com.android.build.api.attributes.ProductFlavor"
        def dimensionName = "version"
        variant.missingDimensionStrategy("$attributePrefix:$dimensionName", flavor)
    }
}