A new start for our Kotlin analyzer for Android developers: more security rules, support ktlint, better code quality rules

Hello Android developers,

As part of our 2021 objectives, we want to help Android developers to write more secure code. While analyzing the Android market and knowing that now by default Kotlin is the recommended language to write Android apps, we decided to invest in our Kotlin engine to give us the possibility to write more powerful and accurate rules, especially to detect security issues.

What do you get today?

The rewrite of our Kotlin analyzer is done and based on stronger foundations, we re-implemented the existing 7 Bug and the 34 Code Smell detection rules. We believe they provide good results, better than ever.

On top of that, we provide 12 security rules in order to move forward in the accomplishment of our objective to secure Android apps:

Security Hotspots

  • S5332: Using clear-text protocols is security-sensitive
  • S4790: Using weak hashing algorithms is security-sensitive
  • S2245: Using pseudorandom number generators (PRNGs) is security-sensitive
  • S2068: Hard-coded credentials are security-sensitive
  • S1313: Using hardcoded IP addresses is security-sensitive


  • S5547: Cipher algorithms should be robust
  • S5542: Encryption algorithms should be used with secure mode and padding scheme
  • S5527: Server hostnames should be verified during SSL/TLS connections
  • S4830: Server certificates should be verified during SSL/TLS connections
  • S4426: Cryptographic keys should be robust
  • S4423: Weak SSL/TLS protocols should not be used
  • S3329: Cipher Block Chaining IV’s should be unpredictable

Support of AndroidLint, Detekt and ktlint

Finally, because we believe these linters provide value to Android developers, we strengthen the support of AndroidLint and Detekt and we added the support of ktlint. It means, you can easily load the results of these 3 tools into SonarCloud. We don’t expect to replace what is provided by these tools but we expect to provide valuable rules on top of them. For sure, from time to time you may see some overlap between these tools and what we provide out of the box but we will do our best to limit this to not generate noise.

Performance (edited)
You should expect your analysis to take more time than before (some users reported 4 times execution time on huge projects). This is linked to the fact that we run a deeper analysis than before to offer you better results. Precision comes at this cost.

What’s next?

We will continue on the security domain and detect security problems related to Android Data Storage and Android Authentication and Session Management.
We won’t forget pure Kotlin development best practices and we expect to prevent developers from making mistake with “coroutines”.

This is available now on SonarCloud and will be included in SonarQube 9.0.



Is there also a focus on kotlin for server backend developers? Actually the difference between Java rules and Kotlin rules especially regarding OWASP Top 20 issues is a problem.

I see the mobile market as a super set on top of the server back-end domain, with specific vulnerabilities (Intent Parameter Injection for example) coming on top of the OWASP Top 10 that we all know for web apps domain.
Once we will start implementing taint rules for Kotlin, it should be a no-brainer to replicate what we currently have for Java into the Kotlin domain.
Ultimately, the goal is indeed to make sure there is no gap between our Kotlin and Java rules and to reach this goal we decided to start by having a good offering for Android developers.

@Alexandre_Gigleux great news.

I am wondering what “strengthen the support” actually means? Does this refer to the automatic analysis? Because we are already using sonar.kotlin.detekt.reportPaths and sonar.androidLint.reportPaths in our SonarCloud projects using the Gradle plugin. Also detekt offers a ktlint wrapper.

So are there changes for us, despite the very welcome Android specific security rules?

Yes, we believe it’s valuable to use AndroidLint, Detekt and ktlint along with what we provide out of the box. What we want to do is to bring valuable rules on top of them and this will come release after release in the coming months.
By “strengthen”, I wanted to say that we now load all issues from these external linters whereas previously only the rules we were aware of were considered. It means for all new rules implemented by these linters during the last 1-2 years we were not loading the corresponding issues.

1 Like

Cool, thanks for your response! So we should potentially see more code smells as of now, because SonarCloud will include all issues reported by any of the tools? Just wondering because currently our number has not changed.

Looking forward for your improved Android and Kotlin support! :blush: