Title: Theory / Unimportant / CS / Programming / Java / Android / Lint
Tags: computer_to_instruction type

Name: lint
Definition: Tool to help you to identify and correct problems with the structural quality of your code without your having to execute the app or write test cases
Page: https://developer.android.com/studio/write/lint

Typ: lint.xml
Meaning: A configuration file that you can use to specify any lint checks that you want to exclude and to customize problem severity levels.
Page: https://developer.android.com/studio/write/lint
Language: java

Instruction: gradlew lint
Page: https://developer.android.com/studio/write/lint
Effect: run the lint inspection
Language: java

Name: Warning baseline
Definition: A set of lint warnings that should be ignored
Page: https://developer.android.com/studio/write/lint
Context: lint
Intuition: Allow to ignore current warnings and avoid adding more

Name: Configuration
Definition: A configuration provides extra information or parameters to lint on a per project, or even per directory basis. For example, the lint.xml files can change the severity for issues, or list incidents to ignore (matched for example by a regular expression), or even provide values for options read by a specific detector.

Name: Context
Definition: An object passed into detectors in many APIs, providing data about (for example) which file is being analyzed (and in which project), and for specific types of analysis additional information; for example, an XmlContext points to the DOM document, a JavaContext includes the AST, and so on.
Context: Android

Name: Detector
Definition: The implementation of the lint check which registers Issues, analyzes the code, and reports Incidents.

Name: Implementation
Definition: Tell lint how a given issue is actually analyzed, such as which detector class to instantiate, as well as which scopes the detector applies to.
Context: Lint

Name: Incident
Definition: A specific occurrence of the issue at a specific location.
Example: Warning: In file IoUtils.kt, line 140, the field download folder
is "/sdcard/downloads"; do not hardcode the path to `/sdcard`.

Name: Issue
Definition: A type or class of problem that your lint check identifies.
Context: Lint
Extra: An issue has an associated severity (error, warning or info), a priority, a category, an explanation, and so on.
An example of an issue is “Don't hardcode paths to /sdcard”.

Name: IssueRegistry
Definition: A list of issues to lint.
Extra: When you write one or more lint checks, you'll register these in an IssueRegistry and point to it using the META-INF service loader mechanism.

Name: LintClient
Definition: A tool the detector run in.
Example: LintClient which (when incidents are reported) will show highlights in the editor
Example2: incidents are instead accumulated into HTML (and XML and text) reports, and the build interrupted on error.
Applied to: when running in the IDE
Applied to2: as part of the Gradle plugin

Name: Location
Definition: A place where an incident is reported.
Context: linter
Extra: Typically this refers to a text range within a source file, but a location can also point to a binary file such as a png file. Locations can also be linked together, along with descriptions. Therefore, if you for example are reporting a duplicate declaration, you can include both Locations, and in the IDE, both locations (if they're in the same file) will be highlighted. A location linked from another is called a “secondary” location, but the chaining can be as long as you want (and lint's unit testing infrastructure will make sure there are no cycles.)

Name: Partial Analysis
Definition: A “map reduce” architecture in lint which makes it possible to analyze individual modules in isolation and then later filter and customize the partial results based on conditions outside of these modules. This is explained in greater detail in the partial analysis chapter.

Name: Platform
Definition: The Platform abstraction allows lint issues to indicate where they apply (such as “Android”, or “Server”, and so on). This means that an Android-specific check won't trigger warnings on non-Android code.

Name: Scanner
Definition: A particular interface a detector that can implement to indicate that it supports a specific set of callbacks.
Example: The XmlScanner interface is where the methods for visiting XML elements and attributes are defined
Example2: the ClassScanner is where the ASM bytecode handling methods are defined, and so on.

Name: Scope
Definition: An enum which lists various types of files that a detector may want to analyze.
Extra: For example, there is a scope for XML files, there is a scope for Java and Kotlin files, there is a scope for .class files, and so on.
Typically lint cares about which set of scopes apply, so most of the APIs take an EnumSet< Scope>, but we'll often refer to this as just “the scope” instead of the “scope set”.

Name: Severity
Definition: For an issue, whether the incident should be an error, or just a warning, or neither (just an FYI highlight). There is also a special type of error severity, “fatal”, discussed later.

Name: TextFormat
Definition: An enum describing various text formats lint understands. Lint checks will typically only operate with the “raw” format, which is markdown-like (e.g. you can surround words with an asterisk to make it italics or two to make it bold, and so on).

Name: Vendor
Definition: A simple data class which provides information about the provenance of a lint check: who wrote it, where to file issues, and so on.
Context: Android linter