Hi everyone,
I’ve been running SonarQube Community Build to analyze a project focused on mobile performance optimization, and I’ve run into a consistent issue with how the scanner interprets high-concurrency logic.
Specifically, I’m seeing a high volume of “Code Smell” and “Reliability” flags regarding thread-safety and resource locking. While I was chatting with some developers in the arceusx community about stabilizing background executors on mobile, I realized that many of these flags might be false positives. In our case, we are intentionally bypassing certain standard locking mechanisms to reduce UI jank and improve execution speed on resource-constrained devices.
Has anyone else noticed that Sonar’s default “Sonar way” profile can be a bit too aggressive when it comes to mobile-specific optimizations? I’m particularly seeing issues where the scanner flags “synchronized” blocks as missing, even though the context—running within a isolated mobile webview environment—doesn’t technically require them for the specific task at hand.
I’m trying to figure out if it’s better to create a custom Quality Profile to silence these specific rules, or if there’s a way to provide more context to the Sonar scanner so it understands the “intent” of the code when external scripts are active. If you’ve dealt with fine-tuning SonarCloud or SonarQube for mobile utility tools where performance is prioritized over traditional enterprise safety patterns, I’d love to hear how you managed your quality gates!
Thanks for the help!