套用自訂建構邏輯
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本節說明當您想要擴充 Android Gradle 外掛程式或自行編寫外掛程式時實用的進階主題。
將變化版本依附元件發布至自訂邏輯
程式庫具有可供其他專案或子專案使用的功能。發布程式庫是提供程式庫給消費者的過程。程式庫可控管消費者在編譯時間和執行階段期間可存取哪些依附元件。
有兩種不同的設定會沿用每個類別路徑的遞移依附元件,讓消費者必須依下列說明使用程式庫:
variant_nameApiElements
:這項設定會沿用消費者在編譯期間可用的遞移依附元件。
variant_nameRuntimeElements
:這項設定會沿用執行階段提供給消費者的遞移依附元件。
如要進一步瞭解不同設定之間的關係,請參閱「Java 程式庫外掛程式設定」。
自訂依附元件解決策略
專案可能包含相同程式庫中兩個不同版本的依附元件,進而產生依附元件衝突。舉例來說,假使專案依附了模組 A 的第 1 版和模組 B 的第 2 版,而 A 模組間接仰賴模組 B 的第 3 版,則會產生依附元件版本衝突。
為解決這項衝突,Android Gradle 外掛程式採用下列依附元件解決方案:當外掛程式檢測到同一個模組的不同版本在依附元件圖形中時,根據預設,會選擇版本編號最高的那個。
然而,這項策略不一定每次都能如預期運作。如要自訂依附元件解決策略,請使用下列設定來解決工作需要的某個變數的特定依附元件:
variant_nameCompileClasspath
:此設定包含特定變數的編譯類別路徑的解析度策略。
variant_nameRuntimeClasspath
:此設定包含特定變數執行階段類別路徑的解析度策略。
您可透過 Android Gradle 外掛程式取得 getter,以便存取每個變數的設定物件。因此,您可以使用 Variant API 來
查詢依附元件解析,如以下範例所示:
Kotlin
android {
applicationVariants.all {
// Return compile configuration objects of a variant.
compileConfiguration.resolutionStrategy {
// Use Gradle's ResolutionStrategy API
// to customize how this variant resolves dependencies.
...
}
// Return runtime configuration objects of a variant.
runtimeConfiguration.resolutionStrategy {
...
}
// Return annotation processor configuration of a variant.
annotationProcessorConfiguration.resolutionStrategy {
...
}
}
}
Groovy
android {
applicationVariants.all { variant ->
// Return compile configuration objects of a variant.
variant.getCompileConfiguration().resolutionStrategy {
// Use Gradle's ResolutionStrategy API
// to customize how this variant resolves dependencies.
...
}
// Return runtime configuration objects of a variant.
variant.getRuntimeConfiguration().resolutionStrategy {
...
}
// Return annotation processor configuration of a variant.
variant.getAnnotationProcessorConfiguration().resolutionStrategy {
...
}
}
}
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[null,null,["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Apply custom build logic\n\nThis section describes advanced topics that are useful when you want to extend\nthe Android Gradle plugin or write your own plugin.\n\nPublish variant dependencies to custom logic\n--------------------------------------------\n\nA library can have functionalities that other projects or sub-projects might\nwant to use. Publishing a library is the process by which the library is made\navailable to its consumers. Libraries can control which dependencies its\nconsumers have access to at compile time and runtime.\n\nThere are two separate configurations that hold the transitive dependencies of\neach classpath which must be used by consumers to consume the library as\ndescribed below:\n\n- \u003cvar translate=\"no\"\u003evariant_name\u003c/var\u003e`ApiElements`: This configuration holds the transitive dependencies that are available to consumers at compile time.\n- \u003cvar translate=\"no\"\u003evariant_name\u003c/var\u003e`RuntimeElements`: This configuration holds the transitive dependencies that are available to consumers at runtime.\n\nTo learn more about the relationships between the different configurations,\ngo to [The Java Library\nplugin configurations](https://docs.gradle.org/current/userguide/java_library_plugin.html#s\nec:java_library_configurations_graph).\n\nCustom dependency resolution strategies\n---------------------------------------\n\nA project may include a dependency on two different versions of the same library\nwhich can lead to dependency conflicts.\nFor example, if your project depends on version 1 of module A and version 2 of\nmodule B, and module A transitively depends on version 3 of module B,\nthere arises a dependency version conflict.\n\nTo resolve this conflict, the Android Gradle plugin uses the following\ndependency resolution strategy: when the plugin detects that different versions\nof the same module are in the dependency graph, by default, it chooses the one\nwith the highest version number.\n\nHowever, this strategy might not always work as you intend. To customize the\ndependency resolution strategy, use the following configurations to\nresolve specific dependencies of a variant that are needed for your task:\n\n- \u003cvar translate=\"no\"\u003evariant_name\u003c/var\u003e`CompileClasspath`: This configuration contains the resolution strategy for a given variant's compile classpath.\n- \u003cvar translate=\"no\"\u003evariant_name\u003c/var\u003e`RuntimeClasspath`: This configuration contains the resolution strategy for a given variant's runtime classpath.\n\nThe Android Gradle plugin includes getters that you can use to access the\nconfiguration objects of each variant. Thus, you can use the variant API to\nquery the dependency resolution as shown in the example below: \n\n### Kotlin\n\n```kotlin\nandroid {\n applicationVariants.all {\n // Return compile configuration objects of a variant.\n compileConfiguration.resolutionStrategy {\n // Use Gradle's https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html\n // to customize how this variant resolves dependencies.\n ...\n }\n // Return runtime configuration objects of a variant.\n runtimeConfiguration.resolutionStrategy {\n ...\n }\n // Return annotation processor configuration of a variant.\n annotationProcessorConfiguration.resolutionStrategy {\n ...\n }\n }\n}\n```\n\n### Groovy\n\n```groovy\nandroid {\n applicationVariants.all { variant -\u003e\n // Return compile configuration objects of a variant.\n variant.getCompileConfiguration().resolutionStrategy {\n // Use Gradle's https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html\n // to customize how this variant resolves dependencies.\n ...\n }\n // Return runtime configuration objects of a variant.\n variant.getRuntimeConfiguration().resolutionStrategy {\n ...\n }\n // Return annotation processor configuration of a variant.\n variant.getAnnotationProcessorConfiguration().resolutionStrategy {\n ...\n }\n }\n}\n```"]]