So as you can see, the 1st “on SDK version 23…” issue matches the Security -> 1 -> AllowBackup.
The 2nd “App is not indexable by Google Search…” issue matches the Usability -> 1 -> GoogleAppIndexingWarning.
So from my locally generated Lint Report the folllowing points are missing in SonarQube:
If you look in the AndroidLint XML report in more details (imported by SonarQube), can you cross-check that the files/lines on which other issues are reported, are also analysed and reported in SonarQube ? (pay attention to full filepaths by the way, it’s important they match)
thanks for your response. I use the following property, and whith this the Android Lint came to SonarQube (before there were no Android Lint issues at all reported):
PS: and only to be sure, this is my Gradle call from the CLI: gradlew lint createDebugCoverageReport jacocoTestReport sonarqube -Dsonar.host.url=http://localhost:9000 -Dsonar.login=32a05a6ed5e0e5cc84ff864fb41044798e135668
PSS: I installed SonarQube Community Edition Version 7.2.1 locally on my Windows laptop, using the following plugins:
Those are either directories or pictures (.jpg), I’m not sure where you would expect to see them reported in SonarQube ?
Just to clarify: SonarQube will import external issues on the code it actually analyzed. No intent to blindly import data that does not relate to specific code files which were not analyzed.
so you are saying, that SonarQube only shows a subset of that what AndroidLint generates?
In my example I added an unused image, yes, these issues lead to larger apps, so Android Lint helps to protect us from that. I think it would be nice to see this in SonarQube as well; well, not as part of the Kotlin code analyser nor as part of the XML code analyser, but maybe as part of some meta analyser?
Yes, SonarQube only shows a subset of what AndroidLint generates. Even if you don’t configure file exclusions on your project, only issues on file with extensions “.xml .java .kt .kts .properties .gradle .cfg .txt” are imported into SonarQube.
I agree, issues on binary files and directories are also valuable. But SonarQube platform ignores issues on directories and does not display well issues on binary files. That’s why, during the import, we intentionally filter them.
So we are open for discussion if you have any solution that could improve your need.