Android’s lint is the only code analyzer released and maintained by Google. So when you run lint on your codebase and you see warnings and errors you better pay attention to them because Google put those rules there for a reason.

The rules fit into six main topics

Correctness. This could be as minor as using px instead of pd or as major as putting a child view inside an AdapterView in your layout file. Performance. Things like allocating memory during drawing or layout operation. Or using HashMap with integer typed keys (in this case you better of with a ParseArray). Security. Sometimes you feel that you are secure enough since you use SecureRandom but specifies a fixed seed because of testing and it remains there when you release the application. Or you call Cipher.getInstance() which will use ECB by default(totally unsecure). Lint will tell you those cases too. Usability. When you get only one icon from your designer and you put it into the drawable’s folder instead of generating all the variations needed by the system. Accessibility. There are only 3 rules for accessibility. Missing contentDescription for images, missing labelFor attribute and missing performClick() implementation in your custom views. Internalization, aka. I18n. I totally agree with lint when throws a warning if you put string literals into setText(), or worst concatenate string there. You should get those texts from your strings.xml. This is worth to do even when you are not translating your app into multiple languages. It provides a better separation of concerns.

The six topics altogether contain 224 checks. For me, who barely can hold a shopping list in mind(maybe because my wife writes War and Peace long ones), it gives a piece of mind to know there are 224 problems that I don’t have to remember. And I can freely worry about the 9.999.776 things that remained.

I hope, now you are convinced that you should use lint.

Let’s see how to do it.

As I mentioned, it is a Google product, so it is baked into the build flow. You just have to enable it in your build.gradle file, like this:

Lint options

Even between the best of friends, disagree happens on certain topics. So it is not uncommon that you think some of the rules should not apply to your codebase. As for us at Prezi, without right-to-left support all the RTL warnings are undesirable. Here is how you can set up your own rules:

Lint config in lint.xml

In lint.xml you can deviate from the default settings by applying weaker or stronger severity level for the issues or turn them off completely.

lint.xml custom config

If you are not a big fan of writing XML’s you can suppress warnings in your source code too.

suppress in java code

Suppress lint from the java files.

@SuppressLint(“all”) is also working.

suppress lint in xml file

Ignore lint rule in resource XML files. Use comma separated list for more items or write ignore=”all”.

If you are more of a command line person, you can run lint like this

~ lint [-flags] <project directory>

For flags run