Android Lint is a static analysis tool for Android which looks for 225 (261 as of May 2016) different types of Android bugs. The potential bugs span a number of categories:

• Correctness (120 checks as of lint version 1.4)

• Performance (25 checks)

• Security (22 checks)

• Usability (21 checks)

• Translations & Internationalization (19)

• Accessibility (3)

The public usage documentation for Lint is here:

http://developer.android.com/tools/debugging/improving-w-lint.html

Current State

Lint is integrated in a number of tools:

• Android Studio and IntelliJ (details)

• Eclipse (details)

• The Android Gradle Plugin (details)

• The Jenkins CI server (plugin details)

• As a command line tool (“lint”)

• Used to integrate it in Shipshape and Maven, and miscellaneous individual product builds at Google.

Non-Goals

• Catching general Java programming bugs. These are already handled by existing code check tools, and they’re handled particularly well by IntelliJ’s code inspections, so performing the same checks in lint would just end up creating double warnings for the same errors in the source editor. Therefore, Android Lint is focused on Android-specific problems.

Goals

• Deeply integrated in the IDE: highlight potential errors right in the source editor

• Integratable in many different types of tools, not just the IDE, and in particular, must be available as part of release build checks on continuous build servers

• High performance: must be fast enough run all checks, all the time, without noticeably slowing down the IDE

• Should support comprehensive and sophisticated checks (e.g. checks which require consulting multiple data sources, may require multiple passes over the data, etc)

• Should flag any and all Android-related problems, not just problems in Java code; e.g. performance issues in layout XML files, spot inconsistencies between XML declarations and Java references, and so on.

• Should allow users to change the severity of issues (boosting warnings to errors and vice versa)

• Should allow users to deliberately suppress issues - either turning off checks completely, or only specific occurrences of a warning

• Allow lint rules to be shipped with libraries in an automatic way, and have lint automatically pick these up and use them to check that the code is using the library correctly

• This also implies that allowing custom rules is a goal for lint, so writing detectors should be as easy as possible, and lint’s testing infrastructure should also be available outside the SDK source tree

Whoops, That One Slipped Through

A classic problem for error checking tools is that they’re available, but that users don’t use them. Yes, they may spot a squiggly warning line in the editor if they happen to be looking at code in the same neighborhood. But there are some checks which aren’t highlighted on the fly and require the user to explicitly check for warnings (in IntelliJ, that action is Analyze > Inspect Code..). Furthermore, even if the user sees the warning, and intend to fix it, they may get distracted and forget.

Lint has a solution for this. While of course it’s integrated with Gradle in the same way that other static analysis tools are (findbugs, checkstyle, etc), and will generate reports if you run the “check” target, it goes one vital step further:

When you generate a release build, whether you ask for it or not, lint will be run too, in a special mode where it only looks for issues with “fatal” severity. This is usually a much smaller set of checks than a normal full lint run (currently 36 our 225 lint checks have severity fatal), so it’s faster than a normal lint run (and given that release builds often perform slow Proguard shrinking and obfuscation too, the additional overhead of fatal lint checking is minimal when compared to the overall build time.)

If any fatal issues are found during a release build, the release build is aborted! Yes, users can turn off this feature, but it’s on by default, and helps Android developers avoid shipping critical problems just because they forgot to run Inspect Code one more time after that last simple innocuous edit…

Examples

Here’s a (non-exhaustive) list of some of the checks lint performs:

• It looks for typos in your resource files. Many IDEs have a “spell checking” feature where they highlight any words not found in the known dictionary, which is often missing programming terms (not so for Android Studio, I added a bunch recently). However, lint takes the opposite approach: it ships with a database of known typo’s, such as “andriod” instead of “android”. I basically grabbed all the typo dictionaries I could find on wikipedia -- which has typo dictionaries for many languages. So while lint doesn’t have a Turkish, Italian, German, Hungarian etc spelling check -- it does flag typos in all these languages.

• When you have a button bar with Cancel and another one with an action verb -- do you remember which side the Cancel button should be on to comply with UI guidelines? (Hint: It depends on the version of Android you’re running.) Lint checks. Oh and makes sure you capitalize OK correctly. Ok?

• Lint is doing its part to move the world to UTF-8. If it finds that you’re using any other encoding in your XML files, they’re flagged. As a fatal error. Which fails the build.

• Lint looks for cut & paste errors, where you copy/paste code to initialize a series of fields with findViewById’s and forget to update one or more of the id’s. Yes, this has found bugs in production. Multiple times!

• Similarly, when you look up a view with a findViewById call and cast the result to a specific view, lint looks at the actual usages of that id in layout files and checks whether the cast looks safe.

• Lint looks at your icon files and makes sure for example that launcher icons have non-rectangular shapes, that notification icons only use shades of white and gray, that icons have consistent dip sizes across dpi folders, etc.

• Performance checks make sure you avoid allocating objects in paint and measure calls, ensure that you’re not using Collections when you could be using the more efficient SparseArrays, etc.

• There’s a huge list of additional checks; they are all listed and described here.

Architecture

The above goals have a number of implications for the architecture of lint:

