Give each tool a clear job
| Tool family | Primary use |
|---|---|
| Android Lint | Android-specific code, resource and manifest issues |
| detekt | Configurable Kotlin code-analysis rules |
| ktlint | Kotlin style checking and formatting |
| Compiler and tests | Type correctness and executable behavior |
| Security analysis | Sensitive flows, trust boundaries and dependency risk |
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.
Introduce one rule with an example the team understands
Choose a rule that addresses a concrete defect pattern in the project, then identify an existing example and the intended repair. Document whether the rule needs type resolution, Android resources or only source text. This explains why a full-project task may report something a lightweight editor or pasted-snippet check does not.
The detekt Gradle documentation describes integration tasks and configuration. Keep its selected version compatible with the project and preserve the rule configuration in version control. The Android Lint guide covers a different set of Android-specific checks; running one does not make the other redundant.
Review the baseline as a change in accepted debt
When introducing analysis to an existing project, capture the reviewed starting issues according to the tool's supported baseline mechanism. On a later failure, inspect the new issue before updating that baseline. Regenerating it automatically after every failure turns the mechanism into a way of accepting defects without a decision.
Make a small controlled rule violation in a disposable branch or fixture and confirm that the intended CI task reports it. Then remove it and rerun the task. This checks that the correct module and source set are included, rather than assuming a successful CI job necessarily analyzed the files developers are changing.
Keep formatting changes separate when practical. A formatter can alter many lines without changing behavior, which makes a simultaneous lifecycle or authorization repair harder to review. Inspect the formatter's scope and generated-source exclusions so it does not continually rewrite files produced by another build step.
For a logic repair, add or run the relevant behavioral checks in addition to static analysis. A clean style report cannot establish that a canceled coroutine leaves the screen consistent or that a resource is closed on an exception path. Associate the tests with the actual failure being repaired.
Preserve task names, tool versions, rules, baseline and reports for the release commit. When a tool upgrade changes the result, review whether the difference reflects a new rule, improved analysis or a regression. This keeps analysis useful as engineering evidence rather than an unexplained pass/fail badge.
Sources and further reading
- Android Developers: Improve your code with lint checks
- detekt: Official documentation
- ktlint official project
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
