Android Static Code Analysis: Combine Build Context and Focused Checks

Give each tool a clear job

Use the current Lint, detekt and ktlint references. Pin compatible tool versions so a developer's local formatter and CI do not disagree unexpectedly.

Adopt rules incrementally

Start with high-signal rules that correspond to bugs or maintainability problems your team understands. A massive unexplained warning list trains people to ignore reports.

For existing debt, use a reviewed baseline where the tool supports it. Keep new issues visible, and reduce the baseline deliberately rather than recreating it after every failed build.

Keep formatting separate from logic changes

Automatic formatting is useful, but a repository-wide reformat mixed with a security fix makes the substantive change harder to review. Prefer a dedicated formatting commit when introducing or changing rules.

Review formatter output before committing, especially in generated files or unusual DSL code.

Preserve build context

Run checks against the correct modules and source sets. A single Kotlin snippet lacks imports, generated code, dependency versions and lifecycle context. Type-aware rules may need configuration that a plain-text scanner cannot infer.

Use APKLint for focused review

APKLint's static analysis tools can highlight patterns in code and configuration and provide explanations. They do not execute the complete Gradle build or prove all findings are applicable. For release decisions, retain the tool versions, rules, baseline, reports and tests tied to the exact commit and artifact.