Hi all! I’ve used kotlin dsl to set up convention ...

# gradle

[tankistorep]

Hi all!
I’ve used kotlin dsl to set up convention plugins for my multi-module app, pretty much following what the nowinandroid app has done. But I keep getting this error any time I change any code in the plugins module, or if I do a clean build:

Cause: loader constraint violation in interface itable initialization for class com.android.build.gradle.internal.api.VariantFilter

Strangely, what makes it temporarily go away is doing a build with --scan, but I have no idea what causes it, especially because I’m not using variant filters. More details about the error + setup in thread.

[tankistorep]

This is the only code that sets up the flavours:

enum class Flavor(val id: String) {
    Foo("foo"),
    Bar("bar"),
    Foobar("foobar"),
    ;
}

internal fun configureFlavors(
    commonExtension: CommonExtension<*, *, *, *>,
    flavorConfigurationBlock: ProductFlavor.(flavor: Flavor) -> Unit = {}
) {
    val myDimension = "environment"
    commonExtension.apply {
        flavorDimensions.add(myDimension)

        productFlavors {
            Flavor.values().forEach { flavor ->
                create(flavor.id) {
                    dimension = myDimension
                    flavorConfigurationBlock(this, flavor)
                    if (this@apply is ApplicationExtension && this is ApplicationProductFlavor) {
                        applicationIdSuffix = ".${flavor.id}"
                    }
                }
            }
        }
    }
}

Again, this is pretty much following exactly the nowinadroid app. This is called from the Application and Library convention plugin code

[tankistorep]

And this is the full error:

loader constraint violation in interface itable initialization for class com.android.build.gradle.internal.api.VariantFilter: when selecting method 'com.android.builder.model.BuildType com.android.build.api.variant.VariantFilter.getBuildType()' the class loader org.gradle.internal.classloader.VisitableURLClassLoader @d504be for super interface com.android.build.api.variant.VariantFilter, and the class loader org.gradle.internal.classloader.VisitableURLClassLoader @6ee373d4 of the selected method's class, com.android.build.gradle.internal.api.VariantFilter have different Class objects for the type com.android.builder.model.BuildType used in the signature (com.android.build.api.variant.VariantFilter is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @d504be, parent loader org.gradle.internal.classloader.CachingClassLoader @28f524f8; com.android.build.gradle.internal.api.VariantFilter is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @6ee373d4, parent loader org.gradle.internal.classloader.VisitableURLClassLoader @d504be)

[alex.krupa]

Hi, I just found your post here — I'm getting the same issue occasionally.

I haven't found a solution, the workaround I use is just killing Gradle daemons with ./gradlew --stop.

[alex.krupa]

The problem might not actually be directly caused by flavors because we don't have any in our app (only build types) and the problem still occurs

[tankistorep]

Hey, sorry I should’ve posted my findings for this a few weeks ago - I managed to solve it for my use case, but I still don’t really know what was causing the issue.

I essentially started stripping down the app’s setup, and as you said, the issue isn’t caused by flavours as removing flavours from my app didn’t fix it. In the end, the issue was having both a buildSrc module and an included build module (build-logic). I moved everything to be just in build-logic and haven’t seen the error since. Again, I’m not sure why this was causing an error (maybe some race condition?), and I’m not sure if it applies to you, but that’s what fixed it for me.

[alex.krupa]

That's great to read, thanks for letting me know!

[alex.krupa]

We actually do have buildSrc with convention plugins, we haven't moved everything because buildSrc just has some constants and minor utilities — haven't considered that this might be the culprit

[tankistorep]

Yeah that was pretty much the position I was in before - included build had all plugins, and buildSrc had a couple of util classes. Glad I could help, if anyone figures out the actual root cause, please do share!

[Balázs Varga]

I encountered the same issue after changing implementation('com.android.tools.build:gradle') to implementation('com.android.tools.build:gradle-api') in `buildSrc`’s build.gradle. Interestingly, the problem only manifested in Kotlin DSL modules, while everything worked fine with Groovy.

I found two potential solutions:
1. Roll back to using com.android.tools.build:gradle in buildSrc.
2. Add the following to the root build.gradle (previously omitted due to our use of version catalogs):

plugins {
    alias(libs.plugins.androidLibrary) apply false
}

I hope this helps someone facing similar issues!