Android Gradle 3.0多DEX冲突：TestOnly重复定义排查

Hey there, I’ve dealt with this exact dex duplicate headache before—especially with JetBrains annotations hiding in unexpected places. Let’s go through all the commands and tricks beyond just app:dependencies to track down where that duplicate TestOnly class is coming from:

1. Targeted Dependency Tree Commands #

The default app:dependencies output can be overwhelming, so narrow it down to focus on the problem area:

• Filter for JetBrains-related dependencies: Run this command to zero in on any line mentioning JetBrains, plus the context around it:

  ./gradlew app:dependencies --configuration releaseCompileClasspath | grep -A 5 -B 5 "jetbrains"
  

  This shows you exactly which libraries are pulling in the annotations—sometimes it’s an indirect dependency you didn’t notice.
• Check all build configurations: The default dependencies command only shows compile-time dependencies, but duplicates often pop up between main code and test configurations. Run this to see every dependency across all configurations (like androidTestCompile or testCompile):

  ./gradlew app:dependencies --configuration all
  

• Generate a visual dependency report: Gradle can make an interactive HTML report that’s way easier to navigate than raw text. Run:

  ./gradlew app:generateDependenciesReport
  

  You’ll find the report in app/build/reports/dependency-report/—open it in a browser, use the search bar for "TestOnly" or "jetbrains", and you’ll see a clear hierarchy of dependencies.

2. Scan for Duplicate Classes Directly #

Sometimes the duplicate class isn’t coming from a declared Maven dependency—it’s packed into a local JAR/AAR. Use these commands to hunt it down:

• Search all exploded AARs/JARs for the TestOnly class: After running a build, Gradle unpacks dependencies into intermediate folders. Run this to scan every JAR inside those folders:

  find app/build/intermediates/exploded-aar -name "*.jar" -exec jar tf {} \; | grep "TestOnly"
  

  This will list every JAR that contains the TestOnly class, so you can trace it back to its source.
• Check compiled class directories: After building, look in these two folders for duplicate TestOnly.class files:
  • app/build/intermediates/classes/debug (your app’s compiled classes)
  • app/build/intermediates/external_libs_classes/debug (compiled classes from dependencies)

3. Bonus Troubleshooting Tricks #

• Inspect local dependencies: If you have JARs or AARs in your libs/ folder, manually unzip them and check if they contain org/jetbrains/annotations/TestOnly.class. Local dependencies don’t show up in the dependencies tree, so they’re a common culprit.
• Reverse-test with dependency exclusion: If you suspect a library is pulling in the duplicate annotation, exclude it temporarily and see if the error goes away. For example:

  implementation('com.example:suspected-library:1.0.0') {
      exclude group: 'org.jetbrains', module: 'annotations'
  }
  

• Enable debug logging for dependency resolution: Gradle’s debug logs show every step of dependency parsing, which can reveal hidden dependencies. Run:

  ./gradlew app:assembleDebug -d | grep "jetbrains"
  

  This will spit out detailed logs about how JetBrains annotations are being pulled into your project.

Wrapping Up #

Most of the time, this duplicate issue isn’t from a direct Maven dependency—it’s either a local library packing the annotations, or a conflict between your main code dependencies and test dependencies. Start with the targeted dependency tree commands, then move to scanning for the class directly, and you’ll find the source in no time.

内容的提问来源于stack exchange，提问作者kar