Status Update
Comments
l3...@gmail.com <l3...@gmail.com> #2 Restricted+
aa...@google.com <aa...@google.com>
je...@google.com <je...@google.com>
sp...@google.com <sp...@google.com>
sp...@google.com <sp...@google.com> #3
OP and +1's, please take a look at the following proposal and let us know if it would meet your needs.
Proposal:
Instead of exposing source set names, AGP could add APIs to support this specific use case. AGP would handle creating the configurations, etc.
interface AndroidComponentsExtension {
/**
* Adds a custom configuration for each source set.
*
* The [suffix] parameter determines the naming convention for the generated configurations.
* For example, if [suffix] is "custom", the generated configurations would be "custom",
* "debugCustom", "releaseCustom", "testCustom", etc.
*
* Under the hood, this API:
* 1. Creates a configuration for each source set.
* 2. Creates resolvable configurations for each component.
* 3. Ensures that each resolvable configuration extends the corresponding source set
* configurations.
*
* Each component's corresponding resolvable configuration can be accessed via
* [Component.getResolvableConfiguration].
*
* Example usage:
* ```kotlin
* androidComponents {
* addSourceSetConfigurations("foo")
* onVariants { variant ->
* val resolvableConfiguration = variant.getResolvableConfiguration("foo")
* variant.nestedComponents.forEach { component ->
* val nestedResolvableConfiguration =
* component.getResolvableConfiguration("foo")
* }
* }
* }
* ```
*
* @param suffix the suffix to append to the generated configuration names.
*/
@Incubating
fun addSourceSetConfigurations(suffix: String)
}
interface Component {
/**
* Access to the component's resolvable configuration corresponding to the source set
* configurations added via [AndroidComponentsExtension.addSourceSetConfigurations].
*
* Example usage:
* ```kotlin
* androidComponents {
* addSourceSetConfigurations("foo")
* onVariants { variant ->
* val resolvableConfiguration = variant.getResolvableConfiguration("foo")
* variant.nestedComponents.forEach { component ->
* val nestedResolvableConfiguration =
* component.getResolvableConfiguration("foo")
* }
* }
* }
* ```
*
* The returned [Configuration] should not be resolved until execution time.
*/
@Incubating
fun getResolvableConfiguration(sourceSetConfigurationsAffix: String): Configuration
}
Under the hood, AGP would (1) create configurations per source set, (2) create a resolvable configuration per component, and (3) make each resolvable configuration extend from the corresponding source set configurations.
Example Usage:
androidComponents {
addSourceSetConfigurations(suffix = "pluginDeps")
onVariants { variant ->
val variantResolvableConfiguration = variant.getResolvableConfiguration("pluginDeps")
// ...
variant.nestedComponents.forEach { component ->
val nestedResolvableConfiguration = component.getResolvableConfiguration("pluginDeps")
// ...
}
}
}
(Edited Jan 8th, 2025 to reflect final APIs)
sp...@google.com <sp...@google.com> #4
Please respond soon if the proposal in
Otherwise, we plan to implement it to unblock
ws...@gmail.com <ws...@gmail.com> #5
That works for me, thank you!
an...@google.com <an...@google.com> #7
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Meerkat | 2024.3.1 Canary 9
- Android Gradle Plugin 8.9.0-alpha09
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
wa...@gmail.com <wa...@gmail.com> #8
Genial
sp...@google.com <sp...@google.com> #9
FYI - for anyone trying this new API, see 8.9.0-rc01
and 8.10.0-alpha03
.
Description
DESCRIBE THE ISSUE IN DETAIL:
We are trying to write a gradle plugin that supports Android. We'd like to create one gradle dependency configuration per sourceset, and then have a resolvable configuration (and gradle tasks) per variant. To do this, we need to know which android sourceSets are used by each variant.
In the old AGP APIs, we could use
variant.sourceSets
, and then use the sourceSet names to find the corresponding dependency configurations.In the new AGP APIs, the source set names are not exposed from variants, so it's hard to determine which configurations should used by each variant. We have to hardcode some naming convention and determine the 'hierarchy' of configurations ourselves.
For example, our gradle plugin might define dependency configurations like
pluginDeps
(the 'main' sourceset),debugPluginDeps
,androidTestPluginDeps
,androidTestDebugPluginDeps
, ... for our users. Then, we would define tasks per variant / testVariant, so fordebug
we might have:myDebugTask
which uses dependencies frompluginDeps
anddebugPluginDeps
(of course, not directly but through a resolvable configuration)myAndroidTestDebugTask
which uses all ofpluginDeps
,debugPluginDeps
,androidTestPluginDeps
,androidTestDebugPluginDeps
, etc.We'd rather be able to use the existing logic in AGP, than have to hardcode all those rules of how configurations are named and used by variants.