Além de criar testes para garantir que o app atenda aos requisitos funcionais, é importante também executar o código com a ferramenta lint para ajudar a garantir que o código não tenha nenhum para solucionar problemas fáceis e de produção. A ferramenta lint ajuda a encontrar códigos com estrutura ineficiente que podem afetar a confiabilidade e eficiência dos seus apps Android e dificultar a manutenção do código. É altamente recomendável corrigir todos os erros detectados pelo lint. antes de publicar o app.
Por exemplo, arquivos de recursos XML que contêm namespaces não utilizados ocupam espaço e exigem o processamento desnecessário. Outros problemas estruturais, como o uso de elementos descontinuados ou chamadas de API sem suporte nas versões visadas da API, podem causar falhas na execução do código. O lint pode ajudar você a acabar com esses problemas.
Para melhorar o desempenho do lint, também é possível adicione anotações ao código.
Visão geral
O Android Studio oferece uma ferramenta de verificação de código chamada lint. que podem ajudar a identificar e corrigir problemas com a qualidade estrutural do seu código sem precisar executar o app ou criar casos de teste. Cada problema detectado pela ferramenta relatada com uma mensagem descritiva e um nível de gravidade, para que você possa priorizar os que precisam ser feitas. Também é possível reduzir o nível de gravidade de um problema para ignorar problemas que não são relevantes para o projeto ou aumentar o nível de gravidade para e destacar problemas específicos.
A ferramenta lint verifica os arquivos de origem do projeto Android para encontrar possíveis bugs e melhorias nos critérios de precisão, segurança, desempenho, usabilidade, acessibilidade e internacionalização. Ao usar o Android Studio, inspeções configuradas do lint e do ambiente de desenvolvimento integrado executadas durante a criação do app. No entanto, é possível executar inspeções manualmente ou Execute o lint na linha de comando, conforme descrito nesta página.
A ferramenta incorporada lint verifica o código enquanto você usa o Android Studio. Os avisos e erros podem ser mostrados de duas formas:
- Como texto pop-up na janela do editor. Quando o lint encontra um problema, ele destaca o código problemático em amarelo. Para problemas mais graves, ela sublinha o código em vermelho.
- Na janela Inspection Results do lint, quando você clica em Code > Inspecionar código.
Observação:quando o código é compilado no Android Studio, outras Inspeções de código do IntelliJ são executadas para otimizar o código. revisão.
A Figura 1 mostra como a ferramenta lint processa os arquivos de origem do app.
- Arquivos de origem do app
- Os arquivos de origem consistem em arquivos que compõem seu projeto Android, incluindo Kotlin, Java e Arquivos XML, ícones e arquivos de configuração do ProGuard.
- O arquivo
lint.xml - Arquivo de configuração usado para especificar todas as verificações do lint que você quer excluir e para personalizar os níveis de gravidade dos problemas.
- Ferramenta lint
- Uma ferramenta de verificação de código estático que pode ser executada no projeto Android pelo linha de comando ou em Android Studio O lint verifica problemas estruturais no código que possam afetar a qualidade e o desempenho dos App Android. .
- Resultados da verificação do lint
- Os resultados do lint podem ser vistos no console ou em Inspection Results
no Android Studio. Se você executar
lintna linha de comando, os resultados serão gravados na pastabuild/. Para mais detalhes, consulte a seção sobre realizar inspeções manualmente.
Executar o lint na linha de comando
Se você estiver usando o Android Studio ou o Gradle, use o wrapper do Gradle para invocar a tarefa lint do seu projeto.
digite um dos seguintes comandos do diretório raiz do seu projeto:
- No Windows:
gradlew lint
- No Linux ou no macOS:
./gradlew lint
O resultado será semelhante ao seguinte:
> Task :app:lintDebug Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results-debug.html
Quando a ferramenta lint conclui a verificação, ela informa caminhos para as versões XML e HTML do relatório. Você pode navegar até o relatório em HTML e abri-lo no navegador, conforme mostrado na Figura 2.
Se seu projeto incluir builds
variantes, o lint verifica apenas a variante padrão. Se você quiser executar o lint em
é necessário colocar o nome da variante em maiúscula e prefixá-lo com lint.
./gradlew lintRelease
Para saber mais sobre corrida Gradle na linha de comando, leia Criar seu app na linha de comando.
Executar o lint com a ferramenta autônoma
Se você não usa o Android Studio ou o Gradle,
instalar as ferramentas de linha de comando do SDK do Android;
para usar a ferramenta lint autônoma. Localizar a ferramenta lint
às android_sdk/cmdline-tools/version/bin/lint.
Observação:se você tentar executar a ferramenta autônoma em um projeto do Gradle, ela fornecerá
um erro. Use sempre gradle lint (no Windows) ou ./gradlew
lint (no macOS ou Linux) para executar o lint em um projeto do Gradle.
Para executar o lint em uma lista de arquivos em um diretório de projeto, use este comando:
lint [flags] <project directory>
Por exemplo, você pode emitir o comando abaixo para verificar os arquivos no diretório
myproject e nos subdiretórios. O ID de problema MissingPrefix
instrui o lint a verificar apenas a existência de atributos XML sem o prefixo de namespace Android.
lint --check MissingPrefix myproject
Para conferir a lista completa de sinalizações e argumentos da linha de comando compatíveis com a ferramenta, use este comando:
lint --help
O exemplo a seguir mostra a saída do console quando o comando do lint é executado em um projeto chamado Earthquake:
$ lint Earthquake Scanning Earthquake: ............................................................................................................................... Scanning Earthquake (Phase 2): ....... AndroidManifest.xml:23: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder] <uses-sdk android:minSdkVersion="7" /> ^ AndroidManifest.xml:23: Warning: <uses-sdk> tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes] <uses-sdk android:minSdkVersion="7" /> ^ res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources] res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder] 0 errors, 4 warnings
O exemplo de saída lista quatro avisos e nenhum erro.
Dois avisos estão relacionados ao arquivo AndroidManifest.xml do projeto:
ManifestOrderUsesMinSdkAttributes
Preferences.xml: UnusedResources.
Um aviso está relacionado ao diretório res:
IconMissingDensityFolder.
Configurar o lint para suprimir alertas
Por padrão, quando você executa uma verificação do lint, a ferramenta verifica todos os problemas suportados pelo lint. Também é possível restringir os problemas verificados pelo lint e atribuir em caso de problemas. Por exemplo, é possível suprimir a verificação do lint para problemas específicos não são relevantes para seu projeto. É possível configurar o lint para relatar problemas não críticos com um nível de gravidade mais baixo.
Os níveis de gravidade são:
enabledisableouignoreinformationalwarningerrorfatal
A verificação do lint pode ser configurada para níveis diferentes:
- Globalmente (todo o projeto)
- Módulo do projeto
- Módulo de produção
- Módulo de teste
- Arquivos abertos
- Hierarquia de classe
- Escopos do sistema de controle de versões (VCS, na sigla em inglês)
Configurar o arquivo do lint
Especifique as preferências de verificação do lint no arquivo lint.xml. Se você
estiver criando esse arquivo manualmente, coloque-o no diretório raiz do projeto Android.
O arquivo lint.xml consiste em uma tag pai <lint> que abrange
um ou mais elementos <issue> filhos. O lint define um único
Valor do atributo id para cada <issue>:
<?xml version="1.0" encoding="UTF-8"?> <lint> <!-- list of issues to configure --> </lint>
Para mudar o nível de gravidade ou desativar a verificação do lint para um problema, faça o seguinte:
defina o atributo de gravidade na tag <issue>.
Dica: para receber uma lista completa dos problemas detectados pelo lint
e seus IDs correspondentes, execute o comando lint --list.
Exemplo de arquivo lint.xml
O exemplo a seguir mostra o conteúdo de um arquivo lint.xml:
<?xml version="1.0" encoding="UTF-8"?> <lint> <!-- Disable the IconMissingDensityFolder check in this project --> <issue id="IconMissingDensityFolder" severity="ignore" /> <!-- Ignore the ObsoleteLayoutParam issue in the specified files --> <issue id="ObsoleteLayoutParam"> <ignore path="res/layout/activation.xml" /> <ignore path="res/layout-xlarge/activation.xml" /> </issue> <!-- Ignore the UselessLeaf issue in the specified file --> <issue id="UselessLeaf"> <ignore path="res/layout/main.xml" /> </issue> <!-- Change the severity of hardcoded strings to "error" --> <issue id="HardcodedText" severity="error" /> </lint>
Este exemplo mostra como diferentes tipos de problemas são informados. A
IconMissingDensityFolder
A verificação é desativada completamente, e a verificação ObsoleteLayoutParam é desativada apenas
nos arquivos especificados nas declarações <ignore ... /> entre elas.
Configurar a verificação do lint para arquivos de origem Kotlin, Java e XML
Desativar a verificação do lint para arquivos de origem Kotlin, Java e XML Na caixa de diálogo Preferences:
- Selecione Arquivo > Configurações (no Windows) ou Android Studio > Preferências (no macOS ou Linux).
- Selecione Editor > Inspeções.
- Para desativar, desmarque o arquivo de origem apropriado.
É possível defini-los para o ambiente de desenvolvimento integrado ou para projetos individuais selecionando o perfil apropriado.
Configurar a verificação do lint em Java ou Kotlin
Para desativar a verificação do lint para uma classe ou um método específico do seu projeto Android,
adicione a anotação @SuppressLint ao código.
O exemplo a seguir mostra como desativar a verificação do lint para o problema NewApi
no método onCreate. A ferramenta lint continuará verificando a existência do problema
NewApi em outros métodos dessa classe.
Kotlin
@SuppressLint("NewApi") override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.main)
Java
@SuppressLint("NewApi") @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main);
Isso pode ser feito em qualquer elemento combinável. O snippet de código a seguir mostra como transformar
de NewApi em qualquer elemento combinável.
Kotlin
@SuppressLint("NewApi") @Composable fun MyComposable{ ... }
O exemplo a seguir mostra como desativar a verificação do lint para o problema ParserError
na classe FeedProvider:
Kotlin
@SuppressLint("ParserError") class FeedProvider : ContentProvider() {
Java
@SuppressLint("ParserError") public class FeedProvider extends ContentProvider {
Para suprimir a verificação de todos os problemas do lint no arquivo, use a palavra-chave all:
Kotlin
@SuppressLint("all")
Java
@SuppressLint("all")
Você pode usar a mesma anotação para suprimir verificações de lint em qualquer função combinável.
Configurar a verificação do lint em XML
Use o atributo tools:ignore para desativar a verificação do lint para
dos arquivos XML. Coloque o valor de namespace a seguir no arquivo lint.xml
para que a ferramenta lint reconheça o atributo:
namespace xmlns:tools="http://schemas.android.com/tools"
O exemplo a seguir mostra como desativar a verificação do lint para a
Problema UnusedResources em um elemento <LinearLayout> de um XML.
arquivo de layout. O atributo ignore é herdado pelos elementos filhos do pai
em que o atributo é declarado. Neste exemplo, a verificação do lint também está desativada para o
Elemento <TextView> filho:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" tools:ignore="UnusedResources" > <TextView android:text="@string/auto_update_prompt" /> </LinearLayout>
Para desativar mais de um problema, relacione aqueles que você quer desativar em uma string separada por vírgulas. Por exemplo:
tools:ignore="NewApi,StringFormatInvalid"
Para suprimir a verificação de todos os problemas do lint no elemento XML, use o all.
palavra-chave:
tools:ignore="all"
Configurar opções do lint com o Gradle
O plug-in do Android para Gradle permite configurar algumas opções de lint,
como quais verificações executar ou ignorar, usando o
lint{} no nível do módulo
build.gradle.
O snippet de código a seguir mostra as propriedades que podem ser configuradas:
Kotlin
android { ... lint { // Turns off checks for the issue IDs you specify. disable += "TypographyFractions" + "TypographyQuotes" // Turns on checks for the issue IDs you specify. These checks are in // addition to the default lint checks. enable += "RtlHardcoded" + "RtlCompat" + "RtlEnabled" // To enable checks for only a subset of issue IDs and ignore all others, // list the issue IDs with the 'check' property instead. This property overrides // any issue IDs you enable or disable using the properties above. checkOnly += "NewApi" + "InlinedApi" // If set to true, turns off analysis progress reporting by lint. quiet = true // If set to true (default), stops the build if errors are found. abortOnError = false // If set to true, lint only reports errors. ignoreWarnings = true // If set to true, lint also checks all dependencies as part of its analysis. // Recommended for projects consisting of an app with library dependencies. checkDependencies = true } } ...
Groovy
android { ... lint { // Turns off checks for the issue IDs you specify. disable 'TypographyFractions','TypographyQuotes' // Turns on checks for the issue IDs you specify. These checks are in // addition to the default lint checks. enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // To enable checks for only a subset of issue IDs and ignore all others, // list the issue IDs with the 'check' property instead. This property overrides // any issue IDs you enable or disable using the properties above. checkOnly 'NewApi', 'InlinedApi' // If set to true, turns off analysis progress reporting by lint. quiet true // If set to true (default), stops the build if errors are found. abortOnError false // If set to true, lint only reports errors. ignoreWarnings true // If set to true, lint also checks all dependencies as part of its analysis. // Recommended for projects consisting of an app with library dependencies. checkDependencies true } } ...
Todos os métodos de lint que substituem o nível de gravidade de um problema respeitam o
ordem de configuração. Por exemplo, definir um problema como fatal em
finalizeDsl()
substitui a desativação na DSL principal.
Criar um valor de referência de avisos
Você pode capturar um snapshot do conjunto atual de avisos do seu projeto e usá-lo como valor de referência para futuras execuções de inspeção, para que apenas problemas novos sejam relatados. O snapshot como valor de referência permite que você comece a usar o lint para indicar falha no build sem ter que voltar atrás e resolver todos os problemas existentes primeiro.
Para criar um snapshot de referência, modifique o arquivo build.gradle do projeto da seguinte maneira:
Kotlin
android { lint { baseline = file("lint-baseline.xml") } }
Groovy
android { lintOptions { baseline file("lint-baseline.xml") } }
Quando você adiciona essa linha pela primeira vez, o arquivo lint-baseline.xml é criado para estabelecer o
valor de referência. A partir desse momento, as ferramentas lerão o arquivo apenas para determinar o valor de referência. Se você quiser
para criar um novo valor de referência, exclua manualmente o arquivo e execute o lint novamente para recriá-lo.
Em seguida, execute o lint no ambiente de desenvolvimento integrado selecionando Code > Inspecione o código ou na linha de comando
da seguinte forma. A saída revela a localização do arquivo lint-baseline.xml. A
o local do arquivo da sua configuração pode ser diferente do que é mostrado aqui:
$ ./gradlew lintDebug -Dlint.baselines.continue=true ... Wrote XML report to file:///app/lint-baseline.xml Created baseline file /app/lint-baseline.xml
A execução de lint registra
problemas atuais no arquivo lint-baseline.xml. O conjunto de problemas atuais é
chamada de valor de referência. Você pode conferir o lint-baseline.xml
no controle de versões se quiser compartilhá-lo com outras pessoas.
Personalizar o valor de referência
Se você quiser adicionar apenas alguns tipos de problemas ao valor de referência, especifique
problemas a serem adicionados editando o arquivo build.gradle do projeto da seguinte maneira:
Kotlin
android { lint { checkOnly += "NewApi" + "HandlerLeak" baseline = file("lint-baseline.xml") } }
Groovy
android { lintOptions { checkOnly 'NewApi', 'HandlerLeak' baseline file("lint-baseline.xml") } }
Se você adicionar novos avisos à base de código depois de criar o valor de referência, apenas listas do lint os bugs recém-introduzidos.
Alerta de valor de referência
Quando um valor de referência estiver em vigor, você receberá um alerta informando que um ou mais os problemas foram filtrados porque estão listados no valor de referência. Isso ajuda você a lembrar que configurou um valor de referência e que precisa corrigir todos os problemas em em algum momento.
Esse aviso informativo também monitora problemas que não são mais relatados. Essas informações permitem você saberá se realmente corrigiu os problemas. Dessa forma, é possível recriar a linha de base para evitar um erro que volte não detectado.
Observação: valores de referência são ativados quando você executa inspeções no modo de lote no ambiente de desenvolvimento integrado, mas eles são ignorados pelas verificações no editor executadas em segundo plano quando você está editando um arquivo. Isso ocorre porque os valores de referência são destinados aos casos em que uma base de código tem um grande número de avisos mas você quer corrigir os problemas localmente enquanto lida com o código.
Executar inspeções manualmente
Para executar manualmente inspeções configuradas do lint e outras inspeções do ambiente de desenvolvimento integrado, selecione Código > Inspecionar código. Os resultados da inspeção são exibidos na janela Inspection Results.
Definir escopo e perfil da inspeção
Selecione os arquivos que você quer analisar (o escopo da inspeção) e os que você quer executar (o perfil de inspeção) da seguinte maneira:
- Na visualização Android, abra o projeto e selecione o projeto, a pasta ou que você quer analisar.
- Na barra de menu, selecione Code > Inspecionar código.
Na caixa de diálogo Specify Inspection Scope, revise as configurações.
Figura 3. Revise as configurações do escopo da inspeção. As opções que aparecem na caixa de diálogo Especificar escopo da inspeção variam dependendo da seleção de um projeto, uma pasta ou um arquivo:
- Quando você seleciona um projeto, arquivo ou diretório, o Especificar o escopo da inspeção mostra o caminho para o projeto, arquivo ou diretório selecionado.
- Quando você seleciona mais de um projeto, arquivo ou diretório, a seção Especificar inspeção A caixa de diálogo "Escopo" mostra um botão de opção para Arquivos selecionados.
Para alterar o que será inspecionado, selecione um dos outros botões de opção. Consulte Especificar o escopo da inspeção para ver uma descrição de todos campos possíveis na caixa de diálogo Especificar escopo da inspeção.
- Em Perfil de inspeção, selecione o perfil que você quer usar.
Clique em OK para executar a inspeção.
A Figura 4 mostra o lint e outras inspeções do ambiente de desenvolvimento integrado. da execução de Inspect Code:
Figura 4. Resultados da inspeção. Selecione um problema para conferir a resolução. -
No painel Inspection Results, abra e selecione os resultados da inspeção. categorias de erro, tipos ou problemas.
O painel Relatório de inspeção exibe o relatório de inspeção para a categoria de erro, tipo ou problema selecionado no painel Inspection Results e exibe o nome e local do erro. Quando aplicável, o relatório de inspeção exibe outras informações, como um resumo do problema, para ajudar a corrigi-lo.
Na visualização em árvore do painel Resultados da inspeção, clique com o botão direito do mouse em uma categoria, tipo ou problema para exibir o menu de contexto.
Dependendo do contexto, você pode:
- Ir para a origem.
- Excluir e incluir os itens selecionados.
- Suprimir problemas.
- Editar configurações.
- Gerenciar alertas de inspeção.
- Executar novamente uma inspeção.
Para descrições dos botões da barra de ferramentas, dos itens do menu de contexto e da inspeção campos do relatório, consulte Janela de ferramentas "Inspection Results".
Usar um escopo personalizado
Use um dos escopos personalizados fornecidos no Android Studio da seguinte forma:
- Na caixa de diálogo Specify Inspection Scope, selecione Custom scope.
Clique na lista Escopo personalizado para mostrar as opções:
Figura 5. Selecione o escopo personalizado que você quer usar. - Todos os lugares:todos os arquivos.
- Project Files:todos os arquivos do projeto atual.
- Project Source Files:somente os arquivos de origem do projeto atual.
- Project Production Files: somente os arquivos de produção do projeto atual.
- Project Test Files: somente os arquivos de teste do projeto atual.
- Scratches and Consoles:somente os arquivos de rascunho e os consoles que você abriu na do projeto atual.
- Arquivos acessados recentemente:mostra apenas os arquivos acessados recentemente no projeto atual.
- Current File: somente o arquivo atual do projeto atual. Aparece quando você tem um arquivo ou uma pasta selecionados.
- Diretório selecionado: somente a pasta atual do projeto atual. Aparece quando você uma pasta selecionada.
- Class Hierarchy:quando você seleciona essa opção e clica em OK, uma caixa de diálogo aparece com todas as classes do projeto atual. Na caixa de diálogo, use o campo Pesquisar por nome. para filtrar e selecionar as turmas ser inspecionado. Se você não filtrar a lista de classes, a inspeção do código inspecionará todos classes.
Se você tiver um VCS configurado para o projeto, também há opções para restringir a pesquisa somente aos arquivos que foram modificados.
- Clique em OK.
Criar um escopo personalizado
Quando você quiser inspecionar uma seleção de arquivos e diretórios que não está coberto por nenhum dos escopos personalizados disponíveis, é possível criar um escopo personalizado:
- Na caixa de diálogo Specify Inspection Scope, selecione Custom scope.
Clique nos três pontos após a lista Escopo personalizado.
Figura 6. Caixa de diálogo "Especificar escopo da inspeção". A caixa de diálogo Scopes é exibida.
Figura 7. Criar um escopo personalizado. - Clique no
no canto superior esquerdo da caixa de diálogo para definir um novo escopo. - Na lista Add Scope exibida, selecione Local.
Os escopos locais e compartilhados são usados no projeto pelo recurso Inspect Code. Um escopo Shared também pode ser usado por outros recursos do projeto com um campo de escopo. Por exemplo, quando você clica em Edit Settings
para mudar as
configurações de Find Usages, a caixa de diálogo exibida terá um campo Scope, em que é possível
selecionar um escopo compartilhado.
Figura 8. Selecione um escopo compartilhado Caixa de diálogo Find Usages. - Atribua um nome ao escopo e clique em OK.
Painel à direita da caixa de diálogo Scopes. é preenchido com opções que permitem definir o escopo personalizado.
- Na lista, selecione Project.
Será exibida uma lista dos projetos disponíveis.
Observação: é possível criar o escopo personalizado para projetos ou pacotes. A as etapas são as mesmas.
Expanda as pastas do projeto, selecione o que você quer adicionar ao escopo personalizado e escolha se ela deve ser incluída ou excluída.
Figura 9. Definir um escopo personalizado. - Include: inclui essa pasta e os arquivos pertencentes a ela, mas não inclui nenhuma das subpastas.
- Incluir recursivamente: inclui esta pasta e os arquivos contidos nela, bem como as subpastas e os respectivos .
- Exclude: exclui essa pasta e os arquivos pertencentes a ela, mas não exclui nenhuma das subpastas.
- Excluir recursivamente: exclui esta pasta e os arquivos contidos nela, bem como as subpastas e os respectivos .
A figura 10 mostra que a pasta main está incluída e que a pasta java e res são incluídas recursivamente. Azul indica uma pasta parcialmente incluída, e verde indica pastas e arquivos incluídos recursivamente.
Figura 10. Exemplo de padrão para um escopo personalizado. - Se você selecionar a pasta java e clicar em Excluir recursivamente, o ícone verde o destaque desaparece na pasta java e em todas as pastas e arquivos relacionados.
- Se você selecionar o arquivo MainActivity.kt destacado em verde e clicar em Excluir, MainActivity.kt não ficará mais destacado em verde, mas todo o restante na pasta java permanece verde.
- Clique em OK. O escopo personalizado aparece na parte inferior da lista.
Revisar e editar perfis de inspeção
O Android Studio tem uma seleção de perfis do lint e outros perfis de inspeção atualizados. através Atualizações do Android. É possível usar esses perfis como estão ou editar os nomes, descrições, gravidades e escopos. Também é possível ativar e desativar grupos inteiros de perfis ou perfis individuais em um grupo.
Para acessar as configurações de Inspections:
- Selecione Arquivo > Configurações. (no Windows) ou Android Studio > Preferências (no macOS ou Linux).
- Selecione Editor > Inspeções.
Selecione a lista Profile para alternar entre Default (Android Studio) e Inspeções Project Default (o projeto ativo).
Para saber mais, consulte a documentação do Gerenciar perfis.
Na lista Inspections no painel esquerdo, selecione uma categoria de perfil de nível superior ou expandir um grupo e selecionar um perfil específico.
Ao selecionar uma categoria de perfil, é possível editar todas as inspeções dessa categoria como uma única inspeção.
- Selecione a lista Show Schema Actions
para copiar, renomear, adicionar
descrições, exportar e importar inspeções. - Ao concluir, clique em OK.
O painel Inspections mostra uma lista de inspeções compatíveis e os respectivos descrições.