• To be natively integrated in multiple tools, it needs to have strong embedding API and go through it for all key services:

• Example 1: Lint checks should never read files directly, they need to go through the lint embedding API. When lint is running in an IDE for example, the IDE can provide the current, possibly modified content of a buffer instead of the most recently saved version of a file.

• Example 2: There’s at least one lint check which connects to a remote server (to check to see if the user is using an older version of a library when a newer one is available). The lint check shouldn’t create this HTTP connection directly; it must go via the embedding API. This allows for example lint running inside Android Studio to use the user’s configured network connection with proxy settings in the IDE.

• To be embeddable not just in “the” IDE but in other tools like Gradle etc, means that lint cannot leverage IDE support. For example, it can’t use IntelliJ’s code index and parse trees.

• Historical note: Lint was initially implemented as a command line tool as well as integrated with Eclipse. The fact that it wasn’t directly referencing Eclipse APIs anywhere made integrating it into IntelliJ and Android Studio much easier! And it now works in multiple IDEs, though that’s not a priority for the tools team anymore, since we’re pursuing a single-IDE strategy. But supporting lint from the command line (Gradle) continues to be a critical requirement.

• To be able to run in the background while a user is editing a single file, it must support incremental checks. This is discussed later in the “Scopes” section (if you want to look ahead.)

• To search for “all” Android bugs, lint cannot simply just scan Java files. It currently has special support for analyzing the following file types (and, crucially, lint checks are able to consider data from more than one of these sources):

• Java source files, XML resource files and XML manifest files

• Compiled bytecode. Vital when analyzing libraries where we may only have bytecode, not source files.

• Bitmaps, like PNG files (sample check: launcher icons shouldn’t be rectangular)

• ProGuard files (sample check: file contains bug included in older default template)

• Property files (sample check: improperly escaped path on Windows)

• Gradle files (sample check: dependency is obsolete, newer library exists)

• Folders (sample check: suspicious language & region combination)

Performance, Performance, Performance

The top challenge for lint is to be highly performant, especially when running in the IDE.

This is addressed through a number of approaches:

• Overall philosophy: Optimize for the case that there are no warnings in the code. The assumption is that if there’s a warning, the user will see it and deal with such that we don’t have to keep paying the same price over and over.

• Try hard to do the minimum amount of work. Obviously, when the user is editing a single file, we should only be running checks in the current file*, and similarly we should only be running checks applicable to this file type. *: this is slightly complicated by cases where there are related files. For example, in Eclipse, lint inspections are run when the file is saved, and in that case we run lint checks incrementally on both the .java and .class files (there could be many, one for each inner class) corresponding to the just edited file.

• There are some operations which can be handled faster in the IDE. Allow the IDE integration to

• Swap in its own implementation of lint a given lint check. This is done for the API check in Android Studio for example. (2016: not anymore)

• Provide faster implementations of certain lint services (such as resolving super classes), where the IDE (or other embedding tool) can leverage extra information it has such as persistent code index.

• Lint allows lint checks to request another pass through the code. When this happens, it repeats the analysis with the subset of lint checks that required another pass. This allows many lint checks to run more leanly. For example, the unused resource detector keeps track of all the declarations and references of resources, and at the end figures out if there are any unused resource. If that’s the case, only then does it request another pass, and it’s in this second pass that it gathers the much more expensive information it needs to report unused resource errors (computing locations of resource declarations etc).

• The biggest performance gains at the infrastructure level are gained from the smart visitors.  There are dedicated visitors for .java, .class and .xml files. The purpose of for example the XML visitor is that if there are let’s say 100 visitors that consider XML content, and the document is a strings.xml file with 500 strings in it (e.g. ~500 elements and ~500 attributes, one for each name attribute), we don’t iterate through this document 100 times, once for each detector, e.g. 50,000 element checks. Instead, the lint checks declare up front which specific tag names and/or attributes they care about. This allows lint to iterate through the XML document in a single pass. For each element and attribute, it only consults the lint checks that apply to the given tag or attribute. There are some complications here, and the situation for Java checks and bytecode checks are a bit more complicated in that there are more usage scenarios, but from a performance perspective, the tricks are the same: partition the work up front to allow just a few passes through the files.

• In addition, there’s a lot of work on performance in the individual lint checks.

• Take the API check for example. It needs to look up the API level for every single method and field reference in every Java file. The database is a 60,000 line XML file shipped with the platform-tools. To make this fast, it performs a one-time parse of the XML file and generates a compact binary database stored in its cache directory; on subsequent runs, it can just mmap in the database file and search it quickly.

• Another example is the plurals check, which looks for likely errors in plurals usage, such as not including a quantity string in a language where that will likely lead to a grammar error. For this, there is a special PluralsDatabase that is generated from ICU data by a unit test if necessary whenever updating to a new ICU version.

Annotation-Based Checks

The support library now ships with a number of annotations which express additional metadata about code. These are all documented here: https://developer.android.com/studio/write/annotations.html.

These annotations let you for example indicate that

• An int parameter must be one or more of a given specific set of constants, such as Gravity.LEFT or Gravity.RIGHT.

• A resource integer of a particular type, such as a @drawable.

• Called on the UI thread.

