Tips‎ > ‎Android Lint‎ > ‎

    Suppressing Lint Warnings

    While Lint can often find real errors that must be fixed, it also flags issues that may or may not be a problem depending on the context. If you've manually verified that an issue is not a problem, you may want to mark the issue as verified such that lint does not keep pointing it out.

    In Source

    You can suppress lint issues directly in the source code. This has the advantage that you filter only this specific occurrence of the lint issue (that you've presumably manually verified), not all occurrences of a particular issue type, or all occurrences in a file.

    With Annotations

    In .java files, you can suppress issues with the @SuppressLint annotations. You supply the lint issue id as the argument to the annotations.

    For example
    @SuppressLint("NewApi")
    public void onGlobalLayout() {
        ....

    You can also suppress more than one issue using a comma separated list:
    @SuppressLint({"NewApi","StringFormatInvalid"})

    In both Android Studio and Eclipse you can easily suppress lint issues directly without having to write the annotation yourself. Just invoke the quickfix for the warning, and one of the options will be to ignore the issue with an annotation; this will annotate either the local declaration, or the method, or the class, or the field, depending on the location of the error. (Some screenshots of this in action in Eclipse is shown here.)

    In .xml files, you suppress issues with the special tools:ignore attribute instead.
    <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools">
        ....
        <LinearLayout 
          tools:ignore="MergeRootFrame"
        ...
    Tip: You can supply a comma separated list of issue id's, or the special value "all" to indicate all issues.

    In Source: With Comments

    In recent versions of lint, you can also use a special line comment on the line above the error to suppress a warning.

    In .java and .gradle files, use a comment line this (where again the issue id can be a comma separated list of id's). You can prefix the id with "AndroidLint", which is allowed for consistency with the way IntelliJ disables inspections in comments.) 
        //noinspection AndroidLintSdCardPath
        String path = "/sdcard/legacy.txt";
    In XML files, the comment should look like this:
    <!--suppress AndroidLintHardcodedText -->

    (Again, you can supply a comma separated list of issue ids instead of a single id.)

    In Build File: With Gradle Configuration

    In Gradle files, you can specify a lintOptions configuration where you can disable id's, enable id's, as well as change the severity of issue id's (including to "ignore" to disable them).
    android {
        lintOptions {
            disable 'TypographyFractions','TypographyQuotes'
            ...
        }
    }

    From Command Line

    The lint command has three commands for controlling which checks are performed: --enable, --disable and --check (see the overview document for more details on these flags). However, these must be specified each time you run lint. This is similar to the lintOptions for Gradle above.

    Config File: lint.xml

    To persistently configure which rules are run, you can create a file named lint.xml in the root directory of your project (next to the manifest file). Lint will automatically look at this file and use it to ignore warnings. Gradle, Android Studio and Eclipse will also use this configuration file if present. Note that when you use Eclipse to suppress errors, it automatically creates this file for you, so you can use Eclipse to ignore warnings and then check in the resulting configuration file such that for example build server lint runs will ignore warnings you've manually verified.

    Here's a sample lint.xml file (the comments are obviously not needed; I've added them here to explain what each line does)

    <?xml version="1.0" encoding="UTF-8"?>
    <lint>
        <!-- Disable the given check in this project -->
        <issue id="IconMissingDensityFolder" severity="ignore" />

        <!-- Ignore the ObsoleteLayoutParam issue in the given files -->
        <issue id="ObsoleteLayoutParam">
            <ignore path="res/layout/activation.xml" />
            <ignore path="res/layout-xlarge/activation.xml" />
        </issue>

        <!-- Ignore the UselessLeaf issue in the given file -->
        <issue id="UselessLeaf">
            <ignore path="res/layout/main.xml" />
        </issue>

        <!-- Change the severity of hardcoded strings to "error" -->
        <issue id="HardcodedText" severity="error" />
    </lint>

    In recent versions of lint (Gradle plugin 0.9+, SDK Tools 27+, Android Studio 0.5+) you can use a globbing pattern for the path:
    <issue id="ObsoleteLayoutParam">
        <ignore path="res/**/activation.xml" />

    You can also specify a full regular expression, by using a regexp attribute instead of path:
        <ignore regexp="res/.*/activation.xml" />

    You can also use "all" as the issue id if you want to apply settings for all issues.

    Issue Id's

    The issue identifiers used to suppress issues as shown above (IconMissingDensityFolder, ObsoleteLayoutParam etc) are the issue ids, which are included in the error output from the lint command:

    Warning: The resource R.drawable.robot appears to be unused [UnusedResources]

    You can also look up the lint ids with the lint --show command (for full details) or lint --list (for a brief summary):
    $ lint --list
    ...
    "ContentDescription": Ensures that image widgets provide a contentDescription
    "DuplicateIncludedIds": Checks for duplicate ids across layouts that are
          combined with include tags
    "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
    "NestedWeights": Looks for nested layout weights, which are costly
    ...

    This lint configuration file apply to the current project, as well as any library projects included into this project. If you want to also have a "global" configuration used for all projects, you can create an additional global file and then invoke lint with the --config flag:

    --config <filename>      Use the given configuration file to determine whether
                             issues are enabled or disabled. If a project contains
                             a lint.xml file, then this config file will be used
                             as a fallback.

    From Android Studio

    You can configure lint severities from the global inspections menu. However, these will only be used inside Studio itself. If you want the Gradle command line build and other users to see your altered severities, use a lint.xml file or a Gradle lintOptions configuration instead.

    To suppress an error, open the issue in the editor and run the quickfix/intentions action (Ctrl/Cmd F1) and select Suppress which will use annotations, attributes or comments to disable the issue.

      From Eclipse

      If you're using the Eclipse Lint plugin, you can suppress errors directly from the Lint Window. There are three separate ignore levels:
      • Always ignore. This completely suppresses the given warning. Use this for warnings you never want flagged.
      • Ignore in project. This will ignore this warning in the current project (and any library projects referenced from this project).
      • Ignore in file. This will ignore this warning anywhere in the current file, but not in any other files.
      • (Ignore warnings within a class, method or even for a specific variable declaration, using annotations or attributes: See this document for more information.)
      You can also access these from the quickfix menu in XML editors, and the first two from the Global Options dialog and from the Project Options dialog.

      Project and file specific warnings are written into lint.xml files into the projects, so command line and build server lint runs will pick these up.
      Comments