and many more.
Command Line Usage
There is a command line tool in the SDK tools/ directory called
If you have the SDK
directory on your path, you can invoke it as “
”. Just point to a specific Android project directory. You can also point to a random directory, which (if it is not an Android project) will be searched recursively and all projects under that directory will be checked. (And you can also specify multiple projects separated by spaces).
$ lint /src/astrid/
Scanning GreenDroid-GoogleAPIs: ..
Scanning stream: ...
Scanning api: ...........................
Scanning GDCatalog: .......................
Scanning GreenDroid: ...........................................................
Scanning tests: ...
Scanning filters: ....
Scanning tests: .....
Scanning astrid: ....................................................................................................................................................
Scanning simple: .......
api/res/values-ca: Error: Locale ca is missing translations for: sync_SPr_bgwifi_key, sync_SPr_forget_key, sync_SPr_interval_values, sync_SPr_logged_in_prefix... (2 more) [MissingTranslation]
astrid/res/values-ca: Error: Locale ca is missing translations for: DLG_cancel, DLG_dismiss, DLG_ok, EPr_deactivated... (117 more) [MissingTranslation]
api/res/values-cs: Error: Locale cs is missing translations for: sync_SPr_bgwifi_key, sync_SPr_forget_key, sync_SPr_interval_values, sync_SPr_logged_in_prefix... (2 more) [MissingTranslation]
(many lines omitted)
43 errors, 466 warnings
The “id” for each type of error is shown in brackets after the error message, such as “MissingTranslation” above.
You can disable a specific check, or a list of checks, by adding the --disable argument, e.g.
$ lint --disable MissingTranslation,UnusedIds,Usability:Icons /src/astrid/
Note that you can list categories as well, such as “Usability:Icons” above, which is the Icons subcategory of the Usability category.
Some checks are disabled by default. These can be enabled by adding the
Finally, you can specify which exact checks to run with the
flag. This lets you look for a specific problem in the codebase, such as:
$ lint --check MissingPrefix /src/astrid/
To find out which id’s and categories are available, run
$ lint --list
Valid issue categories:
Valid issue id's:
"ContentDescription": Ensures that image widgets provide a contentDescription
"DuplicateIds": Checks for duplicate ids within a single layout
"StateListReachable": Looks for unreachable states in a <selector>
"InefficientWeight": Looks for inefficient weight declarations in LinearLayouts
"ScrollViewSize": Checks that ScrollViews use wrap_content in scrolling dimension
"MergeRootFrame": Checks whether a root <FrameLayout> can be replaced with a <merge> tag
And to get the explanation for a specific issue use the
command along with a list of id’s or categories (or no arguments at all to see everything):
$ lint --show MissingPrefix
Summary: Detect XML attributes not using the Android namespace
Priority: 8 / 10
Most Android views have attributes in the Android namespace. When
referencing these attributes you *must* include the namespace prefix,
or your attribute will be interpreted by aapt as just a custom
The command line tool can also generate HTML reports. This has some advantages over the plain lint output:
- It includes the longer explanations associated with each issue, and hyperlinks to More Info for issues which provide a more info attribute.
- It includes the actual source code line with the error (and a window of 3 lines around it).
- It can contain links to the associated source files
- For icon errors, the icons themselves are shown in the report for comparison purposes
To generate an HTML report, just add
as an argument:
$ lint --html /tmp/report.html
By default, links to source files will just use local file:// path resources. You can remap the URLs to a different prefix with the --url option. For example:
$ lint --html /tmp/report.html --url /src/MyProj=http://buildserver/src/MyProj
Other Command Line Options
to get information on the available arguments.
NOTE: This document was written when lint was first released. The Eclipse integration has since been improved significantly. For more up to date details, see New Eclipse Lint UI
Lint is integrated with ADT 16 and later. The integration offers a few features above the command line version of lint:
- Automatic fixes for many warnings
- Lint gets run automatically on various editing operations
- Ability to suppress types of errors as well as specific instances of an error
- Ability to configure issue severities
- Jump directly to the problem source from the lint view
Lint will be run automatically when you:
- Export an APK. In this case it runs lint in a special mode which only looks for fatal errors (which is faster) and aborts the export if any fatal errors are found. You can turn off this in the Lint Options.
- Edit and Save and XML file, such as a layout file or a manifest file. In this case, all the file-scope checks that apply to the given file are run and editor markers are added for any issues found.
- Use the layout editor. After every UI operation, file-scope checks (such as the various layoutopt rules) are run on the layout file and the results are shown in a special lint window (which can be opened from the error marker which shows in the top right corner of the layout editor when errors are found).
To run Lint on a project, select the project in the package explorer and click on the Lint toolbar action (see image on the right).
Alternatively you can right click on the project and in the Android Tools sub menu, there is a “Run Lint” action. This will open a Lint Window which contains the various errors. Selecting an error will show the associated explanation in the text area on the right.
You can double click on errors in the lint view to jump to the associated source location, if any. The icon of each warning will indicate its severity, and for warnings which have fixes (see next section) there is a small light bulb overlay.
The window also has an action bar (in the upper right hand side corner), which lets you
- Run the lint checks again to refresh the results (which turns into a Stop button during the refresh if you want to abort it)
- Run the fix associated with this error, if any
- Ignore this fix
- Remove the warning marker
- Remove all warning markers
Many lint warnings have automatic fixes. For example, the various layoutopt fixes suggest replacements (e.g. replace wrap_content with 0dp).
- From the lint view, click the lightbulb to invoke a fix.
- From the layout editor warning summary, click the Fix button to fix.
- And from the XML source editor, invoke the Quick Fix (Ctrl-1 or Command-1) and pick the quick fix associated with the warning.
From the editor quick fix menu, you can also choose to
- Ignore the warning in this file only
- Ignore the warning in this project
- Ignore the warning, period.
- Ignore warnings using annotations or attributes, as explained here.
(If you do not see the lint fix action in the quickfix list, see the Known Bugs section)
These choices are stored in a file named
in the project, which is also read by the command line tool. Thus, you can ignore warnings from the UI, and check in the
file with your source projects, and others running lint will not see warnings you have ignored (presumably because they have been manually verified).
To edit the global lint options, which are the fallback options used for all projects, invoke the normal Eclipse options dialog and choose Android > Lint Options:
If you select an issue, you can edit its Severity in the dropdown on the bottom right. This lets you designate certain issues as Errors for example (which will abort Export APK if the option near the top of the dialog is enabled).
To turn off an issue check completely, choose “Ignore” as the severity.Note that this does not edit the per-project lint settings
. Open the Project settings dialog (right click on the project), where you’ll find a property page for Android Lint. Manual severity edits in the options dialog are also recorded in the
file along with suppressed errors, so others in your team will get the same severity designations you edit for the project.