SonarScanner for Gradle 7.3.0

Sonar Updates
, , , ,
1

We are pleased to announce the release of the Sonar scanner for Gradle 7.3, now supporting Android Gradle Plugin version 9.
The release also fixes some issues that were present in previous versions of the scanner and moves the creation of the sonar-resolver folders from configuration to execution time.

We encourage all of our users to try out this latest version of the scanner and share their experience with us, especially those who migrated their projects to AGP 9 and whose analyses were disrupted by the move.
If you have any feedback or encounter any issues with this new release, please open a new thread for discussion.

2

(UPDATE) Hello SonarSource team,

After extensive debugging on an AGP 9.2.0 codebase, we managed to track down the exact trigger for the MissingValueException crashing the :sonarResolver task, and we found a clean workaround that doesn’t require mutating Gradle scripts.

The Root Cause

The crash happens specifically because of how sonarResolver interacts with Firebase Crashlytics (and potentially other plugins like Google Services) under AGP 9’s strict lazy configuration.

  1. When sonar.android.variant is set (e.g., stagingDebug), Sonar asks AGP for the variant’s generated resource directories.

  2. AGP provides a list of lazy providers, including the output directory for injectCrashlyticsMappingFileId.

  3. In many local/debug builds, developers disable Crashlytics mapping uploads (e.g., mappingFileUploadEnabled = false).

  4. Because the Crashlytics task is disabled, it intentionally produces no value for that provider.

  5. When sonarResolver eagerly queries the provider collection, Gradle 9 strictly enforces provider constraints and crashes the build with: Cannot query the value of this provider because it has no value available.

This perfectly aligns with the architectural fixes being discussed in PR #498.

The Clean Workaround (No build script hacks)

Initially, we tried forcing explicit dependsOn relationships in our Gradle scripts to bypass the lazy evaluation errors, but this caused massive side-effects with KSP and Hilt.

The safest, cleanest workaround to survive AGP 9 until the plugin is updated is to bypass the sonarResolver task entirely via the CLI.

By excluding the resolver and manually providing a fallback binary path, the sonar task executes perfectly:

Bash

./gradlew sonar -x :app:sonarResolver -Dsonar.java.binaries=build

(Note: If you have a multi-module project, exclude the resolver for the app module that applies Crashlytics/Google Services. The -Dsonar.java.binaries=build flag prevents the Java analyzer from crashing if it encounters legacy .java files but no compiled classes in the old AGP 7/8 directories).

I hope this context helps the engineering team validate the fixes for AGP 9!

3

I attempted to use this work around but it results in the sources for my app module not being included in the sonar report at all. Is there a ticket to follow for a more permanent fix rather than disabling sonarResolver?