Android Lint

Lint 是Android ADT 16引入的优化工具，它可以扫描你的代码，帮助发现潜在的问题，例如：
     1.文本国际化（有些文本缺少其它语言版本）例如：layout文件中编写不规范的地方，会给出提示。考虑到国际化，如果直接在xml中写汉字会提醒你把文字写到string配置文件中

     2.Layout的性能问题 

     3.无用的多余的资源 例如：项目中有哪些资源文件引入了却没有在代码中使用的话，会给提示。既包括图片资源、layout文件，也有定义的String常量和Color常量等。考虑到屏幕适配，如果有些图片只在高分辨率中放置了，会提醒你应该在中低分辨率的文件夹下也应该放置一份。 
     4.不一致的数组大小（在配置文件中）
     5.重复的图标，图片
     6.可用性问题（如没有为EditText指定 InputType）
     7. Manifest xml配置错误。       

        Android Lint，非常强大的静态分析工具，可以帮你查找出代码在很多方面的问题，比如correctness，performance，usability。并且每一个问题都有详细的描述说明为什么这么做不好以及推荐的做法，所以从另外一方面来讲也是一个很好的学习工具，如果对每一项都能够理解并在以后的工作中运用，会对自己的水平提高有很大的帮助。这系列文章中的很多地方都来自于Android Lint。

在装了最新版本的ADT以后，Android Lint就会集成在Eclipse里。运行它很简单，只需要右键点击你的android项目，选择Android Tools->Run Lint: Check For Common Errors就行了。

另外在Eclipse的Preferences里也有Lint的选项。它会默认在你保存文件的时候帮你检查文件代码里的错误，另外在导出apk的时候也会检查，并且在出现fatal错误的时候会终止apk的导出并让你修改错误。

结束检查后，会将结果一条条的显示在Lint Warnings里面。点击其中的某条结果会自动把你定位到该错误出现的文件，可能是java代码，也可能是各种xml资源文件和AndroidManifest.xml文件，这样你就可以非常方便的找到错误并更正。

如果你觉得所有的Android Lint的warning和error都处理了，还剩下一些没有必要处理的，你可以把它们clean掉，否则这些warning和error会一直出现在problems里。

当然，并不是Android Lint发现的所有错误在任何时候都是合理的，你可以根据你的实际情况选择采纳或者忽略。但我强烈建议大家把每个错误里的详细描述都看一下，这是非常好的学习资料，因为这些错误（或者说是建议）可以说是长久以来android开发经验的一个汇总，非常有价值，其价值甚至超过了发现的问题本身。

 

 

Android Lint is a new tool for ADT 16 (and Tools 16) which scans Android project sources for potential bugs. It is available both as a command line tool, as well as integrated with Eclipse. The architecture is deliberately IDE independent so it will hopefully be integrated with other IDEs, with other build tools and with continuous integration systems as well.
Here are some examples of the types of errors that it looks for:
Missing translations (and unused translations)
Layout performance problems (all the issues the old 
layoutopt
tool used to find, and more)
Unused resources
Inconsistent array sizes (when arrays are defined in multiple configurations)
Accessibility and internationalization problems (hardcoded strings, missing contentDescription, etc)
Icon problems (like missing densities, duplicate icons, wrong sizes, etc)
Usability problems (like not specifying an input type on a text field)
Manifest errors
and many more.
New November 24th: We just added some new lint rules.
See this document for a full list of the current checks performed by lint. Lint is still in development, so the list of rules will be increasing. In addition, we have an API in development which will make it possible (and hopefully easy) to add additional custom checks.
For information on how to suppress specific lint warnings, see the suppressing warnings document.
Command Line Usage
There is a command line tool in the SDK tools/ directory called 
lint
.
If you have the SDK 
tools/
directory on your path, you can invoke it as “
lint
”. 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
Disabling Checks
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 
--enable
flag.
Finally, you can specify which exact checks to run with the 
--check
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:
Correctness
Security
Performance
Usability
Usability:Icons
Accessibility
Internationalization
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 
--show
command along with a list of id’s or categories (or no arguments at all to see everything):
$ lint --show MissingPrefix
MissingPrefix
-------------
Summary: Detect XML attributes not using the Android namespace
Priority: 8 / 10
Severity: Warning
Category: Correctness
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
attribute.
HTML Reports
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 
--html filename
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
Run 
lint --help
to get information on the available arguments.
Eclipse Usage
Lint is integrated with ADT 16. 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
Automatic Lint
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).
Lint Window

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

Quick Fixes
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.
Suppressing Errors
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.

(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 
lint.xml
in the project, which is also read by the command line tool. Thus, you can ignore warnings from the UI, and check in the
lint.xml
file with your source projects, and others running lint will not see warnings you have ignored (presumably because they have been manually verified).
Options
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 
lint.xml
file along with suppressed errors, so others in your team will get the same severity designations you edit for the project. 
Installation
We plan to make an early access release of ADT 16 when things settle down a little.
For the impatient the source code is available in the git source code repository, in the 
sdk/lint
folder. (See http://source.android.com/source/downloading.html for instructions, and get the code in the master repository).
Known Bugs
Quick Fix Menu Doesn’t Show: There is a current bug that many XML files in ADT open up with the default Eclipse XML editor instead of our custom Android one. The Quick Fixes only work for Android XML editors (which these files should have opened with). If this happens, right click on the file in the package explorer and use the “Open With” action to reopen the file in one of the Android XML editor types. This issue (21124) should be fixed in ADT 16.
Unused Resources: The unused resource detector may incorrectly consider some resources to be unused. When lint is run from the command line, it just uses some simple string analysis to look for resource references. While it does try to ignore comments and string literals etc, it may still get tripped up. When lint is run inside of Eclipse it uses a parse tree so the results should be more accurate. The plan is to integrate a full parse into the lint core such that it doesn't matter where you run it.
Overdraw Detector: Like the unused detector, this requires analyzing Java code, and this is currently not done with a proper Java parse tree (and unlike the unused resource detector, that's also true when run within Eclipse).