Lint: Statische Analyse für Android-Projekte

Jeder Android-Entwickler kennt die Situation: Die App kompiliert, die Tests laufen grün – und trotzdem schleichen sich im Produktivbetrieb Fehler ein, die ein Werkzeug längst hätte melden können. Android Lint ist genau dieses Werkzeug: ein statischer Analyse-Scanner, der deinen Code, deine Ressourcen und deine Manifest-Datei auf potenzielle Probleme untersucht, ohne dass du die App auch nur einmal starten musst.

Was ist das?

Lint ist das offizielle, in das Android SDK integrierte Werkzeug zur statischen Codeanalyse. Statische Analyse bedeutet: Das Tool liest den Quelltext – Kotlin, Java, XML und Gradle-Skripte – und vergleicht ihn mit einer Sammlung von Regeln, den sogenannten Issues, ohne den Code tatsächlich auszuführen. Jede Regel adressiert eine bestimmte Klasse von Problemen: eine veraltete API, einen fehlenden Inhaltsbeschreibungs-Text für Barrierefreiheit oder eine mögliche NullPointerException.

Lint ist in Android Studio tief verankert. Warnungen erscheinen direkt als Unterstreichungen im Editor, und der Build-Prozess kann bei schwerwiegenden Befunden automatisch abgebrochen werden. Damit gehört Lint zu den ersten Qualitätsstufen in der Android-Entwicklung – noch vor Unit-Tests und Integrationstests, und lange vor dem ersten Testgerät.

Der entscheidende Vorteil gegenüber Tests: Lint braucht keine laufende App, keinen Emulator, kein Testgerät. Es analysiert den Code so, wie er im Repository liegt. Das macht es zur schnellsten und günstigsten Rückmeldeschleife im gesamten Qualitäts-Ökosystem von Android.

Wie funktioniert es?

Lint organisiert seine Regeln in Kategorien:

• Korrektheit – falsch verwendete APIs, fehlende Berechtigungen, Typen-Konflikte.
• Leistung – übermäßige Objekt-Allokierungen in onDraw(), statische Referenzen auf Context.
• Barrierefreiheit – ImageView ohne contentDescription, Touch-Ziele unter 48 dp.
• Internationalisierung – hartkodierte Strings außerhalb von strings.xml.
• Nutzbarkeit und Sicherheit – unsichere Netzwerkaufrufe im Klartext, fehlende ProGuard-Regeln.

Jeder Befund trägt einen Schweregrad: Fatal, Error, Warning, Information oder Ignore. Per Standard bricht ein Fatal- oder Error-Befund den Release-Build ab. Den vollständigen Report erzeugst du mit:

./gradlew lint

Das Ergebnis liegt als HTML-Report unter app/build/reports/lint-results-debug.html. Android Studio zeigt dieselben Befunde auch im Menü Analyze → Inspect Code.

Konfiguration mit lint.xml

In der Datei lint.xml im Projektstamm kannst du einzelne Regeln deaktivieren, ihren Schweregrad ändern oder bestimmte Pfade ausschließen:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Barrierefreiheits-Check für Bilder als Fehler erzwingen -->
    <issue id="ContentDescription" severity="error" />
    <!-- Auto-generierte Klassen aus der Analyse ausschließen -->
    <issue id="all">
        <ignore path="**/generated/**" />
    </issue>
</lint>

Im Kotlin-Code unterdrückst du eine einzelne Warnung mit @SuppressLint:

@SuppressLint("HardcodedText")
val label = TextView(context).apply {
    text = "Debug-Modus" // nur in Entwicklungs-Builds sichtbar
}

Die lintOptions-Konfiguration im Build-Skript steuert, wie Lint im Gradle-Build reagiert:

android {
    lint {
        abortOnError = true
        warningsAsErrors = false
        htmlReport = true
        htmlOutput = file("$buildDir/reports/lint.html")
    }
}

In der Praxis

Ein typischer Arbeitsablauf

Angenommen, du fügst ein ImageView zur Layout-XML hinzu, ohne android:contentDescription zu setzen. Lint meldet sofort [ContentDescription] Missing contentDescription attribute on image. Statt die Warnung zu ignorieren, fügst du eine sinnvolle Beschreibung hinzu – oder android:contentDescription="@null", wenn das Bild rein dekorativ ist. Das ist kein kosmetisches Detail: Screenreader-Nutzer sind direkt davon abhängig, und Google Play bewertet fehlende Barrierefreiheit inzwischen als Qualitätsmerkmal.

Die häufigste Stolperfalle

Viele Teams unterdrücken Lint-Warnungen blind per @SuppressLint oder setzen ganze Kategorien in lint.xml auf ignore. Das Ergebnis: Der Report wird leer, aber die echten Probleme wachsen weiter an. Besser ist eine klare Konvention im Team:

Jede @SuppressLint-Annotation braucht einen Kommentar, der erklärt, warum die Warnung in diesem konkreten Fall unbedenklich ist.

Diese Konvention lässt sich sogar mit einer eigenen Lint-Regel erzwingen. Eigene Regeln schreibst du als separates Android-Library-Modul, das das lint-api-Artefakt von Google einbindet. So kannst du projektspezifische Konventionen – etwa verbotene Imports oder vorgeschriebene Logging-Wrapper – automatisch prüfen lassen.

Lint im CI-Build

Füge in deiner CI-Pipeline folgenden Schritt ein, damit Qualitätsmängel nicht unbemerkt in den Release-Branch gelangen:

- name: Run Lint
  run: ./gradlew lintRelease

Mit abortOnError = true schlägt der Build fehl, sobald ein Error-Befund auftritt. So bleibt der Release-Branch sauber, ohne dass jemand den Report manuell prüfen muss.

Fazit

Lint ist kein optionales Extra, sondern ein integraler Bestandteil professioneller Android-Entwicklung. Es fängt API-Fehler, Performance-Fallen, Barrierefreiheits-Lücken und Internationalisierungsprobleme auf, bevor ein einziger Test läuft. Eine gute Übung für sofort: Starte ./gradlew lint in deinem aktuellen Projekt, öffne den HTML-Report im Browser und wähle drei Error- oder Warning-Befunde aus, die du bisher ignoriert hast. Bearbeite sie gezielt, commitiere die Fixes und füge Lint als festen Schritt in deine CI-Pipeline ein. Dann arbeitet es still im Hintergrund für dich – anstatt dich kurz vor dem Release mit einer langen Mängelliste zu überraschen.