Note: This issue has an associated quickfix operation in Eclipse/ADT
Priority: 8 / 10
Category: Correctness:Messages
Severity: Fatal
Explanation: Incomplete translation.
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.
You can tell lint (and other tools) which language is the default language in your res/values/ folder by specifying tools:locale="languageCode" for the root <resources> element in your resource file. (The tools prefix refers to the namespace declaration http://schemas.android.com/tools.)
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.
In Groovy, an integer literal that starts with a leading 0 will be interpreted as an octal number. That is usually (always?) an accident and can lead to subtle bugs, for example when used in the versionCode of an app.
For applications built for API levels below 17, WebView#addJavascriptInterface presents a security hazard as JavaScript on the target web page has the ability to use reflection to access the injected object's public fields and thus manipulate the host application in unintended ways.
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)"
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Usability
Severity: Warning
Explanation: Usage of showAsAction=always
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.
Not all versions of the Android Gradle plugin are compatible with all versions of the SDK. If you update your tools, or if you are trying to open a project that was built with an old version of the tools, you may need to update your plugin version number.
More info:
To suppress this error, use the issue id "AndroidGradlePluginVersion" as explained in the Suppressing Warnings and Errors section.
AppCompatMethod
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Warning
Explanation: Using Wrong AppCompat Method.
When using the appcompat library, there are some methods you should be calling instead of the normal ones; for example, getSupportActionBar() instead of getActionBar(). This lint check looks for calls to the wrong method.
Assertions are not checked at runtime. There are ways to request that they be used by Dalvik (adb shell setprop debug.assert 1), but the property is ignored in many places and can not be relied upon. Instead, perform conditional checking inside if (BuildConfig.DEBUG) { } blocks. That constant is a static final boolean which is true in debug builds and false in release builds, and the Java compiler completely removes all code inside the if-body from the app.
For example, you can replace assert speed > 0 with if (BuildConfig.DEBUG && !(speed > 0)) { throw new AssertionError() }.
(Note: This lint check does not flag assertions purely asserting nullness or non-nullness; these are typically more intended for tools usage than runtime checks.)
"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.
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.
"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.
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
If a View that overrides onTouchEvent or uses an OnTouchListener does not also implement performClick and call it when clicks are detected, the View may not handle accessibility actions properly. Logic handling the click actions should ideally be placed in View#performClick as some accessibility services invoke performClick when a click action should occur.
More info:
To suppress this error, use the issue id "ClickableViewAccessibility" as explained in the Suppressing Warnings and Errors section.
CommitPrefEdits
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Warning
Explanation: Missing commit() on SharedPreference editor.
After calling edit() on a SharedPreference, you must call commit() or apply() on the editor to save the results.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Accessibility
Severity: Warning
Explanation: Image without contentDescription
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.
Note that elements in application screens that are purely decorative and do not provide any content or enable a user action should not have accessibility content descriptions. In this case, just suppress the lint warning with a tools:ignore="ContentDescription" attribute.
The convention for custom views is to use a declare-styleable whose name matches the custom view class name. The IDE relies on this convention such that for example code completion can be offered for attributes in a custom view in layout XML resource files.
(Similarly, layout parameter classes should use the suffix _Layout.)
This lint check looks for cases where you have cut & pasted calls to findViewById but have forgotten to update the R.id field. It's possible that your code is simply (redundantly) looking up the field repeatedly, but lint cannot distinguish that from a case where you for example want to initialize fields prev and next and you cut & pasted findViewById(R.id.prev) and forgot to update the second initialization to R.id.next.
Explanation: Method considered overridden by Dalvik.
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.
Explanation: Implied default locale in case conversion.
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 notI.
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.
If you register a broadcast receiver which acts as a device admin, you must also register an <intent-filter> for the action android.app.action.DEVICE_ADMIN_ENABLED, without any <data>, such that the device admin can be activated/deactivated.
To do this, add <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter>
to your <receiver>.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Performance
Severity: Warning
Explanation: Missing baselineAligned attribute.
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.
More info:
To suppress this error, use the issue id "DisableBaselineAlignment" as explained in the Suppressing Warnings and Errors section.
Explanation: Memory allocations within drawing code.
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.
You can define a resource multiple times in different resource folders; that's how string translations are done, for example. However, defining the same resource more than once in the same resource folder is likely an error, for example attempting to add a new resource without realizing that the name is already used, and so on.
Explanation: Duplicate ids across layouts combined with include tags.
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.
More info:
To suppress this error, use the issue id "DuplicateIncludedIds" as explained in the Suppressing Warnings and Errors section.
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.
Explanation: Content provider does not require permission.
Content providers are exported by default and any application on the system can potentially use them to read and write data. If the content provider 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.
More info:
To suppress this error, use the issue id "ExportedContentProvider" as explained in the Suppressing Warnings and Errors section.
Explanation: Receiver does not require permission.
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Security
Severity: Warning
Explanation: Exported service does not require permission.
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.
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)
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.
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.
Cipher#getInstance should not be called with ECB as the cipher mode or without setting the cipher mode because the default mode on android is ECB, which is insecure.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 8 / 10
Category: Correctness
Severity: Error
Explanation: Incompatible Gradle Versions.
There are some combinations of libraries, or tools and libraries, that are incompatible, or can lead to bugs. One such incompatibility is compiling with a version of the Android support libraries that is not the latest version (or in particular, a version lower than your targetSdkVersion.)
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 4 / 10
Category: Correctness
Severity: Warning
Explanation: Obsolete Gradle Dependency.
This detector looks for usages of libraries where the version you are using is not the current stable release. Using older versions is fine, and there are cases where you deliberately want to stick with an older version. However, you may simply not be aware that a more recent version is available, and that is what this lint check helps find.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 4 / 10
Category: Correctness
Severity: Warning
Explanation: Gradle Dynamic Version.
Using + in dependencies lets you automatically pick up the latest available version rather than a specific, named version. However, this is not recommended; your builds are not repeatable; you may have tested with a slightly different version than what the build server used. (Using a dynamic version as the major version number is more problematic than using it in the minor version position.)
More info:
To suppress this error, use the issue id "GradleDynamicVersion" as explained in the Suppressing Warnings and Errors section.
Gradle will let you replace specific constants in your build scripts with method calls, so you can for example dynamically compute a version string based on your current version control revision number, rather than hardcoding a number.
When computing a version name, it's tempting to for example call the method to do that getVersionName. However, when you put that method call inside the defaultConfig block, you will actually be calling the Groovy getter for the versionName property instead. Therefore, you need to name your method something which does not conflict with the existing implicit getters. Consider using compute as a prefix instead of get.
Gradle is highly flexible, and there are things you can do in Gradle files which can make it hard or impossible for IDEs to properly handle the project. This lint check looks for constructs that potentially break IDE support.
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.
Gradle build scripts are meant to be cross platform, so file paths use Unix-style path separators (a forward slash) rather than Windows path separators (a backslash). Similarly, to keep projects portable and repeatable, avoid using absolute paths on the system; keep files within the project instead. To share code between projects, consider creating an android-library and an AAR dependency
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.
Since this Handler is declared as an inner class, it may prevent the outer class from being garbage collected. If the Handler is using a Looper or MessageQueue for a thread other than the main thread, then there is no issue. If the Handler is using the Looper or MessageQueue of the main thread, you need to fix your Handler declaration, as follows: Declare the Handler as a static class; In the outer class, instantiate a WeakReference to the outer class and pass this object to your Handler when you instantiate the Handler; Make all references to members of the outer class using the WeakReference object.
Note: This issue has an associated quickfix operation in Eclipse/ADT
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Internationalization
Severity: Warning
Explanation: Hardcoded text.
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.
In Android Studio and Eclipse there are quickfixes to automatically extract this hardcoded string into a resource lookup.
Explanation: Icon colors do not follow the recommended visual style.
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
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
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.
Explanation: Duplicated icons under different names.
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.
Explanation: Identical bitmaps across various configurations.
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.
More info:
To suppress this error, use the issue id "IconDuplicatesConfig" as explained in the Suppressing Warnings and Errors section.
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.
Explanation: The launcher icon shape should use a distinct silhouette.
According to the Android Design Guide (http://developer.android.com/design/style/iconography.html) your launcher icons should "use a distinct silhouette", a "three-dimensional, front view, with a slight perspective as if viewed from above, so that users perceive some depth."
The unique silhouette implies that your launcher icon should not be a filled square.
Explanation: Image defined in density-independent drawable folder.
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.
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
If you accidentally name two separate resources file.png and file.9.png, the image file and the nine patch file will both map to the same drawable resource, @drawable/file, which is probably not what was intended.
Explanation: Icon appears in both -nodpi and dpi folders.
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.
Explanation: Icon is specified both as .xml file and as a bitmap.
If a drawable resource appears as an .xml file in the drawable/ folder, it's usually not intentional for it to also appear as a bitmap using the same name; generally you expect the drawable XML file to define states and each state has a corresponding drawable bitmap.
Explanation: Name and version must be integer or string, not resource.
For the versionCode attribute, you have to specify an actual integer literal; you cannot use an indirection with a @dimen/name resource. Similarly, the versionName attribute should be an actual string, not a string resource url.
Plural strings should generally include a %s or %d formatting argument. In locales like English, the one quantity only applies to a single value, 1, but that's not true everywhere. For example, in Slovene, the one quantity will apply to 1, 101, 201, 301, and so on. Similarly, there are locales where multiple values match the zero and two quantities.
In these locales, it is usually an error to have a message which does not include a formatting argument (such as '%d'), since it will not be clear from the grammar what quantity the quantity string is describing.
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.)
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Correctness
Severity: Error
Explanation: Ignored layout params on include.
Layout parameters specified on an <include> tag will only be used if you also override layout_width and layout_height on the <include> tag; otherwise they will be ignored.
Explanation: Inconsistencies in array element counts.
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.
This check ensures that a layout resource which is defined in multiple resource folders, specifies the same set of widgets.
This finds cases where you have accidentally forgotten to add a widget to all variations of the layout, which could result in a runtime crash for some resource configurations when a findViewById() fails.
There are cases where this is intentional. For example, you may have a dedicated large tablet layout which adds some extra widgets that are not present in the phone version of the layout. As long as the code accessing the layout resource is careful to handle this properly, it is valid. In that case, you can suppress this lint check for the given extra or missing views, or the whole layout
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Performance
Severity: Warning
Explanation: Inefficient layout weight.
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.
When inflating a layout, avoid passing in null as the parent view, since otherwise any layout parameters on the root of the inflated layout will be ignored.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Warning
Explanation: Using inlined constants on older versions.
This check scans through all the Android API field references in the application and flags certain constants, such as static final integers and Strings, which were introduced in later versions. These will actually be copied into the class files rather than being referenced, which means that the value is available even when running on older devices. In some cases that's fine, and in other cases it can result in a runtime crash or incorrect behavior. It depends on the context, so consider the code carefully and device whether it's safe and can be suppressed or whether the code needs tbe guarded.
If you really want to use this API and don't need to support older devices just set the minSdkVersion in your build.gradle or AndroidManifest.xml files.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Correctness
Severity: Warning
Explanation: Inner classes should use $ rather than .
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.)
This check scans through libraries looking for calls to APIs that are not included in Android.
When you create Android projects, the classpath is set up such that you can only access classes in the API packages that are included in Android. However, if you add other projects to your libs/ folder, there is no guarantee that those .jar files were built with an Android specific classpath, and in particular, they could be accessing unsupported APIs such as java.applet.
This check scans through library jars and looks for references to API packages that are not included in Android and flags these. This is only an error if your code calls one of the library classes which wind up referencing the unsupported package.
This lint check looks for a folder name that is not a valid resource folder name; these will be ignored and not packaged by the Android Gradle build plugin.
Note that the order of resources is very important; for example, you can't specify a language before a network code.
Similarly, note that to use 3 letter region codes, you have to use a special BCP 47 syntax: the prefix b+ followed by the BCP 47 language tag but with + as the individual separators instead of -. Therefore, for the BCP 47 language tag nl-ABW you have to use b+nl+ABW.
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.
From the java.util.Locale documentation:
"Note that Java uses several deprecated two-letter codes. The Hebrew ("he") language code is rewritten as "iw", Indonesian ("id") as "in", and Yiddish ("yi") as "ji". This rewriting happens even if you construct your own Locale object, not just for instances returned by the various lookup methods.
Because of this, if you add your localized resources in for example values-he they will not be used, since the system will look for values-iw instead.
To work around this, place your resources in a values folder using the deprecated language code instead.
The BuildConfig class (available in Tools 17) provides a constant, "DEBUG", which indicates whether the code is being built in release mode or in debug mode. In release mode, you typically want to strip out all the logging calls. Since the compiler will automatically remove all code which is inside a "if (false)" check, surrounding your logging calls with a check for BuildConfig.DEBUG is a good idea.
If you really intend for the logging to be present in release mode, you can suppress this warning with a @SuppressLint annotation for the intentional logging calls.
When guarding a Log.v(tag, ...) call with Log.isLoggable(tag), the tag passed to both calls should be the same. Similarly, the level passed in to Log.isLoggable should typically match the type of Log call, e.g. if checking level Log.DEBUG, the corresponding Log call should be Log.d, not Log.i.
Note: This issue has an associated quickfix operation in Eclipse/ADT
Disabled By: Project lint.xml file
Priority: 2 / 10
Category: Correctness
Severity: Error
Explanation: Mangled file line endings.
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.
Explanation: Incorrect order of elements in manifest.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability
Severity: Error
Explanation: Missing menu title.
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.
Explanation: FrameLayout can be replaced with <merge> tag.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability:Icons
Severity: Warning
Explanation: Use Mipmap Launcher Icons.
Launcher icons should be provided in the mipmap resource directory. This is the same as the drawable resource directory, except resources in the mipmap directory will not get stripped out when creating density-specific APKs.
In certain cases, the Launcher app may use a higher resolution asset (than would normally be computed for the device) to display large app shortcuts. If drawables for densities other than the device's resolution have been stripped out, then the app shortcut could appear blurry.
To fix this, move your launcher icons from `drawable-`dpi to `mipmap-`dpi and change references from @drawable/ and R.drawable to @mipmap/ and R.mipmap.
In Android Studio this lint warning has a quickfix to perform this automatically.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability:Icons
Severity: Warning
Explanation: Missing application icon.
You should set an icon for the application as whole because there is no default. This attribute must be set as a reference to a drawable resource containing the image (for example @drawable/icon).
To suppress this error, use the issue id "MissingApplicationIcon" as explained in the Suppressing Warnings and Errors section.
MissingId
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Correctness
Severity: Warning
Explanation: Fragments should specify an id or tag
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Error
Explanation: Missing Android XML namespace.
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.
Different languages have different rules for grammatical agreement with quantity. In English, for example, the quantity 1 is a special case. We write "1 book", but for any other quantity we'd write "n books". This distinction between singular and plural is very common, but other languages make finer distinctions.
This lint check looks at each translation of a <plural> and makes sure that all the quantity strings considered by the given language are provided by this translation.
For example, an English translation must provide a string for quantity="one". Similarly, a Czech translation must provide a string for quantity="few".
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.
You should define the version information for your application. android:versionCode: An integer value that represents the version of the application code, relative to other versions.
android:versionName: A string value that represents the release version of the application code, as it should be shown to users.
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.
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Error
Explanation: Calling new methods on older versions.
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 build.gradle or AndroidManifest.xml files.
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.
If you are deliberately setting android: attributes in style definitions, make sure you place this in a values-vNN folder in order to avoid running into runtime conflicts on certain devices where manufacturers have added custom attributes whose ids conflict with the new ones on later platforms.
Similarly, you can use tools:targetApi="11" in an XML file to indicate that the element will only be inflated in an adequate context.
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.
ObsoleteLayoutParam
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Performance
Severity: Warning
Explanation: Obsolete layout params.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
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
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 2 / 10
Category: Correctness
Severity: Error
Explanation: Missing explicit orientation.
The default orientation of a LinearLayout is horizontal. It's pretty easy to believe that the layout is vertical, add multiple children to it, and wonder why only the first child is visible (when the subsequent children are off screen to the right). This lint rule helps pinpoint this issue by warning whenever a LinearLayout is used with an implicit orientation and multiple children.
It also checks for empty LinearLayouts without an orientation attribute that also defines an id attribute. This catches the scenarios where children will be added to the LinearLayout dynamically.
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.
Explanation: Method conflicts with new inherited method.
Suppose you are building against Android API 8, and you've subclassed Activity. In your subclass you add a new method called isDestroyed(). At some later point, a method of the same name and signature is added to Android. Your method will now override the Android method, and possibly break its contract. Your method is not calling super.isDestroyed(), since your compilation target doesn't know about the method.
The above scenario is what this lint detector looks for. The above example is real, since isDestroyed() was added in API 17, but it will be true for any method you have added to a subclass of an Android class where your build target is lower than the version the method was introduced in.
To fix this, either rename your method, or if you are really trying to augment the builtin method if available, switch to a higher build target where you can deliberately add @Override on your overriding method, and call super if appropriate etc.
Improper validation of app signatures could lead to issues where a malicious app submits itself to the Play Store with both its real certificate and a fake certificate and gains access to functionality or information it shouldn't have due to another application only checking for the fake certificate and ignoring the rest. Please make sure to validate all signatures returned by this method.
According to the Parcelable interface documentation, "Classes implementing the Parcelable interface must also have a static field called CREATOR, which is an object implementing the Parcelable.Creator interface.
This lint check looks for potential errors in internationalization where you have translated a message which involves a quantity and it looks like other parts of the string may need grammatical changes.
For example, rather than something like this:
<string name="try_again">Try again in %d seconds.</string>
you should be using a plural:
<plurals name="try_again">
<item quantity="one">Try again in %d second</item>
<item quantity="other">Try again in %d seconds</item>
</plurals>
This will ensure that in other languages the right set of translations are provided for the different quantity classes.
(This check depends on some heuristics, so it may not accurately determine whether a string really should be a quantity. You can use tools:ignore to filter out false positives.
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-project.txt
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Correctness
Severity: Error
Explanation: Incorrect property escapes.
All backslashes and colons in .property files must be escaped with a backslash (\). This means that when writing a Windows path, you must escape the file separators, so the path \My\Files should be written as key=\\My\\Files.
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.
More info:
To suppress this error, use the issue id "ProtectedPermissions" as explained in the Suppressing Warnings and Errors section.
PxUsage
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 2 / 10
Category: Correctness
Severity: Warning
Explanation: Using 'px' dimension.
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.
Many resources, such as TypedArrays, VelocityTrackers, etc., should be recycled (with a recycle() call) after use. This lint check looks for missing recycle() calls.
If relative layout has text or button items aligned to left and right sides they can overlap each other due to localized text expansion unless they have mutual constraints like toEndOf/toStartOf.
Explanation: Missing layout_width or layout_height attributes.
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.
Explanation: Should pass resolved color instead of resource id.
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.
Explanation: Right-to-left text compatibility issues.
API 17 adds a textAlignment attribute to specify text alignment. However, if you are supporting older versions than API 17, you must also specify a gravity or layout_gravity attribute, since older platforms will ignore the textAlignment attribute.
Explanation: Using RTL attributes without enabling RTL support.
To enable right-to-left support, when running on API 17 and higher, you must set the android:supportsRtl attribute in the manifest <application> element.
If you have started adding RTL attributes, but have not yet finished the migration, you can set the attribute to false to satisfy this lint check.
Explanation: Using left/right instead of start/end attributes.
Using Gravity#LEFT and Gravity#RIGHT can lead to problems when a layout is rendered in locales where text flows from right to left. Use Gravity#START and Gravity#END instead. Similarly, in XML gravity and layout_gravity attributes, use start rather than left.
For XML attributes such as paddingLeft and layout_marginLeft, use paddingStart and layout_marginStart. NOTE: If your minSdkVersion is less than 17, you should add both the older left/right attributes as well as the new start/right attributes. On older platforms, where RTL is not supported and the start/right attributes are unknown and therefore ignored, you need the older left/right attributes. There is a separate lint check which catches that type of error.
(Note: For Gravity#LEFT and Gravity#START, you can use these constants even when targeting older platforms, because the start bitmask is a superset of the left bitmask. Therefore, you can use gravity="start" rather than gravity="left|start".)
If you specify padding or margin on the left side of a layout, you should probably also specify padding on the right side (and vice versa) for right-to-left layout symmetry.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 7 / 10
Category: Correctness
Severity: Warning
Explanation: ScrollView size validation.
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
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.
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.
The signature protection level should probably be sufficient for most needs and works regardless of where applications are installed. The signatureOrSystem level is used for certain situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
More info:
To suppress this error, use the issue id "SignatureOrSystemPermissions" as explained in the Suppressing Warnings and Errors section.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Correctness
Severity: Warning
Explanation: Using dp instead of sp for text sizes.
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.
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.
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.
Explanation: Formatting argument types incomplete or inconsistent.
When a formatted string takes arguments, it usually needs to reference the same arguments in all translations (or all arguments if there are no 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.
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.
Explanation: String.format string doesn't match the XML format string.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 8 / 10
Category: Correctness
Severity: Error
Explanation: String should be int.
The properties compileSdkVersion, minSdkVersion and targetSdkVersion are usually numbers, but can be strings when you are using an add-on (in the case of compileSdkVersion) or a preview platform (for the other two properties).
However, you can not use a number as a string (e.g. "19" instead of 19); that will result in a platform not found error message at build/sync time.
Using 0dp as the width in a horizontal LinearLayout with weights is a useful trick to ensure that only the weights (and not the intrinsic sizes) are used when sizing the children.
However, if you use 0dp for the opposite dimension, the view will be invisible. This can happen if you change the orientation of a layout without also flipping the 0dp dimension in all the children.
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability
Severity: Warning
Explanation: Missing inputType or hint
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".
Explanation: TextView should probably be an EditText instead.
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.
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.
Using too many views in a single 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.
Key generation, signing, encryption, and random number generation may not receive cryptographically strong values due to improper initialization of the underlying PRNG on Android 4.3 and below.
If your application relies on cryptographically secure random number generation you should apply the workaround described in https://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html .
This lint rule is mostly informational; it does not accurately detect whether cryptographically secure RNG is required, or whether the workaround has already been applied. After reading the blog entry and updating your code if necessary, you can disable this lint issue.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability:Typography
Severity: Warning
Explanation: Hyphen can be replaced with dash.
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 5 / 10
Category: Usability:Typography
Severity: Warning
Explanation: Fraction string can be replaced with fraction character.
You can replace certain strings, such as 1/2, and 1/4, with dedicated characters for these, such as ½ (½) and ¼ (¼). This can help make the text more readable.
Note: This issue has an associated quickfix operation in Eclipse/ADT & Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 3 / 10
Category: Usability:Typography
Severity: Warning
Explanation: Other typographical problems.
This check looks for miscellaneous typographical problems and offers replacement sequences that will make the text easier to read and your application more polished.
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.)
Explanation: Reference to an id that is not in the current layout.
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.
Explanation: SMS phone number missing country code.
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.
This check finds attributes set in XML files that were introduced in a version newer than the oldest version targeted by your application (with the minSdkVersion attribute).
This is not an error; the application will simply ignore the attribute. However, if the attribute is important to the appearance of functionality of your application, you should consider finding an alternative way to achieve the same result with only available attributes, and then you can optionally create a copy of the layout in a layout-vNN folder which will be used on API NN or higher where you can take advantage of the newer attribute.
Note: This check does not only apply to attributes. For example, some tags can be unused too, such as the new <tag> element in layouts introduced in API 21.
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.
Android defines a number of different quantity strings, such as zero, one, few and many. However, many languages do not distinguish grammatically between all these different quantities.
This lint check looks at the quantity strings defined for each translation and flags any quantity strings that are unused (because the language does not make that quantity distinction, and Android will therefore not look it up.).
For example, in Chinese, only the other quantity is used, so even if you provide translations for zero and one, these strings will not be returned when getQuantityString() is called, even with 0 or 1.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Security
Severity: Warning
Explanation: Using the result of check permission calls.
You normally want to use the result of checking a permission; these methods return whether the permission is held; they do not throw an error if the permission is not granted. Code which does not do anything with the return value probably meant to be calling the enforce methods instead, e.g. rather than Context#checkCallingPermission it should call Context#enforceCallingPermission.
Note: This issue has an associated quickfix operation in Eclipse/ADT
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Performance
Severity: Warning
Explanation: Node can be replaced by a TextView with compound drawables.
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.
More info:
To suppress this error, use the issue id "UseCompoundDrawables" as explained in the Suppressing Warnings and Errors section.
Explanation: HashMap can be replaced with SparseArray.
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.
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 4 / 10
Category: Performance
Severity: Warning
Explanation: Should use valueOf instead of new
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.
Note: This issue has an associated quickfix operation in Eclipse/ADT
Disabled By: Project lint.xml file
Priority: 2 / 10
Category: Performance
Severity: Warning
Explanation: Useless parent layout.
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.
Explanation: Minimum SDK and target SDK attributes not defined.
The manifest should contain a <uses-sdk> element which defines the 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.)
To suppress this error, use the issue id "UsesMinSdkAttributes" as explained in the Suppressing Warnings and Errors section.
UsingHttp
Note: This issue has an associated quickfix operation in Android Studio/IntelliJ
Disabled By: Project lint.xml file
Priority: 6 / 10
Category: Security
Severity: Warning
Explanation: Using HTTP instead of HTTPS.
The Gradle Wrapper is available both via HTTP and HTTPS. HTTPS is more secure since it protects against man-in-the-middle attacks etc. Older projects created in Android Studio used HTTP but we now default to HTTPS and recommend upgrading existing projects.
Explanation: Missing View constructors for XML inflation.
Some layout tools (such as the Android layout editor for Studio & 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.
When implementing a view Adapter, you should avoid unconditionally inflating a new layout; if an available item is passed in for reuse, you should try to use that one instead. This helps make for example ListView scrolling much smoother.
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.
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.
The WebView implementation has certain performance optimizations which will not work correctly if the parent view is using wrap_content rather than match_parent. This can lead to subtle UI bugs.
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.
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.
Android uses the letter codes ISO 639-1 for languages, and the letter codes ISO 3166-1 for the region codes. In many cases, the language code and the country where the language is spoken is the same, but it is also often not the case. For example, while 'se' refers to Sweden, where Swedish is spoken, the language code for Swedish is notse (which refers to the Northern Sami language), the language code is sv. And similarly the region code for sv is El Salvador.
This lint check looks for suspicious language and region combinations, to help catch cases where you've accidentally used the wrong language or region code. Lint knows about the most common regions where a language is spoken, and if a folder combination is not one of these, it is flagged as suspicious.
Note however that it may not be an error: you can theoretically have speakers of any language in any region and want to target that with your resources, so this check is aimed at tracking down likely mistakes, not to enforce a specific set of region and language combinations.
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 ignore flags specified in the build.gradle file, as explained below
4. With a lint.xml configuration file in the project
5. With a lint.xml configuration file passed to lint via the --config flag
6. 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 a lint warning in a build.gradle file, add a section like this:
Here we specify a comma separated list of issue id's after the disable command. You can also use warning or error instead of disable to change the severity of issues.
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.
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


Consider the following diagram of red black tree:
In above red black tree the node x will have x.size attribute. This attribute is used to store the internal node of x sub-tree. The size of any internal node x is
Consider the OS-RANK(T, x) algorithm provided in section 14.1 to determine the rank of a node having key value 35 in above red black tree.
• Initially, the key value of T (root) and x are 26 and 35.
• The 1st line of OS-RANK(T, x) algorithm calculate value of r. Now, add 1 in x left child size. The node x that is 35 does not have left child. Therefore the value of x becomes:
• The 2nd line assigns value of x into y. Therefore the value of y also becomes 35.
• The 3rd line implement a while loop which check whether value of y that is 35 is not equal to T root that is 26. The condition is true so control moves into while loop.
• The 4th line use if statement to check whether y node is right child of its parent. Currently y is 35 which is not the right child of its parent 38 so condition false. The control directly moves to 6th line.
• The 6th line update the value of y with its parent, so now values of y becomes 38. Now control again moves to 3rd line. The while loop again checks value of y that is 38 is not equal to T root that is 26. The condition is true so control moves into while loop.
• The current y node that is 38 is right child of its parent 30 so 4th line condition get true.
• The 5th line calculate the value of r
• The 6th line again updates the value of y from 38 to 30. Now, control again moves to 3rd line, the condition in 3rd line again gets true.
• The current y node that is 30 is not the right child of its parent 41 so 4th line condition get False. Now, control moves to 6th line.
• The 6th line again updates the value of y from 30 to 41. Now, control again moves to 3rd line, the condition in 3rd line again gets true.
• The current y node that is 41 is the right child of its parent 26 so 4th line condition get False.
• The 5th line again calculate the value of r
• The 6th line again updates the value of y from 41 to 26. Now, control again moves to 3rd line, the condition in 3rd line gets false.
• The control directly moves to 7th line. The 7th line returns the value of r that is 16.
Finally the value of r return by OS-RANK(T, x ) algorithm is 16 .
Insertion process:
While insertion, multiple rotations are performed.
First insert the node and increase the rank of every node by 1 starting from root to the inserted node if the node is in the left subtree using the formula given below:
rank[x]=rank[predecessor[x]]+1
Rotations:
Case: Left rotation
In left rotation, the rank of the node on which rotation is made does not change. It remains same as before.
It can be seen from the diagram below:
Case: Right rotation
Same is the case with right rotation, the rank of the node on rotation is being made, rank remains same as shown below:
Deletion:
Opposite is the case with deletion. decrease the rank while deletion. In rotations, the rank does not change.
To find the number of intersections, count the number of inversions in the array of coordinates. The strategy behind counting inversions is that if two chords i and j (i < j) come like (Si, Ei, Sj, Ej) then they don’t intersect each other.
Note that Ej came before Ei that is an inversion. Thus, the coordinates that are inversion do not intersect each other. It is shown below with the help of diagram.
Taking chord (s1, e1) and point (s1, e2), sweeping clockwise, they come in order s1,s2, e2, e1. 2>1 but they came in unsorted order in e1 and e2. Thus, these are inversion. It is clear that these chords are not intersecting each other.
Now, take chord (s2, e2) and (s4, e4) The end points are in order s2,e2,s4,e4. This is sorted order. Thus, these are not inversions. It can be seen from diagram that these chords are intersecting each other.
Algorithm: Intersection(A, p, r):
1. Name all the chord points on the circle from the array A. Name starting point of ith chord as Si and end-point as Ei.
2. Now, calculate the inversions using merge sort using the steps below.
3. if p < r
4. then q = b(p + r)/2c
5. left = Intersection(A, p, q)
6. right = Intersection(A, q + 1, r)
7. inv = Intersection(A, p, q, r) + left + right
8. return inv
9. end if
10. return 0
11. Count the number of inversions.
12. Total number of intersection = – number of intersections
Complexity:
Since this is using the concept of divide and conquer like merge sort, it takes O(nlg n) time to compute the number of intersections.


The landing site was an ancient flood plain in Mars's northern hemisphere called "Ares Vallis" ("the valley of Ares", the ancient Greek equivalent of the ancient Roman deity Mars) and is among the rockiest parts of Mars. Scientists chose it because they found it to be a relatively safe surface to land on and one that contained a wide variety of rocks deposited during a catastrophic flood. After the landing succeeded, the lander received the name The Carl Sagan Memorial Station in honor of the astronomer.


ERROR: In order to access this website, you must enable your media devices (i.e. camera and microphone)
Try Again Leave Page


Creation 1
stillness.
i draw, paint, take digital photos, and dabble in graphic design.
Creation 3
Creation 4
Creation 5
Creation 9
Creation 11
i draw, paint, take digital photos, and dabble in graphic design.
Creation 1
Creation 3
Creation 4
Creation 5
Creation 9
Creation 11


Contact Form
Please fill all the texts in the fields.


If you already know about trees and want to go into the specific sections then click one of the sections below.
1. Binary Search Trees
2. AVL Trees
3. Huffman Coding
4. Heaps
4.  There are trees that have three children or as many as they want. We will focus on a tree with two children.
Binary Search Tree is a data structure where each node can have up to two children. The left child of the node must be less than the parent node while the right child is greater than or equal to the parent node.
Lets see how we can insert values into a binary search tree.
We first insert 8 and it is a tree with a single node as of now.
We insert 25 and it will go to the right of 8 since 25 > 8.
We then insert 2 and it will go to the left of 8 since 2 < 8.
We then insert 1 and it will go to the left of 8 since 1 < 8, but then it realizes that a child exists so we would check if the child is greater than or less than 1. In this case it is greater than 1, so we insert it to the left of 2 as nothing exists.
Here we do the rest of the insertions.
The nodes that has no children or only one children have null as their children because the value of the children does not exist.
Here is the diagram of a binary search tree. Please note: I forgot to add that nodes that have the same value as the parent goes to the right.
The trees on the bottom are called skewed trees which is where all of the nodes are basically lined up.
In the fields we have declared a val, left, and right. The val is the data that the node is holding and left and right is the children. Left and right default is null as of now.
I have coded the insertion method. Basically, the value we want to insert, compares with the current node and then see if it is less than go left or otherwise go right. We keep on doing this till we found a child that does not exist and then we insert it there.
Searching for a value in the tree has the same logic as the insertion except we just want to find the value.
While searching for the node to delete is part of the method, the deletion part might be a bit tricky. There are three cases we have to deal with in deletion which are: no children, 1 child, and two children.
In the first case, the node we want to delete has no children. It is easy as we can use the two pointer method and use the previous pointer and set its child to null. The Java implementation is located on the right.
In the second case, the node we want to delete has 1 child. It has a bit more steps but it should still be doable.
We can use the previous pointer and connect it to the child of the node we are about to delete. The Java implementation is located on the right.
In the third case, the node we want to delete has 2 children. It can a bit difficult at first but we use in order predecessor to find the node we want to switch with and delete. Basically, starting from the node we want to delete, we go left and then keep on going right till we found a node whose right is null. The Java implementation is located below.
Here is the whole delete method in Java.
Lets just say we want to traverse a tree. We could use the tree traversals, to go through all the nodes of a tree. It is very useful for many binary search tree problems.
Inorder traversal is a tree traversal where we first go through the left subtree and check if the node has children. If it does then we call inorder traversal on the child or else we check the node and move back to the parent and check that. Then we go through the right subtree of the parent node and continue till we go through the whole tree.
We first go down the left subtree and see that a child exists so we keep on going down. We want to go down till the left subtree is null.
Here we have print out the nodes we want to from the last node visited which is 3. And then it is 5. After that we visit 7 since we have to go to the right. Then we go back to the last visited and go on the right if it does exist and so on. So the whole list is 3, 5, 7, 10, 20, 40, 50. Notice how the list is in ascending order.
Here is the preorder and postorder traversal. In preorder traversal we first visit the node and then its left subtree and right. In postorder traversal we first visit the left and right subtree and then the node itself.
Here is the Java implementation for the traversals.
Suppose we want to implement a method where we want to find the kth smallest of a tree.
We can use inorder traversal and start with the smallest element. With that, we can use a counter and increase it by one for each element we meet. Once when we match the counter to k, we can return the value.
The four images below shows the whole process of the method. Now think about how we can do it in Java?
Java implementation
Suppose we want to implemenet a method where we want to find all of the nodes that are in the valid range and then find the sum of them.
10 is in the valid range so we would want to keep it and then call the method on its children.
We first see that 5 is not in the valid range but we should check if the right child is in the range. We will not check the left child since if 5 < 7 so why check the left child which is less than 5 for sure. In this case, the right child is the range so we add it in and 7 also has no children so we are done.
Now we are done with the left subtree so lets check the right subtree which is 15. We will add it in. We also will check the left and right but left is null and right is not in the range.
Java implementation is located below.
Now lets attempt the problems below. Use the following class below for the problems.
For this problem you have to get the height of a binary search tree.
Answer with explanation is at the bottom.
For this problem you have reverse a binary search tree.
Answer with explanation is at the bottom.
For this problem you have to turn a linked list to a binary search tree.
Answer with explanation is at the bottom.
AVL Trees are just like BST as the value less than the parent's value goes on the left and value greater than or equal to the parent's value goes on the right. However, it is also a self-balancing tree.
Before we can go over the AVL tree, we need to go over some other concepts important for this tree.
This is how we can determine the height of a tree.
Here is the balance factors we will use in the AVL Tree.
Here is the how we can the determine the balance factor of a node.
Here is the diagram of an AVL tree. This will be useful in what is coming up next.
So this is how we can determine the difference between two subtrees. The height of an empty tree (null) is -1.
In order for an AVL Tree to be valid (balanced) the difference must be a 1 or 0. The example below is not valid.
Right now we have an unbalanced tree and we need to make it balanced. Think about what could we do?
We can rotate the tree to the left and now it is balanced. This is called the right right case.
Here is the left left case which is similar to the right right case.
Now suppose we have to do a rotation where the subtree is not a straight line. Think about how could we solve this issue?
We rotate half of the tree to the left. It is not balanced but now it is now a left left rotation which we know how to do.
Now the tree is balanced.
This is the right left rotation which similar to left right rotation.
Suppose this tree is not balanced so we have to rotate it. But what if the node has children?
7 will sift up but 6 can become the child of 5 since 6 < 7 so it can go left. Then it can go to the right of 5 since 6 > 5.
The following tree is not balanced. Rotate it.
Answer with explanation is at the bottom.
The following tree is not balanced. Rotate it.
Answer with explanation is at the bottom.
The following tree is not balanced. Rotate it.
Answer with explanation is at the bottom.
Huffman Coding is a type of optimal prefix code which is used for lossless data compression. Huffman trees are used to represent the process of lossless data compression.
As you can see here are the letters sorted in ascending order of frequency. IT ALWAYS HAS TO BE SORTED IN THIS WAY. I also have made two queues. One has all the letters and one will have the tree/trees.
We first pop out two elements from the symbols queue and combine it to add it in the tree queue.
Now we pick the two smallest elements from symbols and/or trees queue. In this case, it is L and B so we build a tree out of those two and enqueue it.
Now it is H and a tree so we dequeue both of them and combine it and then enqueue it.
Here are the remaining steps.
Here is the result.
Here is a diagram of a Huffman Tree.
This is how we can code characters using a Huffman Tree.
This is how we can find the average code length of a tree. For each letter we can multiply the number of bits by the frequency. Then we can combine the result for each letter to find the average code length.
This is how we can decode to a String. At the first number, we start at the top and go down by the following numbers till we reach to a dead end (dead end is a letter). The we write that letter and then start at the next number (unless there are no more numbers left).
Encoding a string is just like encoding one character, but doing it many times.
Lets take a look at this problem below. Try it on your own and then see if you did it correctly or not.
Basically encoded is determined from the number of bits in the huffman tree for each character in the string. And for the unencoded multiply the number of bits given in the problem by the number of characters.
With that we can also determine the compression factor as shown in the calculations below.
 Basically it is a tree where all of the nodes are filled from left to right. And always the node at the top of the tree is the minimum or maximum element of a tree.
As you can see, all of the nodes of a heap must be filled from left to right except for the last level. In the last level it does not have to be fully filled but if there are nodes then it should be filled from left to right.
There are two types of heaps: min heap and max heap. In the min heap the smallest element is on the top while in the max heap the largest element is on the top.
As of now, I have inserted 27.
Now I have inserted 20 and we have to compare with 27 to see if the parent is less than the newly inserted
node or not. In this case the parent is greater so we are fine.
After inserting 45, we compare 45 with 27 and we realize that the parent is less than the newley inserted node. This makes the heap invalid so now we need to think of how we can make the heap valid.
We can use a method called sift up. Basically, after seeing that the parent is less than the newley inserted node. We swap 45 with 27. Then we move up to 45 to check if 45's parent is greater too. In this case, the parent does not exist, so we can stop.
After inserting 100, check if the tree is valid or not and try to fix it if the tree is not valid.
In this case it is, and we had to swap twice because we first swap with 100 and 20, but also we had to swap with 100 and 45 since 100 is obviously not less than 45.
Now try to do the next few insertions shown on the image below.
For the first insertion, we had to one swap. For the second one, we did only one swap. For the last insertion, we did two swaps.
The concept is similar to min heaps as when we insert then we will compare with the parent to see if the parent is smaller than the child. If it is not then we will swap and do it and so on till we reach the end or parent is smaller than the child.
Here is how insertion works on a min heap.
Here is pseudocode of insertion in heaps.
When we call delete in a max heap,the largest element of the tree gets deleted and in the min heap, the smallest element of the tree gets deleted.
In deletion, we take the value of the last node from the last level of the tree and switch it with the top. Then we delete the last node.
We now got rid of the maximum value, but the heap is not valid. Think about what could we do to solve this issue?
We can use sift down which is like sift up but we will go down the tree to switch the values around.
Now try deletion on this heap. Answer is at the bottom.

Here are some formulas use to find nodes' child or parent. This will be useful when we do the coding implementation.
Here is how deletion works on a min heap.
Here is pseudocode of deletion in heaps.
Here is the insert and delete method implemented in Java. I used ArrayLists as a heap for the purposes of this example.
If you are going to use heaps for projects and/or interview problems, you will most likely use a priority queue. So here the default priority queue is a min heap while the other one is a max heap.
We can use heapify, where we start around the middle value. We will start at, (number of nodes)/2. Basically, the middle node usually has children.
We have to check if the child greater than the parent. If it is, then we swap and then apply heapify to the child. In this case, the child has no children of its own so we are done.
Here is the rest of the heapify process
Here is the Java implememtation of this program.
" For this problem you have to return the kth largest of an unsorted array using a heap.
Please Note: I made a mistake on the image. I meant kthLargest instead of kthSmallest.
Solution with explanation is given below.
On average the Big O of going through a tree is O(log n) as we are eliminating paths. However, the worst case is O(n) when we will go through a skewed tree. Going down a skewed tree is just going through a linked list.
All of the tree traversals has a Big O of O(n) because in the worst case we will go through n nodes.
Here is the Big O Chart for Binary Search Trees:
Here is the Big O Chart for AVL Trees:
Here is the Big O Chart for Heaps:


[click on any image to enlarge]
Many new users to Bodhi seem to have the same questions, so here are the answers to a few of them:
Why are there so few applications installed?
Part of the Bodhi Linux philosophy is minimalism and user choice. We feel
that our users are intelligent enough to choose what applications they
want, and we provide an easy way to do so at the AppCenter. We also feel that it is easier and better for you
to build the system you want from the start, rather than
having to remove a lot of applications you don't want and/or need and then
install the ones you want/need.
You can learn more about installing software from here.
How do I change keyboard layouts?
Firstly, check to make sure the Keyboard module is loaded.
To do this, go to Main Menu>Settings>Modules and, in the Utilities tab of the
Module Settings dialog, scroll down until you get to Keyboard. Click on it and, if the Unload
button is inactive, then the module is not loaded. If that is the case, click the Load button to load it.
Now, navigate to Main Menu>Settings>All>Input>Keyboard.
Click the Add button of the Keyboard Settings dialog.
Here, select the keyboard layout you desire and click OK to add the layout to your available configurations.
Now that it has been added, simply click it, move it to the top with the Up button, and
click OK to implement it!
Note:
Once you've loaded the Keyboard module, you can now add the Keyboard
Gadget to a shelf or your desktop. This allows extreme convenience for all
those rampant layout switchers!
Why does Bodhi Linux use Midori Web Browser?
When we polled our users asking what the default web browser should be, we found a nearly equal 3-way tie among the current version of Firefox, an older version of Firefox, and Chromium. So, instead of choosing one of those that would have left approximately 2/3 of our users dissatisfied and needing to install another browser anyway, we went in a totally different direction: Midori!
Midori has the advantages of being very lightweight yet highly functional, which fits in with the Bodhi Linux philosophy (see the first question). Midori also has the ability to install applications directly from the AppCenter, a feature which some other browsers lack.