I’m trying to add support for the new Android source set layout introduced in 1.8.0 and is running into a few problems running the code both as Unit and Instrumentation test. The problem I have is that my Android variant of the library contain code that only works on a device, not on JVM tests. I do have a JVM variant of the library that should work, but I cannot figure out how to include it just for the AndroidUnitTest source set. It looks something like this:

kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
            	// This will pull in library-base-android for both 
                // Android Unit Test and Instrumented Tests
                implementation("io.realm.kotlin:library-base:1.10.0-SNAPSHOT")

            }
        }

        val androidUnitTest by getting {
        	dependencies {
				// Here I need to override the library-base-android variant  
                // with the library-base-jvm dependency.        	
        	}
        }

        val androidInstrumentedTest by getting {
        	dependencies {
				// This should continue to use the library-base-android variant.
        	}
        }

    }	
}

Anyone have any idea on how to achieve this? 🤔 Can I make a release of the library with some metadata for the source set resolution to “just work” or is there some way to manipulate the Gradle depedency inside the the two different test closures?

There's a new API coming in Kotlin 1.9 that allows you to select which source set tree the

androidInstrumentedTest

and

androidUnitTest

source sets should be added to: https://kotlinlang.slack.com/archives/C3PQML5NU/p1682443478051419?thread_ts=1675016886.869689&cid=C3PQML5NU Note the API has been updated slightly since this post. You now call it directly from the

androidTarget()

declaration (which replaces the previous

android()

target declaration):

androidTarget {
    publishLibraryVariants("release")
    instrumentedTestVariant.sourceSetTree.set(SourceSetTree.test)
    unitTestVariant.sourceSetTree.set(SourceSetTree.unitTest)
}

You can check it out in the latest 1.9.0-Beta release: https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev/

I’m not 100% sure that will solve my use case? 🤔 The thing is that we want to allow users of our library to run tests on either JVM or Android as they see fit, and we also support pure android projects, not just multiplatform projects. As I understand the new API it “just” allows decoupling of unit tests from instrumentation tests? In our case the problem is that the Android target internally does some things based on

android.os.Build

(which is not available in the unit test variant), but our users shouldn’t care about that. We also load some native code, which behaves very different on Android devices vs. JVM. All of those things are kinda hidden for people right now because they just interact with the Multiplatform API, and it “just works” because the variant metadata allows Gradle to select the proper dependency based on the projet type. But the androidUnitTest is some sort of hybrid between Jvm and Android which makes it hard for libraries to handle (as far as I can tell). Not sure if that made sense?

Do you have tests specific to the

androidUnitTest

source set? Or just

commonTest

?

Well, right now I’m doing it for our own library tests, but ideally users of our library can use a similar approach in their code. But yes, right now people use the

android

or

jvm

publications we publish. The multiplatform plugin selects the right one automatically and pure android projects use the

-android

artifact directly. I suspect we need to do some gradle dependency substitution for pure android projects no matter what, but for multiplatform projects it would be nice if we could either release some artifact that

androidUniTest

would automatically pick or modify the gradle metadata some the

jvm

publication was chosen by

androidUnitTest

rather than the

android

publication.

Ok, I think I understand more now. So do you have tests specifically in

androidUnitTest

or are you just running

commonTest

tests?

Right now most of the tests are “pure” common tests with some tests for android, jvm, ios and macos respectively. So far that split has been done by us symlinking a “shared” package between the variants and then having platform tests outside that package. That worked fine

If Android unit tests do select the

jvm

attribute variant, I'd expect you should be able to declare the base artifact:

dependencies {
    implementation("lib")
}

And it would choose the

-android

variant for the main build and instrumented tests automatically, and then choose the

-jvm

variant for unit tests, if it does work this way. You could manually declare the variant for the unit tests:

dependencies {
    implementation("lib-android")
    testImplementation("lib-jvm")
}

In this case, it's forcing both onto the classpath and it should exclude the variant that doesn't match the platform attribute. If that's

jvm

for Android unit tests, then it should work as expected, just not sure if that's the case or not. (You should be able to do this similarly with multiplatform dependency declaration.)

Interesting, I haven’t tried that yet. Definitely worth a shot

I'm really curious what the outcome is, which platform gradle uses in this case. I want to test it now.

Thanks for looking into this. Looks like I have some more hacking to so tomorrow to see if there is a way around this.

You might ask in #gradle if there's a way to override the

org.gradle.jvm.environment

and

org.jetbrains.kotlin.platform.type

attributes that a source set selects variants on.

I managed to get this to work using dependency substitution:

configurations.all {
    // Ensure that androidUnitTest uses the Realm JVM variant rather than Android.
    if (name == "debugUnitTestRuntimeClasspath") {
        resolutionStrategy.dependencySubstitution {
            substitute(module("io.realm.kotlin:library-base:${Realm.version}")).using(
                module("io.realm.kotlin:library-base-jvm:${Realm.version}")
            )
            substitute(module("io.realm.kotlin:cinterop:${Realm.version}")).using(
                module("io.realm.kotlin:cinterop-jvm:${Realm.version}")
            )
        }
    }
}

And that will work fine for our internal tests, but is going to be pretty annoying for our external users. I’ll try to ask in #gradle and see if they have a better idea. Thanks for the hints 🙏

Awesome, good find. I suppose you could provide the code snippet via a gradle plugin, where it could be applied more easily to a project. Are the APIs 100% equal between the Android and JVM variants?

Yes, it is just the internals that are problematic