Mit Publikationsvarianten können Sie die Nutzung für Ihre Nutzer personalisieren. Wenn Sie Publikationsvarianten konfigurieren, können Sie verschiedene Build-Varianten mit jeweils eigenen Attributen.
Wenn Sie mehrere Build-Varianten Ihrer Bibliothek veröffentlichen, können Nutzer geeignete Funktionen zu finden. Sie können beispielsweise verschiedene Artefakte für die Fehlersuche im Vergleich zu Release Build-Typen. Das Debug-Publikationsartefakt enthält möglicherweise zusätzlichen Logging-Code und verschiedene Abhängigkeiten, um dieses zusätzliche Logging zu ermöglichen.
Bevor Sie fortfahren, müssen Sie Mediathek für die Veröffentlichung vorbereiten.
Metadaten des Gradle-Moduls verwenden
Um Varianten Ihrer Bibliothek zu veröffentlichen, müssen Sie Gradle Module Metadata (GMM). GMM beschreibt Ihre Publikation und verwaltet Variantenbewusste Abhängigkeitsverwaltung GMM wird standardmäßig mit Ihrer Bibliothek veröffentlicht.
Zu den Vorteilen von Google Maps Mobile gehören:
- Wenn Sie GMM mit Gradle 6.0 oder höher verwenden, können Sie mehrere Publikationen veröffentlichen Varianten oder mehreren Artefakten – jedes mit eigenen Attributen und Abhängigkeiten. Bei Verwendung der POM-Datei von Maven kannst du nur ein Artefakt veröffentlichen. Wenn Sie eine POM-Datei verwenden, können zusätzliche Artefakte mithilfe von Klassifikatoren veröffentlichen, aber die zusätzlichen Artefakte keine eigenen Abhängigkeiten haben.
- Gradle erstellt automatisch eine Variante für die Kompilierung und eine für die Laufzeit,
jede mit ihren eigenen Abhängigkeiten. Sie können eine Variante zur Kompilierung veröffentlichen
und eines für die Laufzeit, sodass der Nutzer je nach
Ihre Bibliothek. GMM zeigt verschiedene Abhängigkeiten für Kompilierungs- und
Laufzeit basierend auf der Nutzung von
api
,implementation
odercompileOnly
/runtimeOnly
. Weitere Informationen finden Sie unter Abhängigkeitskonfigurationen um eine vollständige Liste der Abhängigkeiten zu erhalten. Dies ist auch dann möglich, wenn du eine Single veröffentlichst Publikationsvariante. - Wenn du Test-Displays verwendest, kannst du eine zusätzliche Variante mit speziellen Metadaten oder Funktionen mit denen der Nutzer sie auswählen konnte. Dies ist auch dann verfügbar, wenn Sie einer Publikationsvariante.
Publikationsvarianten verstehen
Um zu verstehen, wie Publikationsvarianten funktionieren, ist es hilfreich, Gradles grundlegende Schritte zur Veröffentlichung. Hier einige Schlüsselkonzepte der Veröffentlichung:
- Build-Variante: Die Konfiguration, mit der Gradle Ihre Bibliothek erstellt. ist das übergreifende Produkt aus Build-Typ und Produktgeschmack. Weitere Informationen finden Sie in der Android-Build-Glossar
- Artefakt: Eine Datei oder ein Verzeichnis, die bzw. das von einem Build erzeugt wird. Im Zusammenhang mit der Veröffentlichung von Büchern ist normalerweise eine JAR- oder AAR-Datei.
- Publikationsvariante: Ein Artefakt mit den zugehörigen Attributen, Merkmalen und Abhängigkeiten. Hinweis das Gradle als variants der Publikationsvarianten bezeichnet. Sie werden jedoch als Publikationsvarianten in diesen Dokumenten beschrieben, um sie von Build-Varianten
- Attribut:
Gradle verwendet Attribute, um Publikationsvarianten zu identifizieren und auszuwählen, wenn
gibt es mehrere Optionen. Beispiel:
org.gradle.usage=java-api
undorg.gradle.jvm.version=11
sind Variantenattribute. - Softwarekomponente:
Ein Gradle-Objekt, das eine oder mehrere Publikationsvarianten enthalten kann und veröffentlicht ist
in einen einzelnen Satz von Maven-Koordinaten (
groupdId:artifactId:version
). Es ist in Gradle DSL überProject.getComponents()
- Veröffentlichung:
Was im Repository veröffentlicht wird und von Nutzern verwendet wird. Publikationen bestehen aus
einer Softwarekomponente und ihrer Metadaten, z. B. ihrer Identität,
(
groupId:artifactId:version
)
Mit dem Android-Gradle-Plug-in (AGP) 7.1
Domainspezifische Sprache (Domain-specific Language,DSL), mit der gesteuert wird, welche Build-Varianten während
und welche nicht. Mit DSL können Sie Instanzen von
SoftwareComponent
, die eines der folgenden Elemente enthalten:
- Eine Publikationsvariante aus einer Build-Variante
- Mehrere Publikationsvarianten aus mehreren Build-Varianten
Beim Erstellen einer Softwarekomponente mit mehreren Publikationsvarianten legt AGP fest für jede Variante hoch, anhand derer der Nutzer die passende Variante. Diese Attribute stammen direkt aus dem Build den Typ und die Geschmacksrichtungen, mit denen die Build-Variante erstellt wurde. Ein Komponente mit einer einzigen Publikationsvariante erfordern keine Attribute, ist es nicht nötig, zu unterscheiden.
Softwarekomponente mit einer einzelnen Publikationsvariante erstellen
Mit dem folgenden Snippet wird eine Softwarekomponente mit einer einzelnen Publikation konfiguriert
aus der Build-Variante release
erstellt und die Quell-JAR-Datei als
sekundäres Artefakt:
Kotlin
android { publishing { singleVariant("release") { withSourcesJar() } } }
Cool
android { publishing { singleVariant('release') { withSourcesJar() } } }
Sie können mehrere Komponenten mit jeweils einer Publikationsvariante erstellen.
unter verschiedenen Maven-Koordinaten verteilen. In diesem Fall werden Attribute
nicht für die Publikationsvariante festgelegt sind. Sie können nicht erkennen, dass diese Publikation
Variante ist aus der Build-Variante release
(siehe Publikation)
Metadaten. Da nur eine Publikationsvariante beteiligt ist, ist keine
zur Begriffsklärung.
Softwarekomponente mit mehreren Publikationsvarianten erstellen
Sie können alle oder einen Teil der Build-Varianten auswählen und in eine einzelne Software einfügen Komponente. AGP verwendet automatisch die Namen der Build-Typen, sowie Namen von Dimensionen für Geschmacksrichtungen, um Attribute zu erstellen, damit die zwischen ihnen unterscheiden können.
Wenn Sie alle Build-Varianten in einer einzigen Komponente veröffentlichen möchten, geben Sie allVariants()
an
im multipleVariants{}
-Block der Datei build.gradle
auf Modulebene:
Kotlin
android { publishing { multipleVariants { allVariants() withJavadocJar() } } }
Cool
android { publishing { multipleVariants { allVariants() withJavadocJar() } } }
Dadurch wird eine einzelne Komponente mit dem Namen default
erstellt. So benennen Sie Ihre Komponente:
oder etwas anderes, verwenden Sie multipleVariants({name})
.
In diesem Fall werden alle Build-Typ-
und Produkt-Geschmacksdimensionen
Attribute.
Sie können auch festlegen, welche Varianten veröffentlicht werden, indem Sie
includeBuildTypeValues()
und includeFlavorDimensionAndValues()
:
Kotlin
android { publishing { multipleVariants("custom") { includeBuildTypeValues("debug", "release") includeFlavorDimensionAndValues( dimension = "color", values = arrayOf("blue", "pink") ) includeFlavorDimensionAndValues( dimension = "shape", values = arrayOf("square") ) } } }
Cool
android { publishing { multipleVariants('custom') { includeBuildTypeValues('debug', 'release') includeFlavorDimensionAndValues( /*dimension =*/ 'color', /*values =*/ 'blue', 'pink' ) includeFlavorDimensionAndValues( /*dimension =*/ 'shape', /*values =*/ 'square' ) } } }
In diesem Beispiel enthält die benutzerdefinierte Komponente alle Kombinationen von
(debug
, release
) für den Build-Typ, (blue
, pink
) für die Dimension color
,
und (square
) für die Dimension shape
.
Alle Flavor-Dimensionen müssen aufgelistet werden, auch wenn Sie nur einen Wert veröffentlichen aus einer Dimension auswählen, damit AGP weiß, welcher Wert für jede Dimension verwendet werden soll.
In der folgenden Tabelle sind die resultierenden Publikationsvarianten und ihre zugehöriger Attribute.
Variante | Attribute |
---|---|
blueSquareDebug | com.android.build.api.attributes.BuildTypeAttr ="debug"
com.android.build.api.attributes.ProductFlavorAttr:color ="blue" |
blueSquareRelease |
com.android.build.api.attributes.BuildTypeAttr="release"
|
pinkSquareDebug |
com.android.build.api.attributes.BuildTypeAttr="debug"
|
pinkSquareRelease |
com.android.build.api.attributes.BuildTypeAttr="release"
|
In der Praxis werden mehr Varianten veröffentlicht. Beispiel:
Jede der oben genannten Varianten wird zweimal veröffentlicht, einmal für die Kompilierung und einmal für die
mit unterschiedlichen Abhängigkeiten (je nachdem, ob die deklarierten Abhängigkeiten
Verwenden Sie implementation
oder api
) und mit einem anderen Wert für das Attribut
org.gradle.Usage
Die Artefakte (AAR-Datei) für diese beiden Varianten
ist das Gleiche.
Weitere Informationen finden Sie in der
publishing
API-Dokumentation.
Kompatibilitätsproblem bei der Veröffentlichung von Multi-Flavor-Bibliotheken
Ein Projekt mit AGP 7.0 oder niedriger kann keine veröffentlichten Multi-Flavor-Bibliotheken nutzen
mit AGP 7.1 oder höher. Dies ist ein bekanntes Problem, das durch eine Änderung des Attributs verursacht wird
Name der Dimension „Produktgeschmack“ von dimensionName
bis
com.android.build.api.attributes.ProductFlavor:dimensionName
in AGP 7.1.
Je nach Projekteinrichtung können Sie missingDimensionStrategy
in
der alten API funktioniert,
zu diesem Thema.
Angenommen, Ihr Anwendungsprojekt enthält nur ein Versionsprodukt Flavor-Dimension:
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)
}
}
Cool
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)
}
}