Logo Icon Logo
A Crowd-sourced Cookbook on Writing Great Android® Apps
GitHub logo Twitter logo OReilly Book Cover Art

Static Code Testing with Android Lint

Author: Ian Darwin
Published? true
FormatLanguage: WikiFormat


Your code looks OK, but you want to see if it passes muster when subjected to expert scrutiny.


Run your code through Android Lint (included with modern versions of the Android SDK and supported by the relevant versions of the ADT Plugin). Examine the warnings, and improve the code where it needs it.


The first "Lint" program originated on Seventh Edition Research Unix at Bell Laboratories. Steve Johnson wrote it as an offshoot of his development of the first Portable C Compiler, in the late 1970's. It is covered in my little book "Checking C Programs with Lint" (O'Reilly. Ever since, people have been writing lint-like tools. Some well-known ones for Java code include PMD, FindBugs, and CheckStyle. The first two, plus a number of other tools, are covered in my 2007 book "Checking Java Programs." The most recent one that's relevant to us is, of course, AndroidLint, a part of the standard Android SDK.

What each of these tools does is examine your code, and offer opinions based on expert-level knowledge of the language and libraries. The hard part is to bear in mind that they are only opinions. There will be cases where you think you know better than the tool, and you later find out that you're wrong. But there will be cases where you're right. And, of course, it's an impossibly-hard problem for the computer to know which, so there is no substitute for the judgement of an experienced developer!

These tools typically find a lot of embarassing issues in your code the first time you run time. One very common error is to create a Toast by calling makeText(), and forget to call the new Toast's show() method; the toast is created but never pops up! The standard compiler cannot catch this kind of error, but Android Lint can, and that is just one of its many capabilities. After laughing at yourself for a minute, you edit (and test!) your code, and run lint again. You repeat this process until you no longer get any messages that you care about.

To run Android Lint, you can use the command-line version in $SDK_HOME/tools/lint. Or, you can run it under Eclipse. Just right-click on the project. Select Android Tools -> Run Lint: Check for Common Errors. The warnings appear as code markers just like the ones form Eclipse itself. Since they are not managed by the Eclipse compiler, you may need to run lint again after editing your code. If you get tired of the game, you can use the same menu to remove the lint markers.

Here is an example of running the command line version:

$ cd MyAndroidProject
$ lint .

Scanning .: ......
Scanning . (Phase 2): ..
AndroidManifest.xml:16: Warning: <uses-sdk> tag should specify a target API level (the
 highest verified version; when running on later versions, compatibility behaviors may be
 enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
    <uses-sdk android:minSdkVersion="7" />
AndroidManifest.xml:16: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder]
    <uses-sdk android:minSdkVersion="7" />
AndroidManifest.xml:6: Warning: Should explicitly set android:allowBackup to true or false
 (it's true by default, and that can have some security implications for the
 application's data) [AllowBackup]
    <application android:icon="@drawable/icon" android:label="@string/app_name">
res/values/strings.xml:5: Warning: The resource R.string.addAccounrSuccess appears to
 be unused [UnusedResources]
    <string name="addAccounrSuccess">Account created</string>
res/values/strings.xml:6: Warning: The resource R.string.addAccounrFailure appears to be
 unused [UnusedResources]
    <string name="addAccounrFailure">Account creation failed</string>
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 6 warnings

Nothing serious found in this project, but several things that can be cleaned up quickly and easily. Of course the unused string resources don't need any action if they are intended for future use, but if they are old and have fallen out of use, you should remove them to keep your app "mean and clean". As with any automated tool, you know your app better than the tool does, at least for making such decisions.

See Also:


O'Reilly page on my Lint book and on my Checking Java Programs book.

No records found.