Melhorar seu código com verificações de lint

Além de criar testes para garantir que o app atenda aos requisitos funcionais, é importante executar o código com a ferramenta lint para garantir que ele não tenha problemas estruturais. 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, se os arquivos de recursos XML contiverem namespaces não utilizados, isso vai ocupar espaço e exigirá 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 a performance do lint, você também pode adicionar anotações ao código.

Visão geral

O Android Studio oferece uma ferramenta de verificação de código chamada lint para ajudar a identificar e corrigir problemas com a qualidade estrutural do código sem executar o app nem programar casos de teste. Cada problema detectado pela ferramenta é relatado com uma mensagem descritiva e um nível de gravidade, permitindo priorizar quais aprimoramentos essenciais são necessários. 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 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, as inspeções configuradas de lint e do ambiente de desenvolvimento integrado são executadas quando você cria seu app. No entanto, você pode executar inspeções manualmente ou executar 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, o lint sublinha o código em vermelho.
• Na janela Inspection Results do lint, quando você clica em Code > Inspect Code.

Observação:quando o código é compilado no Android Studio, outras inspeções de código do IntelliJ são executadas para otimizar a análise do código. Mantenha o Android Studio o mais atualizado possível para garantir que as regras e inspeções mais recentes do lint estejam disponíveis.

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 o projeto Android, incluindo arquivos Kotlin, Java e 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 na linha de comando ou no Android Studio. A ferramenta lint verifica a existência de problemas estruturais no código que possam afetar a qualidade e o desempenho do app Android.

Resultados da verificação do lint

Os resultados do lint podem ser vistos no console ou na janela Inspection Results no Android Studio. Se você executar lint na linha de comando, os resultados serão gravados na pasta build/. Para mais detalhes, consulte a seção sobre como executar inspeções manualmente.

Executar o lint na linha de comando

Se você está usando o Android Studio ou o Gradle, use o wrapper do Gradle para invocar a tarefa lint do seu projeto inserindo um dos seguintes comandos no diretório raiz do projeto:

Observação:mantenha o Plug-in do Android para Gradle o mais atualizado possível para usar as regras de lint mais recentes.

• 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 o projeto incluir variantes de build, o lint vai verificar apenas a variante padrão. Se você quiser executar o lint em uma variante diferente, coloque o nome da variante em maiúscula e adicione o prefixo lint.

./gradlew lintRelease

Observação:o lint não é executado automaticamente como parte do build. É altamente recomendável executar o lint como parte de um build de integração contínua para ter acesso às verificações mais recentes do lint ao criar seu código-fonte.

Para saber mais sobre como executar tarefas do Gradle na linha de comando, consulte Criar seu app na linha de comando.

Executar o lint com a ferramenta autônoma

Se você não estiver usando o Android Studio ou o Gradle, instale as Ferramentas de linha de comando do SDK do Android para usar a ferramenta autônoma do lint. Localize a ferramenta lint em android_sdk/cmdline-tools/version/bin/lint.

Observação:se você tentar executar a ferramenta autônoma em um projeto do Gradle, ela vai gerar um erro. Sempre use 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:

• ManifestOrder
• UsesMinSdkAttributes

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 níveis de gravidade a eles. Por exemplo, você pode suprimir a verificação do lint para problemas específicos que não são relevantes para o projeto, bem como 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:

• enable
• disable ou ignore
• informational
• warning
• error
• fatal

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 valor de atributo id exclusivo para cada <issue>:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- list of issues to configure -->
</lint>

Para alterar o nível de gravidade ou desativar a verificação do lint para um problema, 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 verificação IconMissingDensityFolder é desativada completamente, e a verificação ObsoleteLayoutParam é desativada apenas nos arquivos especificados nas declarações <ignore ... /> anexadas.

Configurar a verificação do lint para arquivos de origem Kotlin, Java e XML

É possível desativar a verificação do lint para arquivos de origem Kotlin, Java e XML na caixa de diálogo Preferences:

1. Selecione File > Settings (no Windows) ou Android Studio > Preferences (no macOS ou Linux).
2. Selecione Editor > Inspeções.
3. Para desativar, desmarque o arquivo de origem apropriado.

É possível definir essas configurações para o ambiente de desenvolvimento integrado ou para projetos individuais, selecionando o perfil adequado.

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.

@SuppressLint("NewApi")
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main)

@SuppressLint("NewApi")
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

O mesmo pode ser feito em qualquer elemento combinável. O snippet de código abaixo mostra como desativar as verificações de NewApi em qualquer elemento combinável.

  @SuppressLint("NewApi")
  @Composable
  fun MyComposable{
    ...
  }
  

O exemplo a seguir mostra como desativar a verificação do lint para o problema ParserError na classe FeedProvider:

