Android Tools Project Site

Search this site
    Tips‎ > ‎

    Android Lint Checks

    Here are the current list of checks that lint performs:

    $ lint --show
    Available issues:

    Correctness
    ===========

    AdapterViewChildren
    -------------------
    Summary: Checks that AdapterViews do not define their children in XML

    Priority: 10 / 10
    Severity: Warning
    Category: Correctness

    AdapterViews such as ListViews must be configured with data from Java code,
    such as a ListAdapter.

    More information: http://developer.android.com/reference/android/widget/AdapterView.html

    OnClick
    -------
    Summary: Ensures that onClick attribute values refer to real methods

    Priority: 10 / 10
    Severity: Error
    Category: Correctness

    The onClick attribute value should be the name of a method in this View's
    context to invoke when the view is clicked. This name must correspond to a
    public method that takes exactly one parameter of type View.

    Must be a string value, using '\;' to escape characters such as '\n' or
    '\uxxxx' for a unicode character.


    SuspiciousImport
    ----------------
    Summary: Checks for 'import android.R' statements, which are usually
    accidental

    Priority: 9 / 10
    Severity: Warning
    Category: Correctness

    Importing android.R is usually not intentional; it sometimes happens when you
    use an IDE and ask it to automatically add imports at a time when your
    project's R class it not present.

    Once the import is there you might get a lot of "confusing" error messages
    because of course the fields available on android.R are not the ones you'd
    expect from just looking at your own R class.


    WrongViewCast
    -------------
    Summary: Looks for incorrect casts to views that according to the XML are of a
    different type

    Priority: 9 / 10
    Severity: Error
    Category: Correctness

    Keeps track of the view types associated with ids and if it finds a usage of
    the id in the Java code it ensures that it is treated as the same type.


    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.


    NamespaceTypo
    -------------
    Summary: Looks for misspellings in namespace declarations

    Priority: 8 / 10
    Severity: Warning
    Category: Correctness

    Accidental misspellings in namespace declarations can lead to some very
    obscure error messages. This check looks for potential misspellings to help
    track these down.


    Proguard
    --------
    Summary: Looks for problems in proguard config files

    Priority: 8 / 10
    Severity: Fatal
    Category: Correctness

    Using -keepclasseswithmembernames in a proguard config file is not correct; it
    can cause some symbols to be renamed which should not be.
    Earlier versions of ADT used to create proguard.cfg files with the wrong
    format. Instead of -keepclasseswithmembernames use -keepclasseswithmembers,
    since the old flags also implies "allow shrinking" which means symbols only
    referred to from XML and not Java (such as possibly CustomViews) can get
    deleted.

    More information: http://http://code.google.com/p/android/issues/detail?id=16384

    ScrollViewCount
    ---------------
    Summary: Checks that ScrollViews have exactly one child widget

    Priority: 8 / 10
    Severity: Warning
    Category: Correctness

    ScrollViews can only have one child widget. If you want more children, wrap
    them in a container layout.


    StyleCycle
    ----------
    Summary: Looks for cycles in style definitions

    Priority: 8 / 10
    Severity: Fatal
    Category: Correctness

    There should be no cycles in style definitions as this can lead to runtime
    exceptions.

    More information: http://developer.android.com/guide/topics/ui/themes.html#Inheritance

    UnknownId
    ---------
    Summary: Checks for id references in RelativeLayouts that are not defined
    elsewhere

    Priority: 8 / 10
    Severity: Fatal
    Category: Correctness

    The "@+id/" syntax refers to an existing id, or creates a new one if it has
    not already been defined elsewhere. However, this means that if you have a
    typo in your reference, or if the referred view no longer exists, you do not
    get a warning since the id will be created on demand. This check catches
    errors where you have renamed an id without updating all of the references to
    it.


    DuplicateIds
    ------------
    Summary: Checks for duplicate ids within a single layout

    Priority: 7 / 10
    Severity: Warning
    Category: Correctness

    Within a layout, id's should be unique since otherwise findViewById() can
    return an unexpected view.


    InconsistentArrays
    ------------------
    Summary: Checks for inconsistencies in the number of elements in arrays

    Priority: 7 / 10
    Severity: Warning
    Category: Correctness

    When an array is translated in a different locale, it should normally have the
    same number of elements as the original array. When adding or removing
    elements to an array, it is easy to forget to update all the locales, and this
    lint warning finds inconsistencies like these.

    Note however that there may be cases where you really want to declare a
    different number of array items in each configuration (for example where the
    array represents available options, and those options differ for different
    layout orientations and so on), so use your own judgement to decide if this is
    really an error.

    You can suppress this error type if it finds false errors in your project.


    NestedScrolling
    ---------------
    Summary: Checks whether a scrolling widget has any nested scrolling widgets
    within

    Priority: 7 / 10
    Severity: Warning
    Category: Correctness

    A scrolling widget such as a ScrollView should not contain any nested
    scrolling widgets since this has various usability issues


    ResourceAsColor
    ---------------
    Summary: Looks for calls to setColor where a resource id is passed instead of
    a resolved color

    Priority: 7 / 10
    Severity: Error
    Category: Correctness

    Methods that take a color in the form of an integer should be passed an RGB
    triple, not the actual color resource id. You must call
    getResources().getColor(resource) to resolve the actual color value first.


    ScrollViewSize
    --------------
    Summary: Checks that ScrollViews use wrap_content in scrolling dimension

    Priority: 7 / 10
    Severity: Warning
    Category: Correctness

    ScrollView children must set their layout_width or layout_height attributes to
    wrap_content rather than fill_parent or match_parent in the scrolling
    dimension


    TextViewEdits
    -------------
    Summary: Looks for TextViews being used for input

    Priority: 7 / 10
    Severity: Warning
    Category: Correctness

    Using a <TextView> to input text is generally an error, you should be using
    <EditText> instead.  EditText is a subclass of TextView, and some of the
    editing support is provided by TextView, so it's possible to set some
    input-related properties on a TextView. However, using a TextView along with
    input attributes is usually a cut & paste error. To input text you should be
    using <EditText>.
    This check also checks subclasses of TextView, such as Button and CheckBox,
    since these have the same issue: they should not be used with editable
    attributes.


    DuplicateIncludedIds
    --------------------
    Summary: Checks for duplicate ids across layouts that are combined with
    include tags

    Priority: 6 / 10
    Severity: Warning
    Category: Correctness

    It's okay for two independent layouts to use the same ids. However, if layouts
    are combined with include tags, then the id's need to be unique within any
    chain of included layouts, or Activity#findViewById() can return an unexpected
    view.


    LibraryCustomView
    -----------------
    Summary: Flags custom views in libraries, which currently do not work

    Priority: 6 / 10
    Severity: Error
    Category: Correctness

    Using a custom view in a library project (where the custom view requires XML
    attributes from a custom namespace) does not yet work.


    MultipleUsesSdk
    ---------------
    Summary: Checks that the <uses-sdk> element appears at most once

    Priority: 6 / 10
    Severity: Error
    Category: Correctness

    The <uses-sdk> element should appear just once; the tools will *not* merge the
    contents of all the elements so if you split up the atttributes across
    multiple elements, only one of them will take effect. To fix this, just merge
    all the attributes from the various elements into a single <uses-sdk>
    element.

    More information: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

    NewApi
    ------
    Summary: Finds API accesses to APIs that are not supported in all targeted API
    versions

    Priority: 6 / 10
    Severity: Error
    Category: Correctness

    This check scans through all the Android API calls in the application and
    warns about any calls that are not available on *all* versions targeted by
    this application (according to its minimum SDK attribute in the manifest).

    If your code is *deliberately* accessing newer APIs, and you have ensured
    (e.g. with conditional execution) that this code will only ever be called on a
    supported platform, then you can annotate your class or method with the
    @TargetApi annotation specifying the local minimum SDK to apply, such
    as@TargetApi(11), such that this check considers 11 rather than your manifest
    file's minimum SDK as the required API level.


    Registered
    ----------
    Summary: Ensures that Activities, Services and Content Providers are
    registered in the manifest

    Priority: 6 / 10
    Severity: Warning
    Category: Correctness

    Activities, services and content providers should be registered in the
    AndroidManifext.xml file using <activity>, <service> and <provider> tags.

    If your activity is simply a parent class intended to be subclassed by other
    "real" activities, make it an abstract class.

    More information: http://developer.android.com/guide/topics/manifest/manifest-intro.html

    SdCardPath
    ----------
    Summary: Looks for hardcoded references to /sdcard

    Priority: 6 / 10
    Severity: Warning
    Category: Correctness

    Your code should not reference the /sdcard path directly; instead use
    Environment.getExternalStorageDirectory().getPath()

    More information: http://developer.android.com/guide/topics/data/data-storage.html#filesExternal

    ManifestOrder
    -------------
    Summary: Checks for manifest problems like <uses-sdk> after the <application>
    tag

    Priority: 5 / 10
    Severity: Warning
    Category: Correctness

    The <application> tag should appear after the elements which declare which
    version you need, which features you need, which libraries you need, and so
    on. In the past there have been subtle bugs (such as themes not getting
    applied correctly) when the <application> tag appears before some of these
    other elements, so it's best to order your manifest in the logical dependency
    order.


    StateListReachable
    ------------------
    Summary: Looks for unreachable states in a <selector>

    Priority: 5 / 10
    Severity: Warning
    Category: Correctness

    In a selector, only the last child in the state list should omit a state
    qualifier. If not, all subsequent items in the list will be ignored since the
    given item will match all.


    UnknownIdInLayout
    -----------------
    Summary: Makes sure that @+id references refer to views in the same layout

    Priority: 5 / 10
    Severity: Warning
    Category: Correctness

    The "@+id/" syntax refers to an existing id, or creates a new one if it has
    not already been defined elsewhere. However, this means that if you have a
    typo in your reference, or if the referred view no longer exists, you do not
    get a warning since the id will be created on demand.

    This is sometimes intentional, for example where you are referring to a view
    which is provided in a different layout via an include. However, it is usually
    an accident where you have a typo or you have renamed a view without updating
    all the references to it.


    GridLayout
    ----------
    Summary: Checks for potential GridLayout errors like declaring rows and
    columns outside the declared grid dimensions

    Priority: 4 / 10
    Severity: Fatal
    Category: Correctness

    Declaring a layout_row or layout_column that falls outside the declared size
    of a GridLayout's rowCount or columnCount is usually an unintentional error.


    ExtraText
    ---------
    Summary: Looks for extraneous text in layout files

    Priority: 3 / 10
    Severity: Warning
    Category: Correctness

    Layout resource files should only contain elements and attributes. Any XML
    text content found in the file is likely accidental (and potentially dangerous
    if the text resembles XML and the developer believes the text to be
    functional)


    PrivateResource
    ---------------
    Summary: Looks for references to private resources

    Priority: 3 / 10
    Severity: Fatal
    Category: Correctness

    Private resources should not be referenced; the may not be present everywhere,
    and even where they are they may disappear without notice.

    To fix this, copy the resource into your own project. You can find the
    platform resources under $ANDROID_SK/platforms/android-$VERSION/data/res/.


    ProguardSplit
    -------------
    Summary: Checks for old proguard.cfg files that contain generic Android rules

    Priority: 3 / 10
    Severity: Warning
    Category: Correctness

    Earlier versions of the Android tools bundled a single "proguard.cfg" file
    containing a ProGuard configuration file suitable for Android shrinking and
    obfuscation. However, that version was copied into new projects, which means
    that it does not continue to get updated as we improve the default ProGuard
    rules for Android.

    In the new version of the tools, we have split the ProGuard configuration into
    two halves:
    * A simple configuration file containing only project-specific flags, in your
    project
    * A generic configuration file containing the recommended set of ProGuard
    options for Android projects. This generic file lives in the SDK install
    directory which means that it gets updated along with the tools.

    In order for this to work, the proguard.config property in the
    project.properties file now refers to a path, so you can reference both the
    generic file as well as your own (and any additional files too).

    To migrate your project to the new setup, create a new proguard-project.txt
    file in your project containing any project specific ProGuard flags as well as
    any customizations you have made, then update your project.properties file to
    contain:
    proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-projec
    .txt


    Deprecated
    ----------
    Summary: Looks for usages of deprecated layouts, attributes, and so on.

    Priority: 2 / 10
    Severity: Warning
    Category: Correctness

    Deprecated views, attributes and so on are deprecated because there is a
    better way to do something. Do it that new way. You've been warned.


    PxUsage
    -------
    Summary: Looks for use of the "px" dimension

    Priority: 2 / 10
    Severity: Warning
    Category: Correctness

    For performance reasons and to keep the code simpler, the Android system uses
    pixels as the standard unit for expressing dimension or coordinate values.
    That means that the dimensions of a view are always expressed in the code
    using pixels, but always based on the current screen density. For instance, if
    myView.getWidth() returns 10, the view is 10 pixels wide on the current
    screen, but on a device with a higher density screen, the value returned might
    be 15. If you use pixel values in your application code to work with bitmaps
    that are not pre-scaled for the current screen density, you might need to
    scale the pixel values that you use in your code to match the un-scaled bitmap
    source.

    More information: http://developer.android.com/guide/practices/screens_support.html#screen-independence

    UsesMinSdkAttributes
    --------------------
    Summary: Checks that the minimum SDK and target SDK attributes are defined

    Priority: 2 / 10
    Severity: Warning
    Category: Correctness

    The manifest should contain a <uses-sdk> element which defines the minimum
    minimum API Level required for the application to run, as well as the target
    version (the highest API level you have tested the version for.)

    More information: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

    UnusedNamespace
    ---------------
    Summary: Finds unused namespaces in XML documents

    Priority: 1 / 10
    Severity: Warning
    Category: Correctness

    Unused namespace declarations take up space and require processing that is not
    necessary


    Correctness:Messages
    ====================

    StringFormatInvalid
    -------------------
    Summary: Checks that format strings are valid

    Priority: 9 / 10
    Severity: Error
    Category: Correctness:Messages

    If a string contains a '%' character, then the string may be a formatting
    string which will be passed to String.format from Java code to replace each
    '%' occurrence with specific values.

    This lint warning checks for two related problems:
    (1) Formatting strings that are invalid, meaning that String.format will throw
    exceptions at runtime when attempting to use the format string.
    (2) Strings containing '%' that are not formatting strings getting passed to a
    String.format call. In this case the '%' will need to be escaped as '%%'.

    NOTE: Not all Strings which look like formatting strings are intended for use
    by String.format; for example, they may contain date formats intended for
    android.text.format.Time#format(). Lint cannot always figure out that a String
    is a date format, so you may get false warnings in those scenarios. See the
    suppress help topic for information on how to suppress errors in that case.


    StringFormatMatches
    -------------------
    Summary: Ensures that the format used in <string> definitions is compatible
    with the String.format call

    Priority: 9 / 10
    Severity: Error
    Category: Correctness:Messages

    This lint check ensures the following:
    (1) If there are multiple translations of the format string, then all
    translations use the same type for the same numbered arguments
    (2) The usage of the format string in Java is consistent with the format
    string, meaning that the parameter types passed to String.format matches those
    in the format string.


    MissingTranslation
    ------------------
    Summary: Checks for incomplete translations where not all strings are
    translated

    Priority: 8 / 10
    Severity: Fatal
    Category: Correctness:Messages

    If an application has more than one locale, then all the strings declared in
    one language should also be translated in all other languages.

    By default this detector allows regions of a language to just provide a subset
    of the strings and fall back to the standard language strings. You can require
    all regions to provide a full translation by setting the environment variable
    ANDROID_LINT_COMPLETE_REGIONS.


    ExtraTranslation
    ----------------
    Summary: Checks for translations that appear to be unused (no default language
    string)

    Priority: 6 / 10
    Severity: Warning
    Category: Correctness:Messages

    If a string appears in a specific language translation file, but there is no
    corresponding string in the default locale, then this string is probably
    unused. (It's technically possible that your application is only intended to
    run in a specific locale, but it's still a good idea to provide a fallback.)


    StringFormatCount
    -----------------
    Summary: Ensures that all format strings are used and that the same number is
    defined across translations

    Priority: 5 / 10
    Severity: Warning
    Category: Correctness:Messages

    When a formatted string takes arguments, it usually needs to reference the
    same arguments in all translations. There are cases where this is not the
    case, so this issue is a warning rather than an error by default. However,
    this usually happens when a language is not translated or updated correctly.


    Security
    ========

    GrantAllUris
    ------------
    Summary: Checks for <grant-uri-permission> elements where everything is
    shared

    Priority: 7 / 10
    Severity: Warning
    Category: Security

    The <grant-uri-permission> element allows specific paths to be shared. This
    detector checks for a path URL of just '/' (everything), which is probably not
    what you want; you should limit access to a subset.


    ExportedService
    ---------------
    Summary: Checks for exported services that do not require permissions

    Priority: 5 / 10
    Severity: Warning
    Category: Security

    Exported services (services which either set exported=true or contain an
    intent-filter and do not specify exported=false) should define a permission
    that an entity must have in order to launch the service or bind to it. Without
    this, any application can use this service.


    HardcodedDebugMode
    ------------------
    Summary: Checks for hardcoded values of android:debuggable in the manifest

    Priority: 5 / 10
    Severity: Warning
    Category: Security

    It's best to leave out the android:debuggable attribute from the manifest. If
    you do, then the tools will automatically insert android:debuggable=true when
    building an APK to debug on an emulator or device. And when you perform a
    release build, such as Exporting APK, it will automatically set it to false.

    If on the other hand you specify a specific value in the manifest file, then
    the tools will always use it. This can lead to accidentally publishing your
    app with debug information.


    WorldWriteableFiles
    -------------------
    Summary: Checks for openFileOutput() calls passing MODE_WORLD_WRITEABLE

    Priority: 4 / 10
    Severity: Warning
    Category: Security

    There are cases where it is appropriate for an application to write world
    writeable files, but these should be reviewed carefully to ensure that they
    contain no private data, and that if the file is modified by a malicious
    application it does not trick or compromise your application.


    Performance
    ===========

    DrawAllocation
    --------------
    Summary: Looks for memory allocations within drawing code

    Priority: 9 / 10
    Severity: Warning
    Category: Performance

    You should avoid allocating objects during a drawing or layout operation.
    These are called frequently, so a smooth UI can be interrupted by garbage
    collection pauses caused by the object allocations.

    The way this is generally handled is to allocate the needed objects up front
    and to reuse them for each drawing operation.

    Some methods allocate memory on your behalf (such as Bitmap.create), and these
    should be handled in the same way.


    ObsoleteLayoutParam
    -------------------
    Summary: Looks for layout params that are not valid for the given parent
    layout

    Priority: 6 / 10
    Severity: Warning
    Category: Performance

    The given layout_param is not defined for the given layout, meaning it has no
    effect. This usually happens when you change the parent layout or move view
    code around without updating the layout params. This will cause useless
    attribute processing at runtime, and is misleading for others reading the
    layout so the parameter should be removed.


    UseCompoundDrawables
    --------------------
    Summary: Checks whether the current node can be replaced by a TextView using
    compound drawables.

    Priority: 6 / 10
    Severity: Warning
    Category: Performance

    A LinearLayout which contains an ImageView and a TextView can be more
    efficiently handled as a compound drawable.

    There's a lint quickfix to perform this conversion in the Eclipse plugin.


    FieldGetter
    -----------
    Summary: Suggests replacing uses of getters with direct field access within a
    class

    Priority: 4 / 10
    Severity: Warning
    Category: Performance
    NOTE: This issue is disabled by default!
    You can enable it by adding --enable FieldGetter

    Accessing a field within the class that defines a getter for that field is at
    least 3 times faster than calling the getter. For simple getters that do
    nothing other than return the field, you might want to just reference the
    local field directly instead.

    More information: http://developer.android.com/guide/practices/design/performance.html#internal_get_set

    MergeRootFrame
    --------------
    Summary: Checks whether a root <FrameLayout> can be replaced with a <merge>
    tag

    Priority: 4 / 10
    Severity: Warning
    Category: Performance

    If a <FrameLayout> is the root of a layout and does not provide background or
    padding etc, it can often be replaced with a <merge> tag which is slightly
    more efficient. Note that this depends on context, so make sure you understand
    how the <merge> tag works before proceeding.

    More information: http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html

    UseSparseArrays
    ---------------
    Summary: Looks for opportunities to replace HashMaps with the more efficient
    SparseArray

    Priority: 4 / 10
    Severity: Warning
    Category: Performance

    For maps where the keys are of type integer, it's typically more efficient to
    use the Android SparseArray API. This check identifies scenarios where you
    might want to consider using SparseArray instead of HashMap for better
    performance.

    This is *particularly* useful when the value types are primitives like ints,
    where you can use SparseIntArray and avoid auto-boxing the values from int to
    Integer.

    If you need to construct a HashMap because you need to call an API outside of
    your control which requires a Map, you can suppress this warning using for
    example the @SuppressLint annotation.


    DisableBaselineAlignment
    ------------------------
    Summary: Looks for LinearLayouts which should set
    android:baselineAligned=false

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    When a LinearLayout is used to distribute the space proportionally between
    nested layouts, the baseline alignment property should be turned off to make
    the layout computation faster.


    FloatMath
    ---------
    Summary: Suggests replacing java.lang.Math calls with android.util.FloatMath
    to avoid conversions

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    On modern hardware, "double" is just as fast as "float" though of course it
    takes more memory. However, if you are using floats and you need to compute
    the sine, cosine or square root, then it is better to use the
    android.util.FloatMath class instead of java.lang.Math since you can call
    methods written to operate on floats, so you avoid conversions back and forth
    to double.

    More information: http://developer.android.com/guide/practices/design/performance.html#avoidfloat

    InefficientWeight
    -----------------
    Summary: Looks for inefficient weight declarations in LinearLayouts

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    When only a single widget in a LinearLayout defines a weight, it is more
    efficient to assign a width/height of 0dp to it since it will absorb all the
    remaining space anyway. With a declared width/height of 0dp it does not have
    to measure its own size first.


    NestedWeights
    -------------
    Summary: Looks for nested layout weights, which are costly

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    Layout weights require a widget to be measured twice. When a LinearLayout with
    non-zero weights is nested inside another LinearLayout with non-zero weights,
    then the number of measurements increase exponentially.


    Overdraw
    --------
    Summary: Looks for overdraw issues (where a view is painted only to be fully
    painted over)

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    If you set a background drawable on a root view, then you should use a custom
    theme where the theme background is null. Otherwise, the theme background will
    be painted first, only to have your custom background completely cover it;
    this is called "overdraw".

    NOTE: This detector relies on figuring out which layouts are associated with
    which activities based on scanning the Java code, and it's currently doing
    that using an inexact pattern matching algorithm. Therefore, it can
    incorrectly conclude which activity the layout is associated with and then
    wrongly complain that a background-theme is hidden.

    If you want your custom background on multiple pages, then you should consider
    making a custom theme with your custom background and just using that theme
    instead of a root element background.

    Of course it's possible that your custom drawable is translucent and you want
    it to be mixed with the background. However, you will get better performance
    if you pre-mix the background with your drawable and use that resulting image
    or color as a custom theme background instead.


    UnusedResources
    ---------------
    Summary: Looks for unused resources

    Priority: 3 / 10
    Severity: Warning
    Category: Performance

    Unused resources make applications larger and slow down builds.


    UselessLeaf
    -----------
    Summary: Checks whether a leaf layout can be removed.

    Priority: 2 / 10
    Severity: Warning
    Category: Performance

    A layout that has no children or no background can often be removed (since it
    is invisible) for a flatter and more efficient layout hierarchy.


    UselessParent
    -------------
    Summary: Checks whether a parent layout can be removed.

    Priority: 2 / 10
    Severity: Warning
    Category: Performance

    A layout with children that has no siblings, is not a scrollview or a root
    layout, and does not have a background, can be removed and have its children
    moved directly into the parent for a flatter and more efficient layout
    hierarchy.


    TooDeepLayout
    -------------
    Summary: Checks whether a layout hierarchy is too deep

    Priority: 1 / 10
    Severity: Warning
    Category: Performance

    Layouts with too much nesting is bad for performance. Consider using a flatter
    layout (such as RelativeLayout or GridLayout).The default maximum depth is 10
    but can be configured with the environment variable ANDROID_LINT_MAX_DEPTH.


    TooManyViews
    ------------
    Summary: Checks whether a layout has too many views

    Priority: 1 / 10
    Severity: Warning
    Category: Performance

    Using too many views in a single layout in a layout is bad for performance.
    Consider using compound drawables or other tricks for reducing the number of
    views in this layout.

    The maximum view count defaults to 80 but can be configured with the
    environment variable ANDROID_LINT_MAX_VIEW_COUNT.


    UnusedIds
    ---------
    Summary: Looks for unused id's

    Priority: 1 / 10
    Severity: Warning
    Category: Performance
    NOTE: This issue is disabled by default!
    You can enable it by adding --enable UnusedIds

    This resource id definition appears not to be needed since it is not
    referenced from anywhere. Having id definitions, even if unused, is not
    necessarily a bad idea since they make working on layouts and menus easier, so
    there is not a strong reason to delete these.


    Usability:Typography
    ====================

    TypographyDashes
    ----------------
    Summary: Looks for usages of hyphens which can be replaced by n dash and m
    dash characters

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Typography

    The "n dash" (–, &#8211;) and the "m dash" (—, &#8212;) characters are used
    for ranges (n dash) and breaks (m dash). Using these instead of plain hyphens
    can make text easier to read and your application will look more polished.

    More information: http://en.wikipedia.org/wiki/Dash

    TypographyEllipsis
    ------------------
    Summary: Looks for ellipsis strings (...) which can be replaced with an
    ellipsis character

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Typography

    You can replace the string "..." with a dedicated ellipsis character, ellipsis
    character (…, &#8230;). This can help make the text more readable.

    More information: http://en.wikipedia.org/wiki/Ellipsis

    TypographyFractions
    -------------------
    Summary: Looks for fraction strings which can be replaced with a fraction
    character

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Typography

    You can replace certain strings, such as 1/2, and 1/4, with dedicated
    characters for these, such as ? (&#189;) and BC (&#188;). This can help make
    the text more readable.

    More information: http://en.wikipedia.org/wiki/Number_Forms

    TypographyQuotes
    ----------------
    Summary: Looks for straight quotes which can be replaced by curvy quotes

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Typography
    NOTE: This issue is disabled by default!
    You can enable it by adding --enable TypographyQuotes

    Straight single quotes and double quotes, when used as a pair, can be replaced
    by "curvy quotes" (or directional quotes). This can make the text more
    readable.

    Note that you should never use grave accents and apostrophes to quote, `like
    this'.

    (Also note that you should not use curvy quotes for code fragments.)

    More information: http://en.wikipedia.org/wiki/Quotation_mark

    TypographyOther
    ---------------
    Summary: Looks for miscellaneous typographical problems like replacing (c)
    with ©

    Priority: 3 / 10
    Severity: Warning
    Category: Usability:Typography

    This check looks for miscellaneous typographical problems and offers
    replacement sequences that will make the text easier to read and your
    application more polished.


    Usability:Icons
    ===============

    IconNoDpi
    ---------
    Summary: Finds icons that appear in both a -nodpi folder and a dpi folder

    Priority: 7 / 10
    Severity: Warning
    Category: Usability:Icons

    Bitmaps that appear in drawable-nodpi folders will not be scaled by the
    Android framework. If a drawable resource of the same name appears *both* in a
    -nodpi folder as well as a dpi folder such as drawable-hdpi, then the behavior
    is ambiguous and probably not intentional. Delete one or the other, or use
    different names for the icons.


    GifUsage
    --------
    Summary: Checks for images using the GIF file format which is discouraged

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Icons

    The .gif file format is discouraged. Consider using .png (preferred) or .jpg
    (acceptable) instead.

    More information: http://developer.android.com/guide/topics/resources/drawable-resource.html#Bitmap

    IconDipSize
    -----------
    Summary: Ensures that icons across densities provide roughly the same
    density-independent size

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Icons

    Checks the all icons which are provided in multiple densities, all compute to
    roughly the same density-independent pixel (dip) size. This catches errors
    where images are either placed in the wrong folder, or icons are changed to
    new sizes but some folders are forgotten.


    IconDuplicatesConfig
    --------------------
    Summary: Finds icons that have identical bitmaps across various configuration
    parameters

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Icons

    If an icon is provided under different configuration parameters such as
    drawable-hdpi or -v11, they should typically be different. This detector
    catches cases where the same icon is provided in different configuration
    folder which is usually not intentional.


    IconExpectedSize
    ----------------
    Summary: Ensures that launcher icons, notification icons etc have the correct
    size

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Icons
    NOTE: This issue is disabled by default!
    You can enable it by adding --enable IconExpectedSize

    There are predefined sizes (for each density) for launcher icons. You should
    follow these conventions to make sure your icons fit in with the overall look
    of the platform.

    More information: http://developer.android.com/design/style/iconography.html

    IconLocation
    ------------
    Summary: Ensures that images are not defined in the density-independent
    drawable folder

    Priority: 5 / 10
    Severity: Warning
    Category: Usability:Icons

    The res/drawable folder is intended for density-independent graphics such as
    shapes defined in XML. For bitmaps, move it to drawable-mdpi and consider
    providing higher and lower resolution versions in drawable-ldpi, drawable-hdpi
    and drawable-xhdpi. If the icon *really* is density independent (for example a
    solid color) you can place it in drawable-nodpi.

    More information: http://developer.android.com/guide/practices/screens_support.html

    IconDensities
    -------------
    Summary: Ensures that icons provide custom versions for all supported
    densities

    Priority: 4 / 10
    Severity: Warning
    Category: Usability:Icons

    Icons will look best if a custom version is provided for each of the major
    screen density classes (low, medium, high, extra high). This lint check
    identifies icons which do not have complete coverage across the densities.

    Low density is not really used much anymore, so this check ignores the ldpi
    density. To force lint to include it, set the environment variable
    ANDROID_LINT_INCLUDE_LDPI=true. For more information on current density usage,
    see http://developer.android.com/resources/dashboard/screens.html

    More information: http://developer.android.com/guide/practices/screens_support.html

    IconDuplicates
    --------------
    Summary: Finds duplicated icons under different names

    Priority: 3 / 10
    Severity: Warning
    Category: Usability:Icons

    If an icon is repeated under different names, you can consolidate and just use
    one of the icons and delete the others to make your application smaller.
    However, duplicated icons usually are not intentional and can sometimes point
    to icons that were accidentally overwritten or accidentally not updated.


    IconMissingDensityFolder
    ------------------------
    Summary: Ensures that all the density folders are present

    Priority: 3 / 10
    Severity: Warning
    Category: Usability:Icons

    Icons will look best if a custom version is provided for each of the major
    screen density classes (low, medium, high, extra high). This lint check
    identifies folders which are missing, such as drawable-hdpi.
    Low density is not really used much anymore, so this check ignores the ldpi
    density. To force lint to include it, set the environment variable
    ANDROID_LINT_INCLUDE_LDPI=true. For more information on current density usage,
    see http://developer.android.com/resources/dashboard/screens.html

    More information: http://developer.android.com/guide/practices/screens_support.html

    Usability
    =========

    ButtonOrder
    -----------
    Summary: Ensures the dismissive action of a dialog is on the left and
    affirmative on the right

    Priority: 8 / 10
    Severity: Warning
    Category: Usability

    According to the Android Design Guide,

    "Action buttons are typically Cancel and/or OK, with OK indicating the
    preferred or most likely action. However, if the options consist of specific
    actions such as Close or Wait rather than a confirmation or cancellation of
    the action described in the content, then all the buttons should be active
    verbs. As a rule, the dismissive action of a dialog is always on the left
    whereas the affirmative actions are on the right."

    This check looks for button bars and buttons which look like cancel buttons,
    and makes sure that these are on the left.

    More information: http://developer.android.com/design/building-blocks/dialogs.html

    BackButton
    ----------
    Summary: Looks for Back buttons, which are not common on the Android
    platform.

    Priority: 6 / 10
    Severity: Warning
    Category: Usability
    NOTE: This issue is disabled by default!
    You can enable it by adding --enable BackButton

    According to the Android Design Guide,

    "Other platforms use an explicit back button with label to allow the user to
    navigate up the application's hierarchy. Instead, Android uses the main action
    bar's app icon for hierarchical navigation and the navigation bar's back
    button for temporal navigation."
    This check is not very sophisticated (it just looks for buttons with the label
    "Back"), so it is disabled by default to not trigger on common scenarios like
    pairs of Back/Next buttons to paginate through screens.

    More information: http://developer.android.com/design/patterns/pure-android.html

    TextFields
    ----------
    Summary: Looks for text fields missing inputType or hint settings

    Priority: 5 / 10
    Severity: Warning
    Category: Usability

    Providing an inputType attribute on a text field improves usability because
    depending on the data to be input, optimized keyboards can be shown to the
    user (such as just digits and parentheses for a phone number). Similarly,a
    hint attribute displays a hint to the user for what is expected in the text
    field.

    If you really want to keep the text field generic, you can suppress this
    warning by setting inputType="text".


    AlwaysShowAction
    ----------------
    Summary: Checks for uses of showAsAction="always" and suggests
    showAsAction="ifRoom" instead

    Priority: 3 / 10
    Severity: Warning
    Category: Usability

    Using showAsAction="always" in menu XML, or MenuItem.SHOW_AS_ACTION_ALWAYS in
    Java code is usually a deviation from the user interface style guide.Use
    "ifRoom" or the corresponding MenuItem.SHOW_AS_ACTION_IF_ROOM instead.

    If "always" is used sparingly there are usually no problems and behavior is
    roughly equivalent to "ifRoom" but with preference over other "ifRoom" items.
    Using it more than twice in the same menu is a bad idea.

    This check looks for menu XML files that contain more than two "always"
    actions, or some "always" actions and no "ifRoom" actions. In Java code, it
    looks for projects that contain references to MenuItem.SHOW_AS_ACTION_ALWAYS
    and no references to MenuItem.SHOW_AS_ACTION_IF_ROOM.

    More information: http://developer.android.com/design/patterns/actionbar.html

    ViewConstructor
    ---------------
    Summary: Checks that custom views define the expected constructors

    Priority: 3 / 10
    Severity: Warning
    Category: Usability

    Some layout tools (such as the Android layout editor for Eclipse) needs to
    find a constructor with one of the following signatures:
    * View(Context context)
    * View(Context context, AttributeSet attrs)
    * View(Context context, AttributeSet attrs, int defStyle)

    If your custom view needs to perform initialization which does not apply when
    used in a layout editor, you can surround the given code with a check to see
    if View#isInEditMode() is false, since that method will return false at
    runtime but true within a user interface editor.


    ButtonCase
    ----------
    Summary: Ensures that Cancel/OK dialog buttons use the canonical
    capitalization

    Priority: 2 / 10
    Severity: Warning
    Category: Usability

    The standard capitalization for OK/Cancel dialogs is "OK" and "Cancel". To
    ensure that your dialogs use the standard strings, you can use the resource
    strings @android:string/ok and @android:string/cancel.


    Accessibility
    =============

    ContentDescription
    ------------------
    Summary: Ensures that image widgets provide a contentDescription

    Priority: 3 / 10
    Severity: Warning
    Category: Accessibility

    Non-textual widgets like ImageViews and ImageButtons should use the
    contentDescription attribute to specify a textual description of the widget
    such that screen readers and other accessibility tools can adequately describe
    the user interface.


    Internationalization
    ====================

    HardcodedText
    -------------
    Summary: Looks for hardcoded text attributes which should be converted to
    resource lookup

    Priority: 5 / 10
    Severity: Warning
    Category: Internationalization

    Hardcoding text attributes directly in layout files is bad for several
    reasons:

    * When creating configuration variations (for example for landscape or
    portrait)you have to repeat the actual text (and keep it up to date when
    making changes)

    * The application cannot be translated to other languages by just adding new
    translations for existing string resources.


    EnforceUTF8
    -----------
    Summary: Checks that all XML resource files are using UTF-8 as the file
    encoding

    Priority: 2 / 10
    Severity: Warning
    Category: Internationalization

    XML supports encoding in a wide variety of character sets. However, not all
    tools handle the XML encoding attribute correctly, and nearly all Android apps
    use UTF-8, so by using UTF-8 you can protect yourself against subtle bugs when
    using non-ASCII characters.