java.lang.NoSuchMethodError: No static method forceEnableAppTracing()V in class Landroidx/tracing/Trace

chestersek-kogan commented 3 days ago

Description

Our project's Dependabot detected some new versions of the dependency updates related to AndroidX.test, but most of the updates came with this error "java.lang.NoSuchMethodError: No static method forceEnableAppTracing()V in class Landroidx/tracing/Trace; or its super classes (declaration of 'androidx.tracing.Trace' appears in /data/app/~~QG-KqkX7XjglpXiFeGkUVA==/com.example-app-Cp5gZmRoQKzfqLpHnN5jRg==/base.apk!classes29.dex)"

Moreover, some of the UI tests encountered another error"java.lang.NoClassDefFoundError: androidx.test.espresso.Espresso " Here's the list of the dependencies that we are trying to update: androidx.test:core from 1.5.0 to 1.6.0 (no issue found from our CI) androidx.test:rules from 1.5.0 to 1.6.0 androidx.test.ext:junit from 1.1.5 to 1.2.0 androidx.test:runner from 1.5.2 to 1.6.0 versionEspresso from 3.5.1 to 3.6.0

We are also using: androidxTestExt = { group = "androidx.test.ext", name = "junit", version = "1.2.0" } androidWorkerTest = { group = "androidx.work", name = "work-testing", version = "2.9.0" } composeBom = { group = "androidx.compose", name = "compose-bom", version.ref = "2024.06.00" } composeUiTest = { group = "androidx.compose.ui", name = "ui-test-junit4" } mockkAndroidTest = { group = "io.mockk", name = "mockk-android", version.ref = "1.13.11" } turbine = { group = "app.cash.turbine", name = "turbine", version = "1.1.0" } And Kotlin 2.0

Steps to Reproduce

Run either compose test or espresso test.

Expected Results

All UI Tests should be able to run successfully

Actual Results

UI tests failed due to either "java.lang.NoSuchMethodError: No static method forceEnableAppTracing()" and "java.lang.NoClassDefFoundError: androidx.test.espresso.Espresso"

AndroidX Test and Android OS Versions

See the list on the description section.

Link to a public git repo demonstrating the problem:

It's my first time logging an issue. Let me know if any of you need more details. Thanks!

TWiStErRob commented 3 days ago

From this comment:

no issue found from our CI

It sounds like you're trying to update each of those dependencies in individual PRs, but notice that they're released together from a monorepo (even if their versions don't match). Try to bundle them all into 1 PR to reduce problems coming from mixing "AndroidX Test" versions.

On the other hand, this looks like a duplicate of https://github.com/android/android-test/issues/1755.

@brettchabot is there a way to fix this in this repo, without needing every single user to go through the pain of "Espresso is broken again" discovery, needing deeper understanding of Gradle dependency resolution?

Aaron-Ritter commented 3 days ago

@TWiStErRob we have dependabot group update and it fails the same way https://github.com/FusionAuth/fusionauth-android-sdk/pull/88, so #1755 is likely the issue.

brettchabot commented 2 days ago

From this comment:

no issue found from our CI

It sounds like you're trying to update each of those dependencies in individual PRs, but notice that they're released together from a monorepo (even if their versions don't match). Try to bundle them all into 1 PR to reduce problems coming from mixing "AndroidX Test" versions.

I don't think that is a correct explanation. Typically we do release all of the individual artifacts in this repo together, but they should be capable of being versioned independently . However, you cannot disregard the version constraints. In this case androidx.test:monitor:1.7.0 requires androidx.tracing:tracing:1.1.0

On the other hand, this looks like a duplicate of #1755.

@brettchabot is there a way to fix this in this repo, without needing every single user to go through the pain of "Espresso is broken again" discovery, needing deeper understanding of Gradle dependency resolution?

This is a fair complaint. I was hoping this could be fixed in Android gradle but after 1.5 years since first being reported that sadly seems unlikely.

Here's what I can do:

2249 will catch and log the exception instead of crashing. I'll merge this to stable branch and kick off a monitor 1.7.1 release. I might bump the versions of core and runner too to make it less likely to hit this issue.
I went ahead and filed a public version of the gradle bug so anyone interested can follow along http://issuetracker.google.com/349628366

Does that sound reasonable?

eric-labelle commented 2 days ago

Thanks for the additional infos @brettchabot We're also currently trying to bump to all the latest version of the jetpack test libraries released this week, but for me, the workaround doesn't work either (tried adding tracing as implementation and/or androidTestImplementation). We were already using tracing:1.2.0 so I tried downgrading to 1.1.0 like the workaround suggested although changes to that class were minor and unrelated between 1.1.0 and 1.2.0, still doesn't work. I looked through dependencyInsight and it's really using 1.1.0 (or 1.2.0 when I remove the downgrade) and not 1.0.0 as suggested, so I'm not sure that workaround is really viable, or perhaps there's something else? 🤔 Our project uses dynamic features and we run tests in Firebase Test Lab.

Thanks

brettchabot commented 2 days ago

@eric-labelle can you post a sample that repros the problem

brettchabot commented 2 days ago

A release just went out with a workaround for this crash.

Please update to androidx.test:monitor:1.7.1

chestersek-kogan commented 2 days ago

Thanks for all the advice @brettchabot. I don't think our project has this androidx.test:monitor dependency. Is adding this dependency will fix the crash for us as well?

brettchabot commented 2 days ago

Your project will transitively depend on androidx.test:monitor since almost all other artifacts depend on it.

So just adding androidx.test:monitor:1.7.1 as an explicit dependency should fix it.

Alternatively you could just increment what you do depend on eg

androidx.test:core 1.6.1 androidx.test:rules 1.6.1 androidx.test.ext:junit 1.2.1 androidx.test:runner 1.6.1 versionEspresso 3.6.1

chestersek-kogan commented 2 days ago

@brettchabot We did try the alternative approach, and I can confirm that the new x.x.1 patch releases have addressed the issue that I raised. Now all of our test cases can be passed like normal.

eric-labelle commented 2 days ago

Having a really hard time reproducing it out of our project. I can also confirm the new patch version you just released fixed all tests.

android / android-test