@SuppressLint("ParserError")
class FeedProvider : ContentProvider() {

@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:

@SuppressLint("all")

@SuppressLint("all")

É possível usar a mesma anotação para suprimir as 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 seções específicas de 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 abaixo mostra como desativar a verificação do lint para o problema UnusedResources em um elemento <LinearLayout> de um arquivo de layout XML. O atributo ignore é herdado pelos elementos filhos do elemento pai em que o atributo é declarado. Nesse exemplo, a verificação do lint também está desativada para o elemento filho <TextView>:

<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 a palavra-chave all:

tools:ignore="all"

Configurar opções do lint com o Gradle

O Plug-in do Android para Gradle permite configurar algumas opções do lint, como quais verificações serão executadas ou ignoradas, usando o bloco lint{} no arquivo build.gradle do módulo.

O snippet de código a seguir mostra algumas propriedades que podem ser configuradas:

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
    }
}
...

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
    }
}
...

Criar um valor de referência de alertas

Você pode capturar um snapshot do conjunto atual de alertas do projeto e usar essa captura como valor de referência para futuras execuções de inspeção. Assim, apenas novos problemas serão 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 como valor de referência, modifique o arquivo build.gradle do projeto da seguinte maneira:

android {
    lint {
        baseline = file("lint-baseline.xml")
    }
}

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 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 > Inspect Code ou na linha de comando, conforme mostrado a seguir. A saída revela a localização do arquivo lint-baseline.xml. O local do arquivo na 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 todos os problemas atuais no arquivo lint-baseline.xml. O conjunto de problemas atuais é chamado de valor de referência. Você pode verificar o arquivo lint-baseline.xml no controle de versões, caso queira 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 os problemas a serem adicionados editando o arquivo build.gradle do projeto desta forma:

android {
    lint {
        checkOnly += "NewApi" + "HandlerLeak"
        baseline = file("lint-baseline.xml")
    }
}

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, o lint vai listar apenas os bugs recém-introduzidos.

Alerta de valor de referência

Quando um valor de referência está em vigor, você recebe um alerta informativo informando que um ou mais problemas foram filtrados porque estão listados no valor de referência. Esse alerta ajuda você a se lembrar de que configurou um valor de referência e que precisa corrigir todos os problemas em algum momento.

Esse aviso informativo também monitora problemas que não são mais relatados. Essas informações indicam se você realmente corrigiu os problemas. Assim você pode recriar o valor de referência para evitar que um erro volte sem ser 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 acontece porque os valores de referência são destinados a casos em que uma base de código tem um grande número de alertas, mas você quer corrigir os problemas localmente enquanto trabalha no código.

Executar inspeções manualmente

Para executar manualmente inspeções configuradas do lint e outras inspeções do ambiente de desenvolvimento integrado, selecione Code > Inspect Code. 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 as inspeções que você quer executar (o perfil da inspeção) da seguinte forma:

1. Na visualização Android, abra seu projeto e selecione o projeto, a pasta ou o arquivo que você quer analisar.
2. Na barra de menus, selecione Code > Inspect Code.

3. Na caixa de diálogo Specify Inspection Scope, revise as configurações.

   

   As opções que aparecem na caixa de diálogo Specify Inspection Scope variam em função do item selecionado:

   • Quando você seleciona um projeto, arquivo ou diretório, a caixa de diálogo Specify Inspection Scope mostra o caminho para o projeto, arquivo ou diretório selecionado.
   • Quando você seleciona mais de um projeto, arquivo ou diretório, a caixa de diálogo Specify Inspection Scope mostra um botão de opção marcado para Selected files.

   Para mudar o objeto da inspeção, selecione um dos outros botões de opção. Consulte a caixa de diálogo Specify Inspection Scope para uma descrição de todos os campos possíveis na caixa de diálogo Specify Inspection Scope.

4. Em Perfil de inspeção, selecione o perfil que você quer usar.

5. Clique em OK para executar a inspeção.

   A Figura 4 mostra os resultados do lint e de outras inspeções do ambiente de desenvolvimento integrado gerados pela execução de Inspect Code:

   

6. No painel Inspection Results, abra e selecione categorias de erro, tipos ou problemas para ver os resultados da inspeção.

   O painel Relatório de inspeção mostra o relatório de inspeção para a categoria de erro, o tipo ou o problema selecionado no painel Resultados da inspeção e mostra o nome e a localização 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.

7. Na visualização em árvore do painel Inspection Results, clique com o botão direito do mouse em uma categoria, tipo ou problema para exibir o menu de contexto.

   Dependendo do contexto, é possível:

   • Acesse a fonte.
   • Excluir e incluir itens selecionados.
   • Suprima problemas.
   • Editar configurações.
   • Gerenciar alertas de inspeção.
   • Execute uma inspeção novamente.

