应用自定义构建逻辑
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本部分介绍的高级主题在您要扩展 Android Gradle 插件或编写自己的插件时很有用。
向自定义逻辑发布变体依赖项
库可以包含其他项目或子项目可能要使用的功能。发布库是向其消费者提供库的过程。库可以控制其消费者在编译时和运行时可访问的依赖项。
有两种不同的配置,它们包含每个类路径的传递依赖项,消费者为了使用相应库而必须使用这些依赖项,具体说明如下:
variant_nameApiElements
:此配置包含编译时消费者可使用的传递依赖项。
variant_nameRuntimeElements
:此配置包含消费者在运行时可使用的传递依赖项。
如需详细了解不同配置之间的关系,请参阅 Java 库插件配置。
自定义依赖项解析策略
一个项目可能会依赖于同一个库的两个不同版本,这样会导致依赖项冲突。例如,如果您的项目依赖于模块 A 的版本 1 和模块 B 的版本 2,而模块 A 以传递方式依赖于模块 B 的版本 3,则会出现依赖项版本冲突。
为了解决此冲突,Android Gradle 插件使用以下依赖项解析策略:当插件检测到依赖项关系图中存在同一模块的不同版本时,默认情况下,它会选择版本号最高的一个。
不过,此策略可能并不总是如您所愿。如需自定义依赖项解析策略,请使用以下配置解析任务所需的特定变体依赖项:
variant_nameCompileClasspath
:此配置包含适用于给定变体编译类路径的解析策略。
variant_nameRuntimeClasspath
:此配置包含适用于给定变体运行时类路径的解析策略。
Android Gradle 插件包含可用于访问每个变体的配置对象的 getter。因此,您可以使用变体 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 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):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```"]]