Lint: fundamentos, analisador estático para projetos Android

Autor: IT Sectr Publicado: 2026-02-13 Tempo de leitura: 10 min

Android Lint — um analisador estático de código integrado no Android Studio e Gradle que verifica os ficheiros fonte de acordo com as recomendações da Google. O Lint encontra potenciais erros antes da compilação: recursos não utilizados, problemas de desempenho, fugas de memória e incompatibilidade de API. A ferramenta analisa ficheiros XML, Java e Kotlin. Saiba mais em Android Lint Guide.

Principais conclusões

  • Android Lint — um analisador estático integrado no Android Studio e Gradle para verificação de código
  • Verificação Lint — análise de XML, Java e Kotlin à procura de erros antes da compilação da aplicação
  • lint.xml — ficheiro de configuração para personalizar regras Lint num projeto Android
  • Lint baseline — um mecanismo para congelar avisos existentes para adoção gradual
  • Integração CI — execução do Lint no servidor de compilação para controlo automático de qualidade de código

O que é o Lint — um analisador estático de código?

Android Lint é uma ferramenta de análise estática incluída no SDK Android e no Android Studio. O Lint examina o código fonte da aplicação sem o executar e encontra problemas que o compilador ignora: recursos não utilizados, localização incorreta, potenciais fugas de memória, incompatibilidade de API com minSdkVersion e violações das recomendações de desempenho da Google.

A análise estática é um método de verificação de software que não requer execução real de código. Ao contrário do compilador, que apenas verifica sintaxe e tipos, um analisador estático procura erros lógicos, antipadrões e desvios das melhores práticas. O Lint realiza mais de 200 verificações integradas em categorias: correção, desempenho, segurança, acessibilidade, usabilidade e I18N.

O Lint funciona em vários níveis: Análise XML verifica layouts, recursos (strings, colors, dimens), o manifesto e ficheiros de configuração. Análise Java/Kotlin examina o código fonte à procura de chamadas de API obsoletas, problemas de threading e fugas de contexto. Análise Gradle verifica a configuração de compilação para compatibilidade de versões.

Como o Lint verifica o código de projetos Android

A verificação Lint é iniciada através do Android Studio (Analyze > Inspect Code) ou pelo comando Gradle: ./gradlew lint. O resultado é um relatório HTML na pasta build/reports/lint-results.html e um relatório XML para sistemas CI. O Lint analisa cada ficheiro de forma independente, aplicando um conjunto de regras (Issues), cada uma com um ID único, descrição, categoria e nível de gravidade.

Níveis de gravidade do Lint: Error (bloqueia a compilação), Warning (afeta a qualidade), Informational (para referência), Ignore (ignorado por predefinição). Os níveis são configurados no lint.xml. Os erros do Lint podem ser configurados para falhar a compilação Gradle quando presentes através de lintOptions.abortOnError true.

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

Lint baseline — um ficheiro que marca os avisos atuais como aceitáveis. Criado com o comando lint --baseline baseline.xml. Após adicionar uma baseline ao projeto, o Lint apenas reporta novos problemas. Isto é conveniente para introduzir o Lint num projeto antigo com centenas de avisos — a equipa corrige erros gradualmente.

Configurar regras Lint em ficheiros de configuração

lint.xml — um ficheiro de configuração na raiz do projeto para personalizar regras Lint. Especifica regras ignoradas, níveis de gravidade e exceções para ficheiros ou diretórios específicos. O ficheiro é criado manualmente e aplicado globalmente a todos os módulos do projeto. Sem lint.xml, todas as regras funcionam com as configurações predefinidas.

xml
<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Desativar verificação de recursos não utilizados -->
    <issue id="UnusedResources" severity="ignore" />

    <!-- Aumentar gravidade de fuga de contexto -->
    <issue id="StaticFieldLeak" severity="error" />

    <!-- Ignorar em ficheiros gerados -->
    <issue id="MissingTranslation" severity="ignore">
        <ignore path="build/generated" />
    </issue>
</lint>

@SuppressLint — uma anotação para desativar o Lint ao nível do método ou classe em Java/Kotlin. Exemplo: @SuppressLint("SetTextI18n") para um método onde o texto é definido dinamicamente num TextView. A anotação @RequiresApi especifica o nível mínimo de API para um método — o Lint não emitirá um aviso se minSdk exceder o valor especificado.

Executar verificação Lint num pipeline CI/CD

A integração CI do Lint é uma prática padrão no desenvolvimento Android. O comando ./gradlew lint executa a análise em todos os módulos e gera relatórios. Em configurações CI/CD (Jenkins, GitLab CI, GitHub Actions), o Lint é executado em cada pull request. Se forem encontrados erros, a compilação falha e o programador recebe uma notificação com o relatório HTML do Lint.

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

O relatório HTML do Lint contém uma tabela de todos os problemas encontrados com categoria, ID da regra, ficheiro, linha e descrição. O relatório está disponível no servidor CI ou é publicado como um artefacto de compilação. O relatório XML (lint-results.xml) é utilizado para integração com sistemas de análise de código (SonarQube, CodeClimate) e criação automática de tarefas em rastreadores (Jira, YouTrack).

