In a project with stable compose multiplatform tes...

# compose

[AndrewStone]

In a project with stable compose multiplatform tests, a month or so ago all the android compose tests started failing with:
java.lang.RuntimeException: Intent in process X resolved to different process X.test: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10008000 cmp=X.test/androidx.activity.ComponentActivity }
at android.app.Instrumentation.startActivitySync(Instrumentation.java:509)

These same tests are running fine on our JVM (desktop) platform. I've done a lot of googling, AI querying, etc. and its not helping. My merged AndroidManifest does not have any android:process tags, suggestions to explicitly annotate the test classes do not work in KMP, and a conversation about the same problem here 2 years ago did not help. Has anyone seen this or have an idea what may have caused it?

[Rey (Kingg22)]

Can attach the test code? how you run your test and build config? That may help understand and help you.

[Jack Boswell]

Do you have an application id prefix for your test variant? I think you have both your test and your main variant installed, and you're not launching an explicit intent so it matches both packages

[AndrewStone]

No its a big project. Its open source though, so you can see the failure here: https://gitlab.com/wallywallet/wallet/-/jobs/11631659972

[AndrewStone]

WRT an "application id prefix" I'm familiar with the android applicationId but I don't know what you mean by prefix. I definitely have both the test and main variant installed. So are you saying that the entire app when its under test is running as appid: ${applicationId}.test, so if I created my own intent I would have to know this and target it to a different name? Basically you are guessing that my own code was launched as X.test and when it launches an intent to itself it just launches to X? That is very possible.

[Jack Boswell]

My bad I meant suffix - you can configure a suffix for variants, such that the system sees them as unique applications and let's you install them side by side

[AndrewStone]

I've dug into this a LOT, and I haven't even seen anything that claims that what I was doing should have ever worked. I was basically using my standard multiplatform tests under Android. These tests launch using runComposeUiTest. When I do that, its runComposeUiTest itself that fails. My composable is never called. And dumping the process name before calling that function shows that IDEA or gradle launched my tests under ${applicationId}, NOT ${applicationId}.test. So runComposeUiTest is launching an intent into ${applicationId}.test (but it is running as ${applicationId}), so fail.

Many sites/AIs I use actually say that runComposeUiTest does not work at all for android. So maybe it was just a bug that it ever worked?

It sucks to not be able to run my GUI unit tests any more. However, if I create an androidInstrumentedTest directory and use the " @get:Rule val composeRule = CreateAndroidComposeRule..." technique, then I can run an activity under Android. This at least will allow me to create and run a system-level test for Android.