Android - 抑制lint的Android XML的警告：tools:ignore

xmlns:tools="http://schemas.android.com/tools"
tools:ignore=“all”

$ 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.

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

Priority: 9 / 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

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.

MissingRegistered
-----------------
Summary: Ensures that classes referenced in the manifest are present in the
project or libraries

Priority: 8 / 10
Severity: Error
Category: Correctness

If a class is referenced in the manifest, it must also exist in the project
(or in one of the libraries included by the project. This check helps uncover
typos in registration names, or attempts to rename or move classes without
updating the manifest file properly.

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

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.

WrongFolder
-----------
Summary: Finds resource files that are placed in the wrong folders

Priority: 8 / 10
Severity: Error
Category: Correctness

Resource files are sometimes placed in the wrong folder, and it can lead to
subtle bugs that are hard to understand. This check looks for problems in this
area, such as attempting to place a layout "alias" file in a layout/ folder
rather than the values/ folder where it belongs.

DalvikOverride
--------------
Summary: Looks for methods treated as overrides by Dalvik

Priority: 7 / 10
Severity: Error
Category: Correctness

The Android virtual machine will treat a package private method in one class
as overriding a package private method in its super class, even if they are in
separate packages. This may be surprising, but for compatibility reasons the
behavior has not been changed (yet).

If you really did intend for this method to override the other, make the
method protected instead.

If you did not intend the override, consider making the method private, or
changing its name or signature.

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.

CommitPrefEdits
---------------
Summary: Looks for code editing a SharedPreference but forgetting to call
commit() on it

Priority: 6 / 10
Severity: Warning
Category: Correctness

After calling edit() on a SharedPreference, you must call commit() or apply()
on the editor to save the results.

DefaultLocale
-------------
Summary: Finds calls to locale-ambiguous String manipulation methods

Priority: 6 / 10
Severity: Warning
Category: Correctness

Calling String#toLowerCase() or #toUpperCase() without specifying an explicit
locale is a common source of bugs. The reason for that is that those methods
will use the current locale on the user‘s device, and even though the code
appears to work correctly when you are developing the app, it will fail in
some locales. For example, in the Turkish locale, the uppercase replacement
for i is not I.

If you want the methods to just perform ASCII replacement, for example to
convert an enum name, call String#toUpperCase(Locale.US) instead. If you
really want to use the current locale, call
String#toUpperCase(Locale.getDefault()) instead.

More information: http://developer.android.com/reference/java/util/Locale.html#default_locale

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.

Instantiatable
--------------
Summary: Ensures that classes registered in the manifest file are
instantiatable

Priority: 6 / 10
Severity: Warning
Category: Correctness

Activities, services, broadcast receivers etc. registered in the manifest file
must be "instiantable" by the system, which means that the class must be
public, it must have an empty public constructor, and if it‘s an inner class,
it must be a static inner class.

LibraryCustomView
-----------------
Summary: Flags custom attributes in libraries, which must use the
res-auto-namespace instead

Priority: 6 / 10
Severity: Error
Category: Correctness

When using a custom view with custom attributes in a library project, the
layout must use the special namespace http://schemas.android.com/apk/res-auto
instead of a URI which includes the library project‘s own package. This will
be used to automatically adjust the namespace of the attributes when the
library resources are merged into the application project.

MissingPrefix
-------------
Summary: Detect XML attributes not using the Android namespace

Priority: 6 / 10
Severity: Error
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.

Similarly, in manifest files, nearly all attributes should be in the android:
namespace.

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

Priority: 6 / 10
Severity: Fatal
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 you really want to use this API and don‘t need to support older devices
just set the minSdkVersion in your AndroidManifest.xml file.
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.

OldTargetApi
------------
Summary: Checks that the manifest specifies a targetSdkVersion that is recent

Priority: 6 / 10
Severity: Warning
Category: Correctness

When your application runs on a version of Android that is more recent than
your targetSdkVersion specifies that it has been tested with, various
compatibility modes kick in. This ensures that your application continues to
work, but it may look out of place. For example, if the targetSdkVersion is
less than 14, your app may get an option button in the UI.

To fix this issue, set the targetSdkVersion to the highest available value.
Then test your app to make sure everything works correctly. You may want to
consult the compatibility notes to see what changes apply to each version you
are adding support for:
http://developer.android.com/reference/android/os/Build.VERSION_CODES.html

More information: http://developer.android.com/reference/android/os/Build.VERSION_CODES.html

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

ShowToast
---------
Summary: Looks for code creating a Toast but forgetting to call show() on it

Priority: 6 / 10
Severity: Warning
Category: Correctness

Toast.makeText() creates a Toast but does not show it. You must call show() on
the resulting object to actually make the Toast appear.

SimpleDateFormat
----------------
Summary: Using SimpleDateFormat directly without an explicit locale

Priority: 6 / 10
Severity: Warning
Category: Correctness

Almost all callers should use getDateInstance(), getDateTimeInstance(), or
getTimeInstance() to get a ready-made instance of SimpleDateFormat suitable
for the user‘s locale. The main reason you‘d create an instance this class
directly is because you need to format/parse a specific machine-readable
format, in which case you almost certainly want to explicitly ask for US to
ensure that you get ASCII digits (rather than, say, Arabic digits).

Therefore, you should either use the form of the SimpleDateFormat constructor
where you pass in an explicit locale, such as Locale.US, or use one of the get
instance methods, or suppress this error if really know what you are doing.

More information: http://developer.android.com/reference/java/text/SimpleDateFormat.html

UniquePermission
----------------
Summary: Checks that permission names are unique

Priority: 6 / 10
Severity: Error
Category: Correctness

The unqualified names or your permissions must be unique. The reason for this
is that at build time, the aapt tool will generate a class named Manifest
which contains a field for each of your permissions. These fields are named
using your permission unqualified names (i.e. the name portion after the last
dot).

If more than one permission maps to the same field name, that field will
arbitrarily name just one of them.

ValidFragment
-------------
Summary: Ensures that Fragment subclasses can be instantiated

Priority: 6 / 10
Severity: Warning
Category: Correctness

From the Fragment documentation:
Every fragment must have an empty constructor, so it can be instantiated when
restoring its activity‘s state. It is strongly recommended that subclasses do
not have other constructors with parameters, since these constructors will not
be called when the fragment is re-instantiated; instead, arguments can be
supplied by the caller with setArguments(Bundle) and later retrieved by the
Fragment with getArguments().

More information: http://developer.android.com/reference/android/app/Fragment.html#Fragment()

WrongManifestParent
-------------------
Summary: Checks that various manifest elements are declared in the right
place

Priority: 6 / 10
Severity: Fatal
Category: Correctness

The <uses-library> element should be defined as a direct child of the
<application> tag, not the <manifest> tag or an <activity> tag. Similarly, a
<uses-sdk> tag much be declared at the root level, and so on. This check looks
for incorrect declaration locations in the manifest, and complains if an
element is found in the wrong place.

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

DuplicateActivity
-----------------
Summary: Checks that an activity is registered only once in the manifest

Priority: 5 / 10
Severity: Error
Category: Correctness

An activity should only be registered once in the manifest. If it is
accidentally registered more than once, then subtle errors can occur, since
attribute declarations from the two elements are not merged, so you may
accidentally remove previous declarations.

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.

MissingId
---------
Summary: Ensures that XML tags like <fragment> specify an id or tag attribute

Priority: 5 / 10
Severity: Warning
Category: Correctness

If you do not specify an android:id or an android:tag attribute on a
<fragment> element, then if the activity is restarted (for example for an
orientation rotation) you may lose state. From the fragment documentation:

"Each fragment requires a unique identifier that the system can use to restore
the fragment if the activity is restarted (and which you can use to capture
the fragment to perform transactions, such as remove it). * Supply the
android:id attribute with a unique ID.
* Supply the android:tag attribute with a unique string.
If you provide neither of the previous two, the system uses the ID of the
container view.

More information: http://developer.android.com/guide/components/fragments.html

ProtectedPermissons
-------------------
Summary: Looks for permissions that are only granted to system apps

Priority: 5 / 10
Severity: Error
Category: Correctness

Permissions with the protection level signature or signatureOrSystem are only
granted to system apps. If an app is a regular non-system app, it will never
be able to use these permissions.

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.

UnlocalizedSms
--------------
Summary: Looks for code sending text messages to unlocalized phone numbers

Priority: 5 / 10
Severity: Warning
Category: Correctness

SMS destination numbers must start with a country code or the application code
must ensure that the SMS is only sent when the user is in the same country as
the receiver.

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.

InOrMmUsage
-----------
Summary: Looks for use of the "mm" or "in" dimensions

Priority: 4 / 10
Severity: Warning
Category: Correctness

Avoid using mm (millimeters) or in (inches) as the unit for dimensions.

While it should work in principle, unfortunately many devices do not report
the correct true physical density, which means that the dimension calculations
won‘t work correctly. You are better off using dp (and for font sizes, sp.)

RequiredSize
------------
Summary: Ensures that the layout_width and layout_height are specified for all
views

Priority: 4 / 10
Severity: Error
Category: Correctness

All views must specify an explicit layout_width and layout_height attribute.
There is a runtime check for this, so if you fail to specify a size, an
exception is thrown at runtime.

It‘s possible to specify these widths via styles as well. GridLayout, as a
special case, does not require you to specify a size.

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)

