Sonar-scanner-gradle 7.3.0: Incorrect sonar.java.binaries

SonarQube Server / Community Build
, , , ,
1

Environment

  • sonar-scanner-gradle: 7.3.0.8198
  • Android Gradle Plugin: 9.1.1
  • Gradle: 9.4.1

Description

The new AndroidConfig.java class (introduced in SCANGRADLE-315 / PR #493 for AGP 9 support) hardcodes an incorrect path for sonar.java.binaries.

In AndroidConfig.getCompiledClasses():

private static Provider<File> getCompiledClasses(Project project, Component component) {
    return project.provider(() -> project.getLayout()
      .getBuildDirectory()
      .dir("intermediates/javac/" + component.getName() + "/classes")
      .get()
      .getAsFile()
    );
}

This resolves to: build/intermediates/javac/debug/classes/
However, AGP 9 outputs compiled Java classes to: build/intermediates/javac/debug/compileDebugJavaWithJavac/classes/

The extra compile{Variant}JavaWithJavac/ segment is missing.

Impact

Any Android module with .java source files fails analysis with:

Your project contains .java files, please provide compiled classes with
sonar.java.binaries property, or exclude them from the analysis with
sonar.exclusions property.

This occurs even when compilation has completed successfully and .class files exist at the correct AGP 9 path.

Pure-Kotlin modules are unaffected because the Java sensor doesn’t activate without .java files.

Steps to Reproduce

  1. Create an Android library module with at least one .java source file
  2. Use AGP 9.x + sonar-scanner-gradle 7.3.0
  3. Compile the module: ./gradlew :mymodule:compileDebugJavaWithJavac
  4. Run analysis: ./gradlew :mymodule:sonar
  5. Observe the failure

Expected Fix

getCompiledClasses should resolve the actual javac output directory, likely by querying the JavaCompile task’s destinationDirectory (as LegacyAndroidConfig does) rather than hardcoding a path:

LegacyAndroidConfig approach (works):

Collections.singleton(javaCompile.getDestinationDirectory().getAsFile().get())
4

Hello @julioyg,

Thank you for the feedback on the latest version of the scanner.
You are right, the computation of binaries for Java classes is incorrect here. I have opened a ticket for this.

Best regards,
Aurélien