../../build.gradle:13: Not targeting the latest versions of Android; compatibility modes apply. Consider testing and updating this version. Consult the android.os.Build.VERSION_CODES javadoc for details.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Priority: 6 / 10
Category: Correctness
Severity: Warning
Explanation: Target SDK attribute is not targeting latest version.
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
Explanation: Value overridden by Gradle build script.
The value of (for example) minSdkVersion is only used if it is not specified in the build.gradle build scripts. When specified in the Gradle build scripts, the manifest value is ignored and can be misleading, so should be removed to avoid ambiguity.
../../AndroidManifest.xml:9: Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
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)"
../../res/layout/activity_ad_sample.xml:21: Possible overdraw: Root element paints background #E4E5E8 with a theme that also paints a background (inferred theme is @android:style/Theme.Holo)
Explanation: Overdraw: Painting regions more than once.
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.
../../res: Missing density variation folders in res: drawable-xxxhdpi
Priority: 3 / 10
Category: Usability:Icons
Severity: Warning
Explanation: Missing density folder.
Icons will look best if a custom version is provided for each of the major screen density classes (low, medium, high, extra-high, extra-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
../../res/layout/fragment_interstitial.xml:27: Buttons in button bars should be borderless; use style="?android:attr/buttonBarButtonStyle" (and ?android:attr/buttonBarStyle on the parent)
../../res/layout/fragment_interstitial.xml:35: Buttons in button bars should be borderless; use style="?android:attr/buttonBarButtonStyle" (and ?android:attr/buttonBarStyle on the parent)
Button bars typically use a borderless style for the buttons. Set the style="?android:attr/buttonBarButtonStyle" attribute on each of the buttons, and set style="?android:attr/buttonBarStyle" on the parent layout
The following issues were not run by lint, either because the check is not enabled by default, or because it was disabled with a command line flag or via one or more lint.xml configuration files in the project directories.
"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.
An "easter egg" is code deliberately hidden in the code, both from potential users and even from other developers. This lint check looks for code which looks like it may be hidden from sight.
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.
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.
Margin values should be positive. Negative values are generally a sign that you are making assumptions about views surrounding the current one, or may be tempted to turn off child clipping to allow a view to escape its parent. Turning off child clipping to do this not only leads to poor graphical performance, it also results in wrong touch event handling since touch events are based strictly on a chain of parent-rect hit tests. Finally, making assumptions about the size of strings can lead to localization problems.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Default
Priority: 4 / 10
Category: Correctness
Severity: Warning
Explanation: Newer Library Versions Available.
This detector checks with a central repository to see if there are newer versions available for the dependencies used by this project.
This is similar to the GradleDependency check, which checks for newer versions available in the Android SDK tools and libraries, but this works with any MavenCentral dependency, and connects to the library every time, which makes it more flexible but also much slower.
More info:
To suppress this error, use the issue id "NewerVersionAvailable" as explained in the Suppressing Warnings and Errors section.
SelectableText
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Default
Priority: 7 / 10
Category: Usability
Severity: Warning
Explanation: Dynamic text should probably be selectable.
If a <TextView> is used to display data, the user might want to copy that data and paste it elsewhere. To allow this, the <TextView> should specify android:textIsSelectable="true".
This lint check looks for TextViews which are likely to be displaying data: views whose text is set dynamically. This value will be ignored on platforms older than API 11, so it is okay to set it regardless of your minSdkVersion.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Default
Priority: 10 / 10
Category: Correctness
Severity: Warning
Explanation: Code contains STOPSHIP marker.
Using the comment // STOPSHIP can be used to flag code that is incomplete but checked in. This comment marker can be used to indicate that the code should not be shipped until the issue is addressed, and lint will look for these.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Default
Priority: 5 / 10
Category: Usability:Typography
Severity: Warning
Explanation: Straight quotes can be replaced with curvy quotes.
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.)
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.
Lint errors can be suppressed in a variety of ways:
1. With a @SuppressLint annotation in the Java code
2. With a tools:ignore attribute in the XML file
3. With a lint.xml configuration file in the project
4. With a lint.xml configuration file passed to lint via the --config flag
5. With the --ignore flag passed to lint.
To suppress a lint warning with an annotation, add a @SuppressLint("id") annotation on the class, method or variable declaration closest to the warning instance you want to disable. The id can be one or more issue id's, such as "UnusedResources" or {"UnusedResources","UnusedIds"}, or it can be "all" to suppress all lint warnings in the given scope.
To suppress a lint warning in an XML file, add a tools:ignore="id" attribute on the element containing the error, or one of its surrounding elements. You also need to define the namespace for the tools prefix on the root element in your document, next to the xmlns:android declaration:
* xmlns:tools="http://schemas.android.com/tools"
To suppress lint warnings with a configuration XML file, create a file named lint.xml and place it at the root directory of the project in which it applies. (If you use the Eclipse plugin's Lint view, you can suppress errors there via the toolbar and Eclipse will create the lint.xml file for you.).
The format of the lint.xml file is something like the following:
<?xml version="1.0" encoding="UTF-8"?>
<lint>
<!-- Disable this given check in this project -->
<issue id="IconMissingDensityFolder" severity="ignore" />
<!-- Ignore the ObsoleteLayoutParam issue in the given files -->
<issue id="ObsoleteLayoutParam">
<ignore path="res/layout/activation.xml" />
<ignore path="res/layout-xlarge/activation.xml" />
</issue>
<!-- Ignore the UselessLeaf issue in the given file -->
<issue id="UselessLeaf">
<ignore path="res/layout/main.xml" />
</issue>
<!-- Change the severity of hardcoded strings to "error" -->
<issue id="HardcodedText" severity="error" />
</lint>
To suppress lint checks from the command line, pass the --ignore flag with a comma separated list of ids to be suppressed, such as:
"lint --ignore UnusedResources,UselessLeaf /my/project/path"