InnerclassSeparator
-------------------
Summary: Ensures that inner classes are referenced using ‘$‘ instead of ‘.‘ in
class names

Priority: 3 / 10
Severity: Warning
Category: Correctness

When you reference an inner class in a manifest file, you must use ‘$‘ instead
of ‘.‘ as the separator character, i.e. Outer$Inner instead of Outer.Inner.

(If you get this warning for a class which is not actually an inner class,
it‘s because you are using uppercase characters in your package name, which is
not conventional.)

LocalSuppress
-------------
Summary: Looks for @SuppressLint annotations in locations where it doesn‘t
work for class based checks

Priority: 3 / 10
Severity: Error
Category: Correctness

The @SuppressAnnotation is used to suppress Lint warnings in Java files.
However, while many lint checks analyzes the Java source code, where they can
find annotations on (for example) local variables, some checks are analyzing
the .class files. And in class files, annotations only appear on classes,
fields and methods. Annotations placed on local variables disappear. If you
attempt to suppress a lint error for a class-file based lint check, the
suppress annotation not work. You must move the annotation out to the
surrounding method.

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

SpUsage
-------
Summary: Looks for uses of "dp" instead of "sp" dimensions for text sizes

Priority: 3 / 10
Severity: Warning
Category: Correctness

When setting text sizes, you should normally use sp, or "scale-independent
pixels". This is like the dp unit, but it is also scaled by the user‘s font
size preference. It is recommend you use this unit when specifying font sizes,
so they will be adjusted for both the screen density and the user‘s
preference.

