Hey folks, With the release Android Gradle Plugin 9, we assume most of you will be migrating to the newest version of AGP very soon. However, as some of you have attempted to do so, we have been made aware of conflicts at analysis time when invoking the SonarScanner for Gradle (see for instance this post or this post). We will be working in the coming days to remove the blockers in the scanner preventing you from upgrading your projects to AGP9. Should you need to upgrade your projects before our next release of SonarScanner for Gradle, we recommend you give this tip suggested by @michael-winkler a try: add android.newDsl=false to the gradle.properties file of your project. While it adds an extra deprecation warning to your logs, it should enable you to get some migration work started. Stay tuned for updates on the progress of this work. Cheers, Dorian

Hi there! Do you have any updates on AGP9 support? Any estimate on when a patched version of the plugin will be released?

Hi Dorian, Thanks for the update and for sharing the android.newDsl=false workaround! While adding this flag to our gradle.properties does successfully prevent the scanner from crashing during the configuration phase, we are encountering a critical side effect: all code coverage is lost. Although the project compiles and the :sonar task completes without errors, our coverage metrics drop to 0% on the dashboard. It appears that by reverting to the legacy DSL, the scanner is no longer able to correctly locate the compiled class directories or the test coverage report outputs (like the JaCoCo XML files) generated under the new AGP 9 structure. In short, this workaround unblocks the build, but it completely breaks our coverage quality gates. Why the coverage is lost? Mostly sure that by adding android.newDsl=false, you are forcing the Android Gradle Plugin (AGP) to fall back to its old, deprecated DSL implementations. This successfully prevents the SonarScanner from crashing with the Extension of type 'AppExtension' does not exist error during the build’s configuration phase. However, because AGP 9 has entirely restructured its internal interfaces and variant APIs, the legacy scanner fails to resolve the correct file paths to your compiled classes and test execution outputs. When SonarScanner cannot find these compiled class directories or report files, it defaults to reporting 0% code coverage. We are really looking forward to a patched release of the SonarScanner for Gradle that natively supports the new AGP 9 APIs so we can fully and safely migrate. Thanks for prioritizing this!

Hey @gmazzo, Sorry for the late reply. We plan to tackle the support of AGP9 as part version 7.3 targeted for April.

I look forward to AGP 9 support. I came across the failure with AGP 9.0.0/9.0.1 with removal of the flag for android.newDsl=false providing a workaround. However, I also came across a failure with no work around (that I could figure out) for AGP 9.1.0 (and Gradle 9.3.1) released with Android Studio Panda 2 on March 3rd. gradlew :sonar fails immediately on my project with android.newDsl=false still in place with the following: Unable to find method ''java.util.Collection com.android.builder.model.SourceProvider.getCDirectories()'' 'java.util.Collection com.android.builder.model.SourceProvider.getCDirectories()' I know this is a large transition for Gradle Plugin maintainers, but it’s sad to see a plugin that should enhance development become a hinderance with support lagging pretty significantly - where support could be pro-active with release candidates provided from Android Studio.

Oh, I see there is a conversation on this at Sonarcloud not working with Android Gradle Plugin 9.1.0 as well.

I’m somewhat struggling to understand why this has been left unless Android and modern Kotlin projects represent such a small portion of revenue and users that this is simply dismissed in favor of other priorities. Considering that many companies have these tools passing as part of required workflows AND the nature of Kotlin and Android projects basically requiring folks to never be more than 3-6mo behind on dependencies to avoid issues, this stance has been somewhat surprising. Perhaps this is simply a mismatch of expectations and sales and how these tools are marketed. I personally really like the tool, so as a direct example this is really just making it hard for advocates as well.

Now that we are at the end of April and it looks like Jira and Jira are Done, is there an update on when we should expect support for AGP 9 to be released?

Working towards the support of Android Gradle Plugin 9

Sonar Updates

aurelien.coet (Aurélien Coet) April 30, 2026, 9:09am 10

Hi all,

We have released a new version of the Sonar scanner for Gradle now with support for Android Gradle Plugin 9.

Topic		Replies	Views
Lower coverage after Gradle upgrade SonarQube Server / Community Build gradle , scanner , coverage	3	1070	September 27, 2022
Sonarcloud not working with Android Gradle Plugin 9.1.0 SonarQube Cloud gradle , scanner , android	8	1489	May 6, 2026
SonarScanner for Gradle 7.3.1 Sonar Updates gradle , scanner , android , plugin , sonar-scanner	3	436	June 9, 2026
Gradle scanner 7.3.0 sets invalid Java binaries for AGP 9.2 SonarQube Server / Community Build scanner	6	319	June 3, 2026
SonarScanner for Gradle 7.3.0 Sonar Updates gradle , scanner , android , plugin , sonar-scanner	3	1034	June 2, 2026

Working towards the support of Android Gradle Plugin 9

Related topics