Para ver descrições dos botões da barra de ferramentas, dos itens do menu de contexto e dos campos do relatório de inspeção, consulte Janela da ferramenta de resultados de inspeção.

Usar um escopo personalizado

Use um dos escopos personalizados fornecidos no Android Studio da seguinte forma:

1. Na caixa de diálogo Specify Inspection Scope, selecione Custom scope.

2. Clique na lista Custom scope para mostrar as opções:

   

   • 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 scratch e consoles abertos no projeto atual.
   • Arquivos acessados recentemente:mostra apenas os arquivos acessados recentemente no projeto atual.
   • Current File: somente o arquivo atual do projeto atual. Exibido quando você seleciona um arquivo ou uma pasta.
   • Selected Directory:somente a pasta atual do projeto atual. Aparece quando você seleciona uma pasta.
   • Class Hierarchy:quando você seleciona essa opção e clica em OK, uma caixa de diálogo é mostrada com todas as classes do projeto atual. Na caixa de diálogo, use o campo Search by Name para filtrar e selecionar as classes a serem inspecionadas. Se você não filtrar a lista de classes, a inspeção do código vai verificar todas as classes.

Se você tiver um VCS configurado para o projeto, também haverá opções para restringir a pesquisa apenas aos arquivos que foram modificados.

3. Clique em OK.

Criar um escopo personalizado

Para inspecionar uma seleção de arquivos e diretórios que não é abrangida por nenhum dos escopos personalizados disponíveis, crie um escopo personalizado:

1. Na caixa de diálogo Specify Inspection Scope, selecione Custom scope.

2. Clique nos três pontos após a lista Custom Scope.

   

   A caixa de diálogo Scopes é exibida.

   

3. Clique no botão no canto superior esquerdo da caixa de diálogo para definir um novo escopo.
4. 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.

   

5. Atribua um nome ao escopo e clique em OK.

   O painel à direita da caixa de diálogo Scopes é preenchido com opções que permitem definir o escopo personalizado.

6. Na lista, selecione Project.

   Será exibida uma lista dos projetos disponíveis.

   Observação: é possível criar o escopo personalizado para projetos ou pacotes. As etapas são as mesmas.

7. Abra as pastas do projeto, selecione o que você quer adicionar ao escopo personalizado e escolha se ele será incluído ou excluído.

   

   • Include: inclui esta pasta e os arquivos pertencentes a ela, mas não inclui nenhuma das subpastas.
   • Include Recursively: inclui esta pasta e os arquivos pertencentes a ela, bem como subpastas e arquivos relacionados.
   • Exclude: exclui esta pasta e os arquivos pertencentes a ela, mas não exclui nenhuma das subpastas.
   • Exclude Recursively: exclui esta pasta e os arquivos pertencentes a ela, bem como subpastas e arquivos relacionados.

   A Figura 10 mostra que a pasta main é incluída e que as pastas java e res são incluídas recursivamente. O azul indica uma pasta parcialmente incluída, e o verde indica pastas e arquivos incluídos recursivamente.

   

   • Se você selecionar a pasta java e clicar em Exclude Recursively, o destaque em verde vai desaparecer na pasta java e em todas as pastas e arquivos relacionados.
   • Se você selecionar o arquivo MainActivity.kt destacado em verde e clicar em Exclude, o arquivo MainActivity.kt não será mais destacado em verde, mas todos os demais itens na pasta java vão continuar em verde.
8. Clique em OK. O escopo personalizado aparece na parte de baixo da lista.

Revisar e editar perfis de inspeção

O Android Studio tem uma seleção de lint e outros perfis de inspeção que são atualizados por meio das atualizações do Android. Você pode usar esses perfis como estão ou editar os nomes, descrições, níveis de gravidade 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 Inspeções:

1. Selecione Arquivo > Configurações. (no Windows) ou Android Studio > Preferences (no macOS ou Linux).
2. Selecione Editor > Inspeções.

3. O painel Inspections mostra uma lista de inspeções compatíveis e as respectivas descrições.

   

4. Selecione a lista Profile para alternar entre inspeções Default (Android Studio) e Project Default (o projeto ativo).

   Para mais informações, consulte a página Gerenciar perfis do IntelliJ.

5. Na lista Inspections no painel esquerdo, selecione uma categoria de perfil de nível superior ou expanda um grupo e selecione um perfil específico.

   Quando você seleciona uma categoria de perfil, é possível editar todas as inspeções como uma só.

6. Selecione a lista Show Schema Actions para copiar, renomear, adicionar descrições, exportar e importar inspeções.
7. Ao concluir, clique em OK.