I’m having trouble consuming a library using singl...

# multiplatform

[russhwolf]

I’m having trouble consuming a library using single-variant aar publishing in eap-100. See sample project at https://github.com/russhwolf/AndroidLibDemo

Here’s my process:
1. run ./gradlew clean build check publishToMavenLocal in root directory
2. run ./gradlew clean build check in app directory

If the library used publishAllLibraryVariants() this works fine, but if I do publishLibraryVariants("release") I get an error because the debug app build can’t figure out which library variant to use.

[russhwolf]

Error output:

> Task :app:checkDebugClasspath FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all files for configuration ':app:debugCompileClasspath'.
> Could not resolve com.example:AndroidLibraryDemo:0.0.1.
  Required by:
      project :app
   > Unable to find a matching configuration of com.example:AndroidLibraryDemo:0.0.1:
       - Configuration 'android-releaseApiElements':
           - Required com.android.build.api.attributes.BuildTypeAttr 'debug' and found incompatible value 'release'.
           - Found com.android.build.api.attributes.VariantAttr 'release' but wasn't required.
           - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
           - Found org.gradle.status 'release' but wasn't required.
           - Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
           - Required org.jetbrains.kotlin.platform.type 'androidJvm' and found compatible value 'androidJvm'.
       - Configuration 'android-releaseRuntimeElements':
           - Required com.android.build.api.attributes.BuildTypeAttr 'debug' and found incompatible value 'release'.
           - Found com.android.build.api.attributes.VariantAttr 'release' but wasn't required.
           - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
           - Found org.gradle.status 'release' but wasn't required.
           - Required org.gradle.usage 'java-api' and found incompatible value 'java-runtime'.
           - Required org.jetbrains.kotlin.platform.type 'androidJvm' and found compatible value 'androidJvm'.
       - Configuration 'metadata-api':
           - Found artifactType 'jar' but wasn't required.
           - Required com.android.build.api.attributes.BuildTypeAttr 'debug' but no value provided.
           - Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' but no value provided.
           - Found org.gradle.status 'release' but wasn't required.
           - Required org.gradle.usage 'java-api' and found incompatible value 'kotlin-api'.
           - Required org.jetbrains.kotlin.platform.type 'androidJvm' and found incompatible value 'common'.

[h0tk3y]

Thanks, I'll take a look at this and the below one.

[h0tk3y]

For this problem, I suppose the Android plugin doesn't set up the attribute compatibility rules in a way that would allow a debug configuration to consume a release variant of a library (and vice versa). Maybe we could check if the variants chosen for publishing are all release ones and then erase the build type attribute from the metadata. Until it's fixed, it may be necessary to publish both debug and release variants.

[h0tk3y]

Similarly, this may lead a custom build type defined along with debug and release (e.g. staging) to fail to consume a release variant if the latter is published with the attribute.

[russhwolf]

You might look at how the Android Gradle Plugin does variant-aware dependency management in traditional pure-android projects. I don't know much about it at the plugin source level but there's some developer documentation at https://developer.android.com/studio/build/dependencies#variant_aware.

[h0tk3y]

@russhwolf Uhm, well, according to that page, this behavior is as designed and should be solved by adding matchingFallbacks = ['release'] to the debug variant. However, I don't think it's good UX, so I'll still try to find out whether the release variant may be used as a default one.

[h0tk3y]

So yes, a valid workaround for now is:

android {
    buildTypes {
        debug {
        	matchingFallbacks = ['release']
        }
    }
}

[h0tk3y]

This will definitely get documented unless fixed in 1.3.20.

[russhwolf]

Haha well maybe I should have tried that myself then.

The Android UX is indeed that it grabs the release version by default. I was pointing to those docs more for the case of custom build types. But maybe the solution is to use matchingFallbacks = ['release'] by default if the developer doesn't provide anything there.