• An integer that is in the range -10 to 10.

• ...and so on.

These annotations are also available in the framework (in the android.annotation namespace instead, but hidden). The SDK extracts these annotations, converts them to the corresponding support annotation, and ships these in an extracted form both with the platform-tools (for command line lint usage) and with Android Studio (for IDE usage).

Lint has special support for checking for these annotations.

For every single method call, it finds the corresponding method and checks whether it, or any of its super classes, are annotated with a support annotation (either directly on that code, or in the external annotations database, as discussed above). This is also done for field references, and class references.

For each support annotation constraint it finds, it then perform analysis to discover whether the annotation constraint is met.

Typedef Annotations (@IntDef) and External Annotations

The @IntDef annotations check is one of the annotation based checks, but it has some interesting special considerations.

First, @IntDef allows developers (and the framework) to use a primitive integer instead of an enum to represent that a parameter must be one of a specific set of values, offering compile-time safety to the same extent that an enum does -- but without the same overhead. (Much has been made about the number of extra bytes required by an enum in the .dex file, but another consideration of enums is that the runtime class also needs to initialize all constants as objects.)

The main benefit of an @IntDef is that you can have two unrelated constants that have the same value, and while the compiler will happily let you pass in one instead of the other, the typdef annotation knows the specific allowed constants and will flag any other constants, whether the values are the same or not.

However, annotations in .class files cannot record “references to constants” in this way; they can only contain a limit set of specific types of data: primitives, Strings, Class instances and enums. Therefore, if we look at the .class file for a typedef enum, it only contains the actual values of the constants, not the references to the fields that contained the constants -- and with only the values, lint can’t actually do its job down the line.

Therefore, the typedef annotation needs to either be local to the project (such that lint can look at the AST node for the typedef annotation itself), or we need to record the data in a separate mechanism: an external file. That’s what lint does. When Gradle is compiling libraries (such as the support library), it runs a special “extract annotations” task, which looks for typedef annotations, and when it finds any, it records these annotations in a special file inside the AAR file.

Lint, when analyzing projects, will look at all the AAR files of the project’s dependencies, see if any contain the special external annotations file, and if so, include it in its annotations lookup described above.

Flow Analysis

Control Flow Analysis

Lint has multiple implementations of control flow analysis: one operating at the bytecode level, for the .class file based checks, and the other for Java AST based analysis.

One obvious use for control flow analysis in lint is the WakelockDetector, which looks at wakelock acquire and release calls, and makes sure there is no escape path via exceptions that can lead to the wakelock release being skipped.

However, the most “important” control flow check in lint is related to the API check, because it avoids a lot of false positives!

Lint’s API check looks at every method call and field reference, and makes sure that the call was not introduced in an API level higher than the minSdkVersion supported by the phone.

However, what if that code is surrounded by an explicit version check? In the below, we don’t want myLollipopCall() to be flagged as invalid, since clearly it can only be executed if we’re on Lollipop:

if (Build.VERSION.SDK_INT > LOLLIPOP) {

myLollipopCall();

}

Checking this is not as simple as just looking to see if a method call is surrounded by a simple if check like this (though usually that’s where the lint check is). It’s not even enough to look at all outer if statements. We also need to handle scenarios like this:

if (Build.VERSION.SDK_INT <= LOLLIPOP) {

            return;

}

myLollipopCall();

...and so on. Hence, lint will build up a control flow graph to analyze the control flow in these cases such that it can properly be silent about API “violations” that are found to be unreachable on older platforms.

2017: There's a new global call graph for use by lint checks such as the inter-procedural thread checker. This is still experimental.

Data Flow Analysis

Lint performs data flow analysis for a number of checks.

Just as for control flow, this is implemented in two separate ways: one for bytecode analysis, and one for AST based analysis.

Examples of AST-based data flow analysis:

• If you create a TypedArray (via a call to obtainStyledArrays), lint tracks the references to the returned value (which can pass from one variable to another), and it makes sure that the array is eventually recycled. In fact it goes one step further: it also checks to see if you recycle it more than once, which is also not valid.

• For the String format detector, it checks whether the formatting specifies specified in an XML resource string matches the argument types supplied to the String.format call. However, to do this, it needs to be able to figure out which resource string is used for formatting. It’s simple when the call is
  getResources().getString(R.string.hello), arg) myArgument)
  but we’re not always that lucky.

• The new Intent and ContentProvider permission lint checks in 1.4 require data flow analysis to be able to map for example a ContentProvider URI with a call.

Examples of bytecode based data flow analysis:

• The SecureRandomDetector which looks at calls to initialize the random number generator makes sure that the value passed into the constructor is not a fixed value

Constant Folding

Lint performs “constant folding” on the AST, including for symbols referenced from other compilation units. For example, if in one class you define

public static final String LOG_TAG_PREFIX = “MyReallyLongLogTag”;

and then from some other class you do this

public static final String LOG_TAG = OtherClass.LOG_TAG_PREFIX + “_Parser”;

Lint will flag a logging call using this tag as invalid, because the LOG_TAG is too long (the max allowed is 23 characters), and it computed this on the fly in the editor by performing constant evaluation: