Lint: Grundlagen, statischer Analyse für Android-Projekte

Was ist Lint — ein statischer Code-Analysator?

Android Lint ist ein statisches Analysewerkzeug, das im Android SDK und Android Studio enthalten ist. Lint scannt den Quellcode der Anwendung, ohne ihn auszuführen, und findet Probleme, die der Compiler übersieht: ungenutzte Ressourcen, falsche Lokalisierung, potenzielle Speicherlecks, API-Inkompatibilität mit minSdkVersion und Verstöße gegen die Leistungsempfehlungen von Google.

Statische Analyse ist eine Software-Überprüfungsmethode, die keine tatsächliche Code-Ausführung erfordert. Im Gegensatz zum Compiler, der nur Syntax und Typen prüft, sucht ein statischer Analysator nach logischen Fehlern, Anti-Patterns und Abweichungen von bewährten Verfahren. Lint führt über 200 integrierte Prüfungen in Kategorien durch: Correctness, Performance, Security, Accessibility, Usability und I18N.

Lint arbeitet auf mehreren Ebenen: XML-Analyse prüft Layouts, Ressourcen (strings, colors, dimens), das Manifest und Konfigurationsdateien. Java/Kotlin-Analyse untersucht den Quellcode auf veraltete API-Aufrufe, Threading-Probleme und Kontextlecks. Gradle-Analyse prüft die Build-Konfiguration auf Versionskompatibilität.

Wie Lint den Code von Android-Projekten prüft

Die Lint-Prüfung wird über Android Studio (Analyze > Inspect Code) oder den Gradle-Befehl gestartet: ./gradlew lint. Das Ergebnis ist ein HTML-Bericht im Ordner build/reports/lint-results.html und ein XML-Bericht für CI-Systeme. Lint analysiert jede Datei unabhängig und wendet eine Reihe von Regeln (Issues) an, jede mit einer eindeutigen ID, Beschreibung, Kategorie und Schweregrad.

Lint-Schweregrade: Error (Fehler — blockiert den Build), Warning (Warnung — beeinträchtigt die Qualität), Informational (Information — zur Referenz), Ignore (standardmäßig ignoriert). Die Stufen werden in lint.xml konfiguriert. Lint-Fehler können so konfiguriert werden, dass der Gradle-Build bei ihrem Vorhandensein über lintOptions.abortOnError true fehlschlägt.

android {
    lintOptions {
        abortOnError true
        checkAllWarnings true
        baselineFile file("lint-baseline.xml")
        htmlReport true
        xmlReport true
        lintConfig file("lint.xml")
    }
}

Lint baseline — eine Datei, die aktuelle Warnungen als akzeptabel markiert. Erstellt mit dem Befehl lint --baseline baseline.xml. Nach dem Hinzufügen einer Baseline zum Projekt meldet Lint nur noch neue Probleme. Dies ist praktisch für die Einführung von Lint in einem alten Projekt mit Hunderten von Warnungen — das Team behebt Fehler schrittweise.

Konfiguration von Lint-Regeln in Konfigurationsdateien

lint.xml — eine Konfigurationsdatei im Projektstamm zur Anpassung von Lint-Regeln. Sie legt ignorierte Regeln, Schweregrade und Ausnahmen für bestimmte Dateien oder Verzeichnisse fest. Die Datei wird manuell erstellt und global auf alle Module des Projekts angewendet. Ohne lint.xml arbeiten alle Regeln mit Standardeinstellungen.

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Prüfung ungenutzter Ressourcen deaktivieren -->
    <issue id="UnusedResources" severity="ignore" />

    <!-- Schweregrad von Kontextlecks erhöhen -->
    <issue id="StaticFieldLeak" severity="error" />

    <!-- In generierten Dateien ignorieren -->
    <issue id="MissingTranslation" severity="ignore">
        <ignore path="build/generated" />
    </issue>
</lint>

@SuppressLint — eine Annotation zum Deaktivieren von Lint auf Methoden- oder Klassenebene in Java/Kotlin. Beispiel: @SuppressLint("SetTextI18n") für eine Methode, bei der Text dynamisch in einem TextView gesetzt wird. Die Annotation @RequiresApi gibt das minimale API-Level für eine Methode an — Lint gibt keine Warnung aus, wenn minSdk den angegebenen Wert überschreitet.

Ausführen von Lint-Prüfungen in einer CI/CD-Pipeline

Die CI-Integration von Lint ist eine Standardpraxis in der Android-Entwicklung. Der Befehl ./gradlew lint führt die Analyse aller Module durch und erstellt Berichte. In CI/CD-Konfigurationen (Jenkins, GitLab CI, GitHub Actions) wird Lint bei jedem Pull Request ausgeführt. Werden Fehler gefunden, schlägt der Build fehl und der Entwickler erhält eine Benachrichtigung mit dem Lint-HTML-Bericht.

lint-check:
  script:
    - ./gradlew lint
  artifacts:
    paths:
      - app/build/reports/lint-results.html
    when: always

Der Lint-HTML-Bericht enthält eine Tabelle aller gefundenen Probleme mit Kategorie, Regel-ID, Datei, Zeile und Beschreibung. Der Bericht ist auf dem CI-Server verfügbar oder wird als Build-Artefakt veröffentlicht. Der XML-Bericht (lint-results.xml) wird für die Integration mit Code-Analyse-Systemen (SonarQube, CodeClimate) und die automatische Aufgabenerstellung in Trackern (Jira, YouTrack) verwendet.

Lint in Pull Requests — konfigurieren Sie GitHub Actions oder GitLab CI so, dass Lint automatisch ausgeführt wird, wenn ein MR/PR erstellt wird. Wenn Lint Fehler findet, gibt CI einen Fehlerstatus zurück und das Zusammenführen wird blockiert. Dies verhindert, dass problematischer Code in den Hauptzweig gelangt, und erhält die Qualität der Codebasis.

Hauptkategorien von Lint-Regeln in Android

Lint-Kategorien decken alle Aspekte der Android-Entwicklung ab. Google unterteilt die Regeln in 12 Kategorien, jede für eine bestimmte Art von Problem zuständig. Die wichtigsten Kategorien sind Correctness, Performance, Security und Accessibility. Entwickler müssen die wichtigsten Prüfungen jeder Kategorie kennen, um effektiv mit Lint zu arbeiten.

Leistungsregeln sind in der Praxis am nützlichsten. UnusedResources findet Ressourcen, die in XML deklariert, aber im Code nicht verwendet werden. ViewHolder prüft, ob das ViewHolder-Muster in RecyclerView-Adaptern verwendet wird. DrawAllocation warnt vor der Objekterstellung in der onDraw-Methode. Die Behebung dieser Probleme reduziert die APK-Größe und beschleunigt die Anwendung.

Sicherheitsregeln sind für veröffentlichte Anwendungen obligatorisch. ExportedContentProvider prüft, ob ein ContentProvider ohne Schutz exportiert wird. WorldReadableFiles warnt vor der Erstellung von Dateien, die für alle Anwendungen zugänglich sind. AllowBackup prüft das allowBackup-Flag im Manifest — es wird empfohlen, es aus Gründen der Datensicherheit zu deaktivieren.