2017-08-31 2 views
1

j'ai dans mon build.gradle:Android Studio est lint_baseline.xml n'exclut pas beaucoup de questions qu'il devrait

android { 
    lintOptions { 
    abortOnError false 
    absolutePaths false 
    lintConfig file('lint.xml') 
    baseline file('lint-baseline.xml') 
    } 
} 

Et J'ai couru Analyze > Inspect Code précédemment pour établir cette ligne de base. J'ai également confirmé que ce fichier existe bel et bien et qu'il contient des problèmes à ignorer.

Cependant, j'ai encore beaucoup d'avertissements apparaissant lorsque je cours Analyze > Inspect Code. Il semble que les problèmes qui ne sont pas exclus sur la base de référence sont ceux qui ne sont pas listés par lint --list/ceux listés here.

Ils comprennent « déclaration non utilisée », « champ peut être local », etc.

Est-il possible de filtrer ces derniers dehors aussi? Pourquoi l'inspection du code vérifie-t-elle les avertissements/erreurs que la charpie ne répertorie pas comme des problèmes?

Répondre

2

des inspections Android Studio:

Lint peut être configuré avec une "base"; un ensemble de problèmes actuels trouvés dans une base de code, que les futures analyses de lint ignorent silencieusement. Seuls les nouveaux problèmes non détectés dans la base de référence sont signalés.

Notez que lorsque vous ouvrez des fichiers dans l'EDI, les problèmes de base ne sont pas filtrés; Le but des lignes de base est de vous permettre de commencer à utiliser lint et de casser la construction de toutes les erreurs nouvellement introduites, sans avoir à revenir en arrière et à corriger toute la base de code à l'avant. Cependant, lorsque vous ouvrez des fichiers existants, vous voulez toujours connaître et résoudre les problèmes lorsque vous les rencontrez. Ce type de problème est utilisé pour émettre deux types de messages d'information dans les rapports: d'abord, si des problèmes ont été filtrés afin que vous n'ayez pas un faux sentiment de sécurité si vous avez oublié que vous avez archivé un fichier de base et, deuxièmement, si des problèmes dans le fichier de base semblent avoir été corrigés de sorte que vous pouvez arrêter de les filtrer et être avertis si les problèmes sont réintroduits.

Je me demandais juste la même chose. Peut-être que cela aidera à expliquer les choses.

La fonction de ligne de base est destinée à masquer les erreurs de lissage dans la console et à faire en sorte que les nouvelles mises en garde/erreurs interrompent la génération. Malheureusement, cela ne supprime pas les inspections d'Android Studio.

enter image description here

+0

Si je vous parle de la façon dont la ligne de base de peluches vous comprendre correctement, ne supprimera pas les problèmes quand je visionne un fichier dans l'IDE, oui? Si c'est le cas, ce n'est pas exactement ce dont je parle. Au contraire, je vois le retour d'inspection réel avec des problèmes de peluches, lors de l'exécution de l'inspection du code _immédiatement après la définition de la ligne de base, sans changements de code. Pour moi, cela semble vaincre tout le but de la mise en place d'une ligne de base –

+0

Bon alors oui et non. La ligne de base affecte UNIQUEMENT la tâche de l'outil CLI/Gradle. Exécutez la tâche "peluches" dans votre module. Si elle est configurée correctement, elle utilisera la ligne de base et ne signalera pas d'erreur/d'avertissement, à l'exception de la simple notification de l'utilisation d'une ligne de base. Lorsque je l'exécute via la tâche Gradle, cela fonctionne comme prévu, mais uniquement pour l'outil CLI, pas pour 'Analyser> Inspecter le code'. En résumé, la ligne de base ne peut pas affecter quoi que ce soit dans l'EDI: les inspections en ligne pour un fichier ouvert ni la fenêtre 'Analyser> Inspecter le code'.Il peut supprimer les avertissements/erreurs lors de l'exécution à partir de l'outil CLI/Gradle uniquement –