Sonarlint ignores some rules

SonarLint IntelliJ Platform
, , ,
1

We are having some issues with SonarLint analysis in Android Studio, it seems to be skipping some checks. We found out about the issues after connecting the plugin to our SonarQube Server to use our own rulesets, but I was able to reproduce this issue without the SonarQube connection.
The rule we are having Problems with is "static" base class members should not be accessed via derived types, but there seem to be multiple rules that aren’t applied, since the SonarLint check is, in comparison to SonarQube, a few issues short for almost every file.

Setup:

  • SonarLint Plugin for IntelliJ 4.5.1.15617
  • Android Studio 3.6.1
  • I’m on Arch, but my colleague was able to reproduce the issue on Windows 10

Minimal steps to reproduce:

  1. Start a new android project or open an existing one
  2. Make sure the SonarLint rule "static" base class members should not be accessed via derived types is activated
  3. Add this anywhere in an activity:
AlertDialog dialog = new AlertDialog.Builder(getActivity()).create();
dialog.getButton(AlertDialog.BUTTON_POSITIVE).setEnabled(true);

→ If everything worked correctly, SonarLint should mark AlertDialog.BUTTON_POSITIVE as an issue and suggest adding a static import. For me and my colleagues however, it doesn’t.

To double-check if this is really a false negative, let the demo code run through a SonarQube check with this rule enabled. SonarQube will corectly recognize it as an issue.

2

Hello, thanks for reporting this.

I managed to reproduce this issue in IntelliJ Ultimate with the latest Android Support plugin (equivalent to a recent Android Studio).

However, the rule was correctly triggered with a class hierarchy inside my test project, so this looks to me like a type resolution issue - and in my local tests, I noticed that the SDK’s android.jar is not present in the analyzer’s resolved class path, which could explain why AlertDialog and/or DialogInterface are not resolved, resulting in a false negative from the rule.

Could you please enable both “Analysis logs” and “Verbose output” and check the Logs tab of the SonarLint tool window? There should be a long list of lines starting with:

----- Classpath analyzed by Squid:

According to my tests, none of them should point to the SDK JAR (and we could start to look on why this is missing, and how to fix it).

3

Thank you for the quick answer. Here are the logs of a scan on the MainActivity of a new project containing the two AlertDialog lines and with only the “static base class…” rule activated: Gist link
(uploaded them to gist because of character limit)

4

Great, thanks.

As a final validation, the following code should raise an issue on the reference to Extend.PROPERTY:

  interface Super {
    static final int PROPERTY = -1;
  }

  class Extend implements Super {
    // NOP
  }

  System.out.println(Extend.PROPERTY);

This would confirm that the issue lies in type resolution.

5

Yes, it does

1 Like
6

I reproduced with Android Studio 3.1.2, so this is not a new issue :frowning: Thanks for reporting it!

For the record, when you enable verbose and analysis logs, you should see a message Classes not found during the analysis which indicate that type resolution failed.

Java Main Files AST scan
1 source files to be analyzed
Initializing metadata of file file:///home/julien/Prog/AndroidStudioProjects/MyApplication/app/src/main/java/com/sonarsource/myapplication/MainActivity.java
1/1 source files have been analyzed
Classes not found during the analysis : [android.app.Activity, android.content.Context, android.content.Intent, android.content.IntentSender, android.content.IntentSender$SendIntentException, [...]]
Java Main Files AST scan (done) | time=1687ms
7

Thank you for your detailed report, ticket created!

1 Like