getDependencies task prints enormous amount of AmbiguousVariantSelectionException

[entibaldi]

Describe the bug
Running :app:getDependencies task on our Android project (with 26 gradle modules) takes minutes and prints an enormous amount of AmbiguousVariantSelectionException for each of our library modules, resulting in 150+ MB of text logs.
Using AGP 7.0.2

Expected behavior
Correctly handle local library modules

Example log

Failed to process <app id>:<module name>:1.0.0-SNAPSHOT
org.gradle.internal.component.AmbiguousVariantSelectionException: The consumer was configured to find an API of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'store' with value 'playstore', attribute 'brand' with value 'suunto', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm'. However we cannot choose between the following variants of project :<module name>:
Configuration ':<module name>:releaseApiElements' variant android-aidl declares an API of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm':
      - Unmatched attributes:
          - Provides attribute 'artifactType' with value 'android-aidl' but the consumer didn't ask for it
          - Doesn't say anything about brand (required 'suunto')
          - Provides attribute 'com.android.build.gradle.internal.attributes.VariantAttr' with value 'release' but the consumer didn't ask for it
          - Doesn't say anything about its target Java environment (preferred optimized for Android)
          - Doesn't say anything about store (required 'playstore')

Desktop

• Gradle version: 7.0.2
• AGP: 7.0.2
• Android Studio version: Android Studio Arctic Fox | 2020.3.1 Patch 2
• Plugin name and version: plugin 0.10.4, oss lib 17.0.0

[kuuuurt]

Will there be an update here? The logs eat up all the logging and if there's an issue, I have to disable the plugin so I can read the message..

[zayo]

I'll offer a workaround I just invent. Not a solution for every log, but at least reduction of them.
Simply replace

implementation(project(":module")) 

with

implementation(project(":module", "default"))

It will not require modules to have defined flavors the same your main application does and it will match them regardless of requested configuration.
I'm not 100% sure this is suitable solution for flavored/partially flavored modules, but for the basic ones it helps a bit.

PS: pontential solution is to also define all flavors for all modules.

EDIT: Seems this has an issues with aapt when modules defines some resources/attrs, so probably defining flavors in modules is a prefered way. In our case, we've just excluded that task from building and keeping it only for production builds.

[kaidotarma]

Unfortunately, @zayo 's workaround didn't help us.

Fortunately, this task isn't always needed and can be excluded from the task that originally depends on it, for example:
gradlew someTask -x getDependencies -x generateLicenses
This command also excludes generateLicenses, which depends on getDependencies.

This doesn't fix the root issue, only mitigates some of the cases (where we don't really need this task). Hope that it will get fixed soon, our build logs are currently littered with unnecessary warnings.

[Kanialdo]

Look here: #137 - this problem was reported Apr 20, 2020 - 1.5 year ago

[mrmike]

Another workaround is to use different library like this one. It's not the perfect solution but migration isn't difficult and after migration logs are finally not cluttered.