Debugging log · Build

lintVitalRelease aborted the release build

Everything ran in debug. Then I went to build the release AAB and it failed at a task I rarely think about: lintVitalRelease, with "Lint found fatal errors." No code had changed — I'd just switched from assembling a debug build to a release one, and release turns on a stricter gate that debug never runs.

The short version: release builds run a "vital" lint pass that treats certain issues as fatal and stops the build. The fix is to open the lint report it points to, find the specific fatal issue, and fix that issue — not to switch lint off, which just ships the problem.

The error

Execution failed for task ':app:lintVitalRelease'.
> Lint found fatal errors while assembling a release target.
  ... see the report at: .../build/reports/lint-results-...html

Why release lint is stricter

Lint runs in two modes. During normal development it reports issues as warnings you can ignore for now. But when you build a release, a subset of checks marked as "fatal" run as lintVitalRelease, and any one of them stops the build. The reasoning is that some problems are fine to defer while coding but must not reach users — a broken resource reference, a missing translation marked as an error, a hardcoded value that breaks on certain devices. Release is the last chance to catch them, so the gate is intentionally hard.

Read the report it names

The error line includes a path to an HTML report. Open it — that report lists the exact fatal issue, the file, and the line, usually with an explanation and a suggested fix. This is the whole game: the task name tells you lint failed, but the report tells you what to fix. Don't guess from the task name; read the report.

Fix the issue it found

Common fatal findings and their real fixes:

Missing or broken resource references — a layout or string points at something that doesn't exist. Fix the reference.
Missing translations (if treated as fatal) — add the missing string to the locale it complains about, or mark it non-translatable if that's correct.
Hardcoded values that break accessibility or sizing — move to resources as the report suggests.
A genuinely wrong API usage for your minSdk — guard it or raise the floor.

Each one is a real issue the gate caught before your users did. Fixing it is usually small.

Resist abortOnError false or disabling the check. It's the most-copied answer and it only mutes the alarm — the broken resource or missing translation still ships. If you're truly certain a specific finding is a false positive, suppress that one check narrowly (via a lint baseline or a targeted suppression), not the whole gate.

If it's genuinely a false positive

Occasionally lint flags something that's correct in your context. The right tool then is a lint baseline — a snapshot that acknowledges existing findings so they don't fail the build, while new ones still do — or a targeted suppression on the exact issue id. Both keep the gate working for everything else. Turning the gate off entirely trades one real safety net for a green build.

Confirming the fix

Re-run the release build (or ./gradlew lintVitalRelease directly) and confirm the report is clean.
Fix issues one at a time and re-check — a report can list several, and you want to know each is genuinely resolved.

Paths and specific findings above are examples — act on the exact report and issue in your own build.