Android Studio Lint: Run the Build-Integrated Check, Not Just a Snippet Scan

Establish a repeatable command

./gradlew :app:lintRelease

Use the task that exists for your actual module and flavors. The Android Lint documentation describes command-line execution, reports and configuration. A successful debug lint run does not automatically cover every release-specific source set.

Separate new defects from existing debt

An existing project may need a baseline to keep old findings from blocking every change immediately. A baseline records known issues; it does not fix them or prove they are harmless.

Avoid regenerating the baseline automatically whenever CI fails. That can convert every new defect into silently accepted debt.

Keep suppressions local

Suppress the specific issue at the smallest justified scope. A project-wide disable for a warning caused by one unusual component can hide unrelated future problems.

Review severity changes as policy changes. Turning an error into a warning may be reasonable in a staged migration, but it should be visible in code review.

Run alongside tests

Lint can identify suspicious patterns without executing the app. It cannot prove business logic, backend authorization or every runtime lifecycle path. Use unit and device tests for those behaviors, and inspect the final release artifact after build-time transformations.

Understand APKLint's scope

APKLint's Android Lint and code-checking pages provide focused heuristic review of submitted material. They are not the same as running the Android SDK's build-integrated lint task against the complete project. Use them for quick triage or explanation, while keeping the Gradle-generated report as the release evidence.