Lint em pull requests — configure GitHub Actions ou GitLab CI para que o Lint seja executado automaticamente quando um MR/PR é criado. Se o Lint encontrar erros, o CI retorna um estado de falha e a fusão é bloqueada. Isto impede que código problemático entre no ramo principal e mantém a qualidade da base de código.

Principais categorias de regras Lint no Android

As categorias Lint cobrem todos os aspetos do desenvolvimento Android. A Google divide as regras em 12 categorias, cada uma responsável por um tipo específico de problema. As categorias mais importantes são Correctness, Performance, Security e Accessibility. Os programadores precisam de conhecer as verificações chave de cada categoria para trabalhar eficazmente com o Lint.

CategoriaDescriçãoRegra de exemplo
CorrectnessErros que afetam a funcionalidade da aplicaçãoMissingPermission, WrongConstant
PerformanceProblemas de desempenho e memóriaUnusedResources, ViewHolder, DrawAllocation
SecurityVulnerabilidades e violações de segurançaExportedContentProvider, WorldReadableFiles
AccessibilityProblemas de acessibilidade para utilizadoresContentDescription, TouchTargetSize
UsabilityUsabilidade e experiência do utilizadorNotSibling, BackButton, HardcodedText
I18NInternacionalização e localizaçãoMissingTranslation, ExtraTranslation

As regras de desempenho são as mais úteis na prática. UnusedResources encontra recursos declarados em XML mas não utilizados no código. ViewHolder verifica se o padrão ViewHolder é utilizado nos adaptadores RecyclerView. DrawAllocation alerta sobre a criação de objetos no método onDraw. Corrigir estes problemas reduz o tamanho do APK e acelera a aplicação.

As regras de segurança são obrigatórias para aplicações publicadas. ExportedContentProvider verifica se um ContentProvider está exportado sem proteção. WorldReadableFiles alerta sobre a criação de ficheiros acessíveis a todas as aplicações. AllowBackup verifica a flag allowBackup no manifesto — recomenda-se desativá-la para segurança dos dados.

Perguntas frequentes

Qual é a diferença entre o Lint e um compilador?

O compilador verifica sintaxe e tipos, traduzindo código em bytecode para execução. O Lint analisa código sem compilação e encontra problemas lógicos que o compilador ignora: variáveis não utilizadas, fugas de recursos, problemas de localização, violações de desempenho e incompatibilidade de API com minSdkVersion. O Lint complementa o compilador mas não o substitui.

Como desativar um aviso específico do Lint no código?

Em ficheiros XML, use o atributo tools:ignore com o ID da regra: tools:ignore="UnusedResources". Em Java/Kotlin, adicione a anotação @SuppressLint a um método ou classe: @SuppressLint("SetTextI18n"). Para um diretório inteiro, configure lint.xml com um nó issue e severity="ignore". Para todo o projeto, configure lint.xml na raiz do módulo.

O que é uma Lint baseline e como usá-la?

Lint baseline é um ficheiro XML que marca os avisos atuais do Lint como aceitáveis. É criado com o comando ./gradlew lint -Pbaseline ou através de lintOptions.baselineFile no build.gradle. Após adicionar uma baseline, o Lint apenas reporta novos problemas. Isto é conveniente para introduzir o Lint em projetos com código legado — a equipa corrige erros iterativamente.

Como criar uma regra Lint personalizada?

Crie um novo módulo Java/Kotlin com dependências de lint-api e lint-checks da biblioteca com.android.tools.lint. Implemente uma classe Detector para encontrar problemas e uma classe Issue para os descrever. Compile o módulo num JAR, coloque-o na pasta lintLibs do seu projeto Android. O Android Studio detetará automaticamente as regras personalizadas.

Porque é que a verificação Lint é obrigatória em projetos Android?

O Lint encontra problemas que o compilador não vê: fugas de contexto (Activity, Fragment), incompatibilidade de API com minSdkVersion, problemas de configuração Gradle, ícones PNG demasiado grandes, falta de recursos alternativos para diferentes idiomas e configurações de ecrã. A Google Play recomenda o Lint antes da publicação. Sem Lint, a aplicação pode falhar em dispositivos mais antigos.

Resumo

  • Android Lint — um analisador estático de código integrado no SDK Android e Android Studio
  • Verificação Lint — análise de XML, Java e Kotlin para potenciais erros antes da compilação
  • lint.xml — ficheiro de configuração para personalizar regras Lint num projeto Android
  • Lint baseline — um mecanismo para congelar avisos existentes para adoção gradual
  • Integração CI — executar Lint no servidor de compilação bloqueia PRs com erros críticos
  • Categorias Lint — Correctness, Performance, Security, Accessibility e I18N
  • @SuppressLint — anotação para desativar o Lint ao nível do método ou classe

Vamos desenvolver um aplicativo móvel chave na mão

A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.

Discutir o projeto

Leia também