Lint : bases, analyseur statique pour projets Android

Qu'est-ce que Lint — un analyseur statique de code ?

Android Lint est un outil d'analyse statique inclus dans le SDK Android et Android Studio. Lint scanne le code source de l'application sans l'exécuter et trouve les problèmes que le compilateur ignore : ressources inutilisées, localisation incorrecte, fuites mémoire potentielles, incompatibilité d'API avec minSdkVersion et violations des recommandations de performance de Google.

L'analyse statique est une méthode de vérification logicielle qui ne nécessite pas d'exécution réelle du code. Contrairement au compilateur, qui ne vérifie que la syntaxe et les types, un analyseur statique recherche les erreurs logiques, les anti-patrons et les écarts par rapport aux meilleures pratiques. Lint effectue plus de 200 vérifications intégrées par catégories : exactitude, performance, sécurité, accessibilité, utilisabilité et I18N.

Lint fonctionne à plusieurs niveaux : L'analyse XML vérifie les mises en page, les ressources (strings, colors, dimens), le manifeste et les fichiers de configuration. L'analyse Java/Kotlin examine le code source pour les appels d'API obsolètes, les problèmes de threading et les fuites de contexte. L'analyse Gradle vérifie la configuration de build pour la compatibilité des versions.

Comment Lint vérifie le code des projets Android

La vérification Lint est lancée via Android Studio (Analyze > Inspect Code) ou par la commande Gradle : ./gradlew lint. Le résultat est un rapport HTML dans le dossier build/reports/lint-results.html et un rapport XML pour les systèmes CI. Lint analyse chaque fichier indépendamment, en appliquant un ensemble de règles (Issues), chacune avec un ID unique, une description, une catégorie et un niveau de gravité.

Niveaux de gravité Lint : Error (erreur — bloque la build), Warning (avertissement — affecte la qualité), Informational (information — pour référence), Ignore (ignoré par défaut). Les niveaux sont configurés dans lint.xml. Les erreurs Lint peuvent être configurées pour faire échouer la build Gradle via lintOptions.abortOnError true.

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

Lint baseline — un fichier qui marque les avertissements actuels comme acceptables. Créé avec la commande lint --baseline baseline.xml. Après avoir ajouté une baseline au projet, Lint ne signale que les nouveaux problèmes. C'est pratique pour introduire Lint dans un ancien projet avec des centaines d'avertissements — l'équipe corrige les erreurs progressivement.

Configuration des règles Lint dans les fichiers de configuration

lint.xml — un fichier de configuration à la racine du projet pour personnaliser les règles Lint. Il spécifie les règles ignorées, les niveaux de gravité et les exceptions pour des fichiers ou répertoires spécifiques. Le fichier est créé manuellement et appliqué globalement à tous les modules du projet. Sans lint.xml, toutes les règles fonctionnent avec les paramètres par défaut.

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Désactiver la vérification des ressources inutilisées -->
    <issue id="UnusedResources" severity="ignore" />

    <!-- Augmenter la gravité des fuites de contexte -->
    <issue id="StaticFieldLeak" severity="error" />

    <!-- Ignorer dans les fichiers générés -->
    <issue id="MissingTranslation" severity="ignore">
        <ignore path="build/generated" />
    </issue>
</lint>

@SuppressLint — une annotation pour désactiver Lint au niveau de la méthode ou de la classe en Java/Kotlin. Exemple : @SuppressLint("SetTextI18n") pour une méthode où le texte est défini dynamiquement dans un TextView. L'annotation @RequiresApi spécifie le niveau d'API minimum pour une méthode — Lint n'émettra pas d'avertissement si minSdk dépasse la valeur spécifiée.

Exécution de la vérification Lint dans un pipeline CI/CD

L'intégration CI de Lint est une pratique standard dans le développement Android. La commande ./gradlew lint exécute l'analyse sur tous les modules et génère des rapports. Dans les configurations CI/CD (Jenkins, GitLab CI, GitHub Actions), Lint s'exécute à chaque pull request. Si des erreurs sont trouvées, la build échoue et le développeur reçoit une notification avec le rapport HTML de Lint.

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

Le rapport HTML Lint contient un tableau de tous les problèmes trouvés avec la catégorie, l'ID de la règle, le fichier, la ligne et la description. Le rapport est disponible sur le serveur CI ou publié comme artefact de build. Le rapport XML (lint-results.xml) est utilisé pour l'intégration avec les systèmes d'analyse de code (SonarQube, CodeClimate) et la création automatique de tâches dans les trackers (Jira, YouTrack).

Lint dans les pull requests — configurez GitHub Actions ou GitLab CI pour que Lint s'exécute automatiquement lors de la création d'un MR/PR. Si Lint trouve des erreurs, CI renvoie un statut d'échec et la fusion est bloquée. Cela empêche le code problématique d'entrer dans la branche principale et maintient la qualité de la base de code.

Catégories principales des règles Lint dans Android

Les catégories Lint couvrent tous les aspects du développement Android. Google divise les règles en 12 catégories, chacune responsable d'un type spécifique de problème. Les catégories les plus importantes sont Correctness, Performance, Security et Accessibility. Les développeurs doivent connaître les vérifications clés de chaque catégorie pour travailler efficacement avec Lint.

Les règles de performance sont les plus utiles en pratique. UnusedResources trouve les ressources déclarées en XML mais non utilisées dans le code. ViewHolder vérifie que le modèle ViewHolder est utilisé dans les adaptateurs RecyclerView. DrawAllocation avertit de la création d'objets dans la méthode onDraw. La correction de ces problèmes réduit la taille de l'APK et accélère l'application.

Les règles de sécurité sont obligatoires pour les applications publiées. ExportedContentProvider vérifie si un ContentProvider est exporté sans protection. WorldReadableFiles avertit de la création de fichiers accessibles à toutes les applications. AllowBackup vérifie le drapeau allowBackup dans le manifeste — il est recommandé de le désactiver pour la sécurité des données.