There are cases where you might need to use dp; typically this happens when
the text is in a container with a specific dp-size. This will prevent the text
from spilling outside the container. Note however that this means that the
user‘s font size settings are not respected, so consider adjusting the layout
itself to be more flexible.

More information: http://developer.android.com/training/multiscreen/screendensities.html

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.

MangledCRLF
-----------
Summary: Checks that files with DOS line endings are consistent

Priority: 2 / 10
Severity: Error
Category: Correctness

On Windows, line endings are typically recorded as carriage return plus
newline: \r\n.

This detector looks for invalid line endings with repeated carriage return
characters (without newlines). Previous versions of the ADT plugin could
accidentally introduce these into the file, and when editing the file, the
editor could produce confusing visual artifacts.

More information: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375421

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

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.

If the string should not be translated, you can add the attribute
translatable="false" on the <string> element, or you can define all your
non-translatable strings in a resource file called donottranslate.xml. Or, you
can ignore the issue with a tools:ignore="MissingTranslation" attribute.

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.

Typos
-----
Summary: Looks for typos in messages

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

This check looks through the string definitions, and if it finds any words
that look like likely misspellings, they are flagged.

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

Priority: 6 / 10
Severity: Fatal
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.).

Note that these strings can lead to crashes if the string is looked up on any
locale not providing a translation, so it‘s important to clean them up.

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
========

PackagedPrivateKey
------------------
Summary: Looks for packaged private key files

Priority: 8 / 10
Severity: Warning
Category: Security

In general, you should not package private key files inside your app.

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.

SetJavaScriptEnabled
--------------------
Summary: Looks for invocations of
android.webkit.WebSettings.setJavaScriptEnabled

Priority: 6 / 10
Severity: Warning
Category: Security

Your code should not invoke setJavaScriptEnabled if you are not sure thatyour
app really requires JavaScript support.

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

ExportedContentProvider
-----------------------
Summary: Checks for exported content providers that do not require
permissions

Priority: 5 / 10
Severity: Warning
Category: Security

Content providers are exported by default and any application on the system
can potentially use them to read and write data. If the contentprovider
provides access to sensitive data, it should be protected by specifying
export=false in the manifest or by protecting it with a permission that can be
granted to other applications.

ExportedReceiver
----------------
Summary: Checks for exported receivers that do not require permissions

Priority: 5 / 10
Severity: Warning
Category: Security

Exported receivers (receivers 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 receiver or bind to it.
Without this, any application can use this receiver.

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.

WorldReadableFiles
------------------
Summary: Checks for openFileOutput() and getSharedPreferences() calls passing
MODE_WORLD_READABLE

Priority: 4 / 10
Severity: Warning
Category: Security

There are cases where it is appropriate for an application to write world
readable files, but these should be reviewed carefully to ensure that they
contain no private data that is leaked to other applications.

WorldWriteableFiles
-------------------
Summary: Checks for openFileOutput() and getSharedPreferences() 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.

AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application‘s
manifest

Priority: 3 / 10
Severity: Warning
Category: Security

The allowBackup attribute determines if an application‘s data can be backed up
and restored. It is documented at
http://developer.android.com/reference/android/R.attr.html#allowBackup

By default, this flag is set to true. When this flag is set to true,
application data can be backed up and restored by the user using adb backup
and adb restore.

This may have security consequences for an application. adb backup allows
users who have enabled USB debugging to copy application data off of the
device. Once backed up, all application data can be read by the user. adb
restore allows creation of application data from a source specified by the
user. Following a restore, applications should not assume that the data, file
permissions, and directory permissions were created by the application
itself.

Setting allowBackup="false" opts an application out of both backup and
restore.

To fix this warning, decide whether your application should support backup,
and explicitly set android:allowBackup=(true|false)"

More information: http://developer.android.com/reference/android/R.attr.html#allowBackup

ExportedActivity
----------------
Summary: Checks for exported activities that do not require permissions

Priority: 2 / 10
Severity: Warning
Category: Security

Exported activities (activities 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 activity or bind to it.
Without this, any application can use this activity.

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.

SecureRandom
------------
Summary: Looks for suspicious usage of the SecureRandom class

Priority: 9 / 10
Severity: Warning
Category: Performance

Specifying a fixed seed will cause the instance to return a predictable
sequence of numbers. This may be useful for testing but it is not appropriate
for secure use.

More information: http://developer.android.com/reference/java/security/SecureRandom.html

Wakelock
--------
Summary: Looks for problems with wakelock usage

Priority: 9 / 10
Severity: Warning
Category: Performance

Failing to release a wakelock properly can keep the Android device in a high
power mode, which reduces battery life. There are several causes of this, such
as releasing the wake lock in onDestroy() instead of in onPause(), failing to
call release() in all possible code paths after an acquire(), and so on.

NOTE: If you are using the lock just to keep the screen on, you should
strongly consider using FLAG_KEEP_SCREEN_ON instead. This window flag will be
correctly managed by the platform as the user moves between applications and
doesn‘t require a special permission. See
http://developer.android.com/reference/android/view/WindowManager.LayoutParams
html#FLAG_KEEP_SCREEN_ON.

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 (a single TextView, using the
drawableTop, drawableLeft, drawableRight and/or drawableBottom attributes to
draw one or more images adjacent to the text).

If the two widgets are offset from each other with margins, this can be
replaced with a drawablePadding attribute.

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

ViewTag
-------
Summary: Finds potential leaks when using View.setTag

Priority: 6 / 10
Severity: Warning
Category: Performance

Prior to Android 4.0, the implementation of View.setTag(int, Object) would
store the objects in a static map, where the values were strongly referenced.
This means that if the object contains any references pointing back to the
context, the context (which points to pretty much everything else) will leak.
If you pass a view, the view provides a reference to the context that created
it. Similarly, view holders typically contain a view, and cursors are
sometimes also associated with views.

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.

NOTE: As of Android 2.3 (Gingerbread), this optimization is performed
automatically by Dalvik, so there is no need to change your code; this is only
relevant if you are targeting older versions of Android.

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

HandlerLeak
-----------
Summary: Ensures that Handler classes do not hold on to a reference to an
outer class

Priority: 4 / 10
Severity: Warning
Category: Performance

In Android, Handler classes should be static or leaks might occur. Messages
enqueued on the application thread‘s MessageQueue also retain their target
Handler. If the Handler is an inner class, its outer class will be retained as
well. To avoid leaking the outer class, declare the Handler as a static nested
class with a WeakReference to its outer class.

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.

UseValueOf
----------
Summary: Looks for usages of "new" for wrapper classes which should use
"valueOf" instead

Priority: 4 / 10
Severity: Warning
Category: Performance

You should not call the constructor for wrapper classes directly, such as`new
Integer(42)`. Instead, call the valueOf factory method, such as
Integer.valueOf(42). This will typically use less memory because common
integers such as 0 and 1 will share a single instance.

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 android.util.FloatMath calls with java.lang.Math

Priority: 3 / 10
Severity: Warning
Category: Performance

In older versions of Android, using android.util.FloatMath was recommended for
performance reasons when operating on floats. However, on modern hardware
doubles are just as fast as float (though they take more memory), and in
recent versions of Android, FloatMath is actually slower than using
java.lang.Math due to the way the JIT optimizes java.lang.Math. Therefore, you
should use Math instead of FloatMath if you are only targeting Froyo and
above.

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.

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

Priority: 1 / 10
Severity: Warning
Category: Performance

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

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" (–, –) and the "m dash" (—, —) 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 (…, …). 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 ? (?) and BC (?). 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.

IconColors
----------
Summary: Checks that icons follow the recommended visual style

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

Notification icons and Action Bar icons should only white and shades of gray.
See the Android Design Guide for more details. Note that the way Lint decides
whether an icon is an action bar icon or a notification icon is based on the
filename prefix: ic_menu_ for action bar icons, ic_stat_ for notification
icons etc. These correspond to the naming conventions documented in
http://developer.android.com/guide/practices/ui_guidelines/icon_design.html

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

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.

IconExtension
-------------
Summary: Checks that the icon file extension matches the actual image format
in the file

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

Ensures that icons have the correct file extension (e.g. a .png file is really
in the PNG format and not for example a GIF file named .png.)

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

MenuTitle
---------
Summary: Ensures that all menu items supply a title

Priority: 5 / 10
Severity: Warning
Category: Usability

From the action bar documentation:
"It‘s important that you always define android:title for each menu item — even
if you don‘t declare that the title appear with the action item — for three
reasons:

* If there‘s not enough room in the action bar for the action item, the menu
item appears in the overflow menu and only the title appears.
* Screen readers for sight-impaired users read the menu item‘s title.
* If the action item appears with only the icon, a user can long-press the
item to reveal a tool-tip that displays the action item‘s title.
The android:icon is always optional, but recommended.

More information: http://developer.android.com/guide/topics/ui/actionbar.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.

The lint detector also looks at the id of the view, and if the id offers a
hint of the purpose of the field (for example, the id contains the phrase
phone or email), then lint will also ensure that the inputType contains the
corresponding type attributes.

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.

LabelFor
--------
Summary: Ensures that text fields are marked with a labelFor attribute

Priority: 2 / 10
Severity: Warning
Category: Accessibility

Text fields should be labelled with a labelFor attribute, provided your
minSdkVersion is at least 17.

If your view is labeled but by a label in a different layout which includes
this one, just suppress this warning from lint.

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.