Lint: basics, static analyzer for Android projects

What is Lint — a static code analyzer?

Android Lint is a static analysis tool included with the Android SDK and Android Studio. Lint scans the application's source code without executing it and finds issues that the compiler misses: unused resources, incorrect localization, potential memory leaks, API incompatibility with minSdkVersion, and violations of Google's performance recommendations.

Static analysis is a software verification method that does not require actual code execution. Unlike the compiler, which only checks syntax and types, a static analyzer looks for logical errors, anti-patterns, and deviations from best practices. Lint performs over 200 built-in checks across categories: correctness, performance, security, accessibility, usability, and I18N.

Lint works on multiple levels: XML analysis checks layouts, resources (strings, colors, dimens), the manifest, and configuration files. Java/Kotlin analysis examines the source code for deprecated API calls, threading issues, and context leaks. Gradle analysis checks the build configuration for version compatibility.

How Lint checks Android project code

Lint checking is launched via Android Studio (Analyze > Inspect Code) or by the Gradle command: ./gradlew lint. The result is an HTML report in the build/reports/lint-results.html folder and an XML report for CI systems. Lint analyzes each file independently, applying a set of rules (Issues), each with a unique ID, description, category, and severity level.

Lint severity levels: Error (blocks the build), Warning (affects quality), Informational (for reference), Ignore (ignored by default). Levels are configured in lint.xml. Lint errors can be configured to fail the Gradle build when present via lintOptions.abortOnError true.

android {
    lintOptions {
        abortOnError true
        checkAllWarnings true
        baselineFile file("lint-baseline.xml")
        htmlReport true
        xmlReport true
        lintConfig file("lint.xml")
    }
}

Lint baseline — a file that marks current warnings as acceptable. Created with the command lint --baseline baseline.xml. After adding a baseline to the project, Lint only reports new issues. This is convenient for introducing Lint into an old project with hundreds of warnings — the team fixes errors gradually.

Configuring Lint rules in configuration files

lint.xml — a configuration file in the project root for customizing Lint rules. It specifies ignored rules, severity levels, and exceptions for specific files or directories. The file is created manually and applied globally to all project modules. Without lint.xml, all rules work with default settings.

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Disable unused resources check -->
    <issue id="UnusedResources" severity="ignore" />

    <!-- Increase context leak severity -->
    <issue id="StaticFieldLeak" severity="error" />

    <!-- Ignore in generated files -->
    <issue id="MissingTranslation" severity="ignore">
        <ignore path="build/generated" />
    </issue>
</lint>

@SuppressLint — an annotation for disabling Lint at the method or class level in Java/Kotlin. Example: @SuppressLint("SetTextI18n") for a method where text is dynamically set in a TextView. The @RequiresApi annotation specifies the minimum API Level for a method — Lint will not issue a warning if minSdk exceeds the specified value.

Running Lint checks in a CI/CD pipeline

CI integration of Lint is a standard practice in Android development. The command ./gradlew lint runs analysis on all modules and generates reports. In CI/CD configurations (Jenkins, GitLab CI, GitHub Actions), Lint runs on every pull request. If errors are found, the build fails, and the developer receives a notification with the Lint HTML report.

lint-check:
  script:
    - ./gradlew lint
  artifacts:
    paths:
      - app/build/reports/lint-results.html
    when: always

Lint HTML report contains a table of all found issues with category, rule ID, file, line, and description. The report is available on the CI server or published as a build artifact. XML report (lint-results.xml) is used for integration with code analysis systems (SonarQube, CodeClimate) and automatic task creation in trackers (Jira, YouTrack).

Lint in pull requests — configure GitHub Actions or GitLab CI so that Lint runs automatically when an MR/PR is created. If Lint finds errors, CI returns a failure status, and merging is blocked. This prevents problematic code from entering the main branch and maintains codebase quality.

Main categories of Lint rules in Android

Lint categories cover all aspects of Android development. Google divides the rules into 12 categories, each responsible for a specific type of issue. The most important categories are Correctness, Performance, Security, and Accessibility. Developers need to know the key checks in each category to work effectively with Lint.

Performance rules are the most useful in practice. UnusedResources finds resources declared in XML but not used in code. ViewHolder checks that the ViewHolder pattern is used in RecyclerView adapters. DrawAllocation warns about object creation in the onDraw method. Fixing these issues reduces APK size and speeds up the application.

Security rules are mandatory for published applications. ExportedContentProvider checks whether a ContentProvider is exported without protection. WorldReadableFiles warns about creating files accessible to all applications. AllowBackup checks the allowBackup flag in the manifest — it is recommended to disable it for data security.