I m having trouble consuming a library using single variant

Question

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 · Answer

Error output ``` gt Task app checkDebugClasspath FAILED FAILURE Build failed with an exception What went wrong Could not resolve all files for configuration app debugCompileClasspath gt Could not resolve com example AndroidLibraryDemo 0 0 1 Required by project app gt 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 · Answer

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

h0tk3y · Answer

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 · Answer

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 · Answer

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 · Answer

< 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 · Answer

So yes a valid workaround for now is ``` android buildTypes debug matchingFallbacks = release ```

h0tk3y · Answer

This will definitely get documented unless fixed in 1 3 20

russhwolf · Answer

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