IssueTracker

We have a number of issues filed in the issue tracker around problems with the lint.xml file. Some of them are duplicates, but many of them illuminate different parts of the problem, so this is an umbrella issue which tries to succinctly list the problems.

(1) Bug: You can use lint.xml to change the severity of an issue, or to suppress a specific occurrence of an issue. If the lint.xml file is located in the right place (in the root of the module directory), then the settings from the lint.xml file (from here on referred to as the "configuration") will apply both in Gradle and from Android Studio. However, you can also point to a lint.xml file in a custom location using android.lintOptions.lintConfig <file> from Gradle. This lets you place the lint.xml file in a shared location and reuse it from all the various gradle projects. However, this did not work from Android Studio; it did not pick up this configuration, only the other lintOptions DSL flags for enabling/disabling issues.

(2) Lint could only apply up to two configurations: the lint.xml file in the library and the one from the app module (if lint is running on the whole project in Android Studio and with checkDependencies is true from Gradle). If you have both a lintOptions.lintConfig file and a lint.xml file, only one would be used.

(3) I was about to fix the first bug, but it turns out that some users now depend on this broken behavior: The use case is that you want to enable or disable some issues only in Studio, or only on the CI server. For example, in the IDE you may want to enable various up-to-date checks which tells you whether new versions are available, but you don't want your CI server to start reporting errors in the middle of the night as soon as a library is made available somewhere. Therefore, we need to add the ability of lint.xml to target specific lint integrations (studio, gradle, etc) before fixing the bug such that lint.xml applies everywhere.

(4) Some users have asked for an ability to configure issues with more granularity, not just for a whole module. For example, what if lint.xml could be placed in any directory and would apply recursively below, as is already the case for .gitignore files or .editorconfig files?

(5) Lint detector authors have also asked for the ability to pass data (parameters) to their detectors. Longer term, having a nice UI in Studio, and a nice DSL in Gradle, for letting the detector expose its parameters and offer easy editing would be great, but short term, allowing this via lint.xml options seems straightforward.