Lint ships with a number of new features in 2.3.
This feature allows you to save a snapshot of your project's current set of warnings, and then use that as a baseline for future inspection runs where only new issues are reported. This lets you start using lint to fail the build without having to go back and address all existing issues first.
To use this feature, modify your build.gradle file like this:
Next run lint -- either from the IDE (via Analyze > Inspect Code…) or from the command line, e.g.
This will run lint on the project and record all the current issues in the file listed above ("lint-baseline.xml" in the project directory). The set of current issues is called the "baseline". This is a file you'll probably want to check into version control.
Note that if you only want to add some types of issues to the baseline, not all of them, you can add lines to build.gradle to configure the specific issues you want to include:
Remember to delete these after creating the baseline file.
From now on, if you add any new warnings to the codebase, lint will only list the newly introduced bugs!
With this set up, you may even want to turn all warnings into errors, and fail the build if there are any errors:
When baselines are in effect, you'll also get a warning (but only with "informational" severity) that tells you that one or more issues were filtered out because they were already listed in the baseline. The purpose of this is to avoid a situation where you forget that you have configured a baseline. Ideally you'll want to go back and fix all the issues at some point!
This warning doesn't just tell you the exact number of errors and warnings that it filtered out, but it also keeps track of issues that weren't reported anymore. This lets you know if you've actually fixed issues, so you can optionally re-create the baseline to prevent the error from sneaking back undetected!
Note also that while baselines are enabled when you run Inspections in batch mode in the IDE, they are ignored for the in-editor checks that run in the background when you're editing a file. The purpose is the same: baselines are intended for the case where a codebase has a massive number of existing warnings, but you do want to fix issues locally as you're touching code.
In the IDE, the above warning which describes filtered out issues has an associated quickfix which lets you re-run analysis without the baseline. This gives you a quick way to view the actual issues in the codebase and to fix them.
Similarly, the warning which tells you that some issues listed in the baseline appear to be fixed has an IDE quickfix which lets you update the baseline to remove the fixed issues. This helps you ensure that the issues don't creep back in undetected.
The new version of the support library (25.x) shipped with some new and updated annotations that lint can use.
This annotation, which can be specified not just on methods and classes but on packages as well, lets you designate an API as restricted. There are several types of restrictions:
This annotation is not new, but it now has an optional argument: "otherwise". This lets you designate what the visibility of the method should have been if not for the need to make it visible for testing.
Lint uses this to enforce the intended visibility. For example, if you have a method that you wanted to be private except it's now package private for tests, like this:
Then lint will complain if anyone calls this from outside the context allowed by private access -- e.g. from a different compilation unit.
You can also specify
Android Studio 2.3 also ships with a cluster of new lint checks. (There are also a large number of bug fixes to the existing checks -- typically fixing false positives or false negatives.)
Many of these look for specific problems that you'll only need to know about it if it finds the problem in your project -- but here are some notable ones:
Lint now flags useless version checks. Let's say your minSdkVersion used to be 10, and you had some conditional code like this:
If you later go and change the
When using an ObjectAnimator, you are referencing methods on a class by name. If you have a typo, the app will compile but crash at runtime. And more subtly, even if you're using the right name and your app works correctly, it's possible that when you build a release version of your app and the app is obfuscated with ProGuard, ProGuard doesn't know that you're referencing this method by name, so it may be renamed and even deleted as unused, which will also cause a crash.
Lint now analyzes your code to make sure that your ObjectAnimator calls are referencing valid methods with the right signatures:
It also checks that those methods have been annotated with
Older versions of the RecyclerView library did not include a divider decorator, but one was provided as a sample in the support demos. This divider class has been widely copy/pasted into various projects.
In recent versions of the support library, the divider decorator is now included, so you can replace custom copies with the "built-in" version,
Lint looks for code that looks like a copy of the old sample and suggests replacing it.
On versions prior to Android N (24), initializing theWifiManager via Context#getSystemService can cause a memory leak if the context is not the application context. Lint looks for these types of initializations and if it's not certain that a context is the application context, it suggests you change it to
Lint has had a resourcePrefix check for quite a while, but it had many limitations. In 2.3 it's quite a bit smarter so you can now configure your project with a prefix, such as this:
and lint will now make sure that all your resources are using this prefix. Unlike the past, it now lets you use variations of the name for styles and themes, so for example for the above my_lib_ prefix you can have themes named MyLibTheme, myLibAttr, my_lib_layout, and so forth.
Technical docs >