Se usó la API de Cloud Translation para traducir esta página.

Cómo mejorar tu código con verificaciones de lint

Además de compilar pruebas para asegurarte de que tu app cumpla con sus requisitos funcionales, es importante que también ejecutes el código con la herramienta lint para asegurarte de que no contiene problemas estructurales. La herramienta lint ayuda a encontrar código poco estructurado que puede afectar la confiabilidad y eficiencia de tus apps de Android, y hacer que tu código sea más difícil de mantener. Te recomendamos que corrijas cualquier error que detecte lint antes de publicar la app.

Por ejemplo, si tus archivos de recursos XML contienen espacios de nombres no usados, se ocupa espacio y se genera procesamiento innecesario. Otros problemas estructurales, como el uso de elementos que ya no están disponibles o llamadas a API no admitidas por versiones de API de destino, pueden hacer que no se ejecute correctamente el código. Lint puede ayudarte a solucionar estos problemas.

Para mejorar el rendimiento del análisis con lint, también puedes agregar anotaciones a tu código.

Descripción general

Android Studio ofrece una herramienta de análisis de código denominada lint que puede ayudarte a identificar y corregir problemas de calidad estructural de tu código sin necesidad de ejecutar la app o escribir casos de prueba. Cada problema que detecta la herramienta se informa con un mensaje descriptivo y un nivel de gravedad, para que puedas priorizar rápidamente las mejoras críticas necesarias. Además, puedes reducir el nivel de gravedad de un problema con el objetivo de ignorar los inconvenientes que no sean relevantes para tu proyecto, o elevar el nivel de gravedad para destacar problemas específicos.

La herramienta lint comprueba los archivos de origen de tu proyecto de Android en busca de posibles errores y para realizar mejoras relacionadas con la precisión, la seguridad, el rendimiento, la usabilidad, la accesibilidad y la internacionalización. Cuando usas Android Studio, se ejecutan las inspecciones de lint y de IDE configuradas la compilar tu app. Sin embargo, puedes ejecutar inspecciones manualmente o ejecutar lint desde la línea de comandos, como se describe en esta página.

La herramienta lint integrada comprueba tu código mientras usas Android Studio. Puedes ver las advertencias y los errores de dos maneras:

Como texto emergente en la ventana del editor. Cuando lint encuentra un problema, destaca el código problemático en amarillo. En el caso de los problemas más graves, subraya el código en rojo.
En la ventana Inspection Results cuando haces clic en Code > Inspect Code.

Nota: Cuando se compila tu código en Android Studio, se ejecutan inspecciones de código IntelliJ adicionales para optimizar la revisión del código. Mantén Android Studio lo más actualizado posible para asegurarte de que las inspecciones y reglas de lint más recientes estén disponibles.

En la Figura 1, se muestra cómo la herramienta lint procesa archivos de origen de la app.

**Figura 1:** Flujo de trabajo de análisis de código con la herramienta lint.

Archivos de origen de la app: Los archivos de origen son archivos que componen tu proyecto de Android, como archivos Kotlin, Java y XML, íconos y archivos de configuración de ProGuard.
Archivo lint.xml: Es un archivo de configuración que puedes usar para especificar cualquier comprobación de lint que desees excluir y personalizar los niveles de gravedad.
Herramienta lint: Es una herramienta de análisis de código estático que puedes ejecutar en tu proyecto de Android, ya sea desde la línea de comandos o en Android Studio. La herramienta lint verifica si existen problemas de código estructural que puedan afectar la calidad y el rendimiento de tu app para Android.
Resultados de la comprobación de lint: Puedes ver los resultados de lint en la consola o en la ventana Inspection Results de Android Studio. Si ejecutas lint desde la línea de comandos, los resultados se escriben en la carpeta build/. Si quieres obtener más información, consulta la sección sobre la ejecución manual de inspecciones.

Cómo ejecutar lint desde la línea de comandos

Si usas Android Studio o Gradle, puedes utilizar el wrapper de Gradle para invocar la tarea lint para tu proyecto. Para ello, debes ingresar uno de los siguientes comandos desde el directorio raíz de tu proyecto:

Nota: Mantén el complemento de Android para Gradle lo más actualizado posible para usar las reglas de lint más recientes.

En Windows:
```
gradlew lint
```
En Linux o macOS:
```
./gradlew lint
```

Deberías ver un resultado similar al siguiente:

> Task :app:lintDebug
Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results-debug.html

Cuando la herramienta lint completa sus comprobaciones, se proporcionan rutas de acceso a las versiones XML y HTML del informe de lint. Luego, puedes navegar al informe HTML y abrirlo en el navegador, como se muestra en la Figura 2.

**Figura 2:** Ejemplo de informe HTML de lint.

Si tu proyecto incluye variantes de compilación, la ejecución de lint solo verificará la variante predeterminada. Si deseas ejecutar lint en una variante diferente, debes escribir en mayúscula el nombre de la variante y agregarle lint como prefijo.

./gradlew lintRelease

Nota: Lint no se ejecuta automáticamente como parte de la compilación. Te recomendamos que ejecutes lint de forma explícita como parte de una compilación de integración continua para que veas las verificaciones de lint más recientes cuando compiles tu código fuente existente.

Para obtener más información sobre cómo ejecutar tareas de Gradle desde la línea de comandos, consulta Cómo compilar tu app desde la línea de comandos.

Cómo ejecutar lint con la herramienta independiente

Si no usas Android Studio ni Gradle, puedes utilizar la herramienta lint independiente después de instalar las herramientas de línea de comandos del SDK de Android. Puedes encontrar la herramienta lint en android_sdk/cmdline-tools/version/bin/lint.

Nota: Si intentas ejecutar la herramienta independiente en un proyecto Gradle, se produce un error. Deberías usar siempre gradle lint (en Windows) o ./gradlew lint (en macOS o Linux) para ejecutar lint en un proyecto de Gradle.

Para ejecutar lint en una lista de archivos de un directorio del proyecto, usa el siguiente comando:

lint [flags] <project directory>

Por ejemplo, puedes publicar el siguiente comando para analizar los archivos del directorio myproject y sus subdirectorios. El ID de problema MissingPrefix le indica a lint que solo busque atributos XML a los que les falte el prefijo del espacio de nombres de Android.

lint --check MissingPrefix myproject

Para ver una lista completa de marcas y argumentos de línea de comandos compatibles con la herramienta, usa el siguiente comando:

lint --help

En el siguiente ejemplo, se muestra el resultado de la consola cuando se ejecuta el comando de lint en un proyecto llamado "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

El resultado de ejemplo muestra cuatro advertencias y ningún error.

Dos de las advertencias se relacionan con el archivo AndroidManifest.xml del proyecto:

ManifestOrder
UsesMinSdkAttributes

Una advertencia se relaciona con el archivo de diseño Preferences.xml: UnusedResources.

Una advertencia se relaciona con el directorio res: IconMissingDensityFolder.

Cómo configurar lint para suprimir advertencias

De manera predeterminada, cuando ejecutas un análisis de lint, la herramienta comprueba todos los errores que admite lint. También puedes restringir los problemas que lint comprueba y puedes asignar niveles de gravedad a los problemas. Por ejemplo, puedes suprimir la comprobación de lint de errores específicos que no son relevantes para tu proyecto y configurar lint para que informe acerca de problemas que no sean críticos y cuyo nivel de gravedad sea más bajo.

Los niveles de gravedad son los siguientes:

enable
disable o ignore
informational
warning
error
fatal

Puedes configurar la comprobación de lint para diferentes niveles:

Globalmente (proyecto completo)
Módulo de proyecto
Módulo de producción
Módulo de prueba
Archivos abiertos
Jerarquía de clases
Alcances del sistema de control de versiones (VCS)

Cómo configurar el archivo de lint

Puedes especificar tus preferencias de comprobación de lint en el archivo lint.xml. Si creas manualmente este archivo, colócalo en el directorio raíz de tu proyecto de Android.

En el archivo lint.xml se incluye una etiqueta principal <lint> que contiene uno o más elementos <issue> secundarios. Lint define un valor de atributo id único para cada <issue>.

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

Para cambiar el nivel de gravedad del problema o inhabilitar la comprobación del error por parte de lint, configura el atributo de gravedad en la etiqueta <issue>.

Sugerencia: Para ver una lista completa de errores admitidos por lint y sus ID de error correspondientes, ejecuta el comando lint --list.

Archivo lint.xml de ejemplo

En el siguiente ejemplo, se muestra el contenido de un archivo 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 ejemplo muestra cómo se informan los diferentes tipos de problemas. La marca de IconMissingDensityFolder está completamente inhabilitada y la marca de ObsoleteLayoutParam solo se inhabilita en los archivos especificados en las declaraciones <ignore ... /> delimitadas.

Cómo configurar la comprobación de archivos de origen Kotlin, Java y XML por parte de lint

Puedes desactivar la comprobación de archivos de origen Kotlin, Java y XML por parte de lint en el diálogo Preferences:

Selecciona File > Settings (en Windows) o Android Studio > Preferences (en macOS o Linux).
Selecciona Editor > Inspections.
Para inhabilitarlo, anula la selección del archivo de origen correspondiente.

Puedes configurar esto para proyectos IDE o individuales seleccionando el perfil que corresponda.

Cómo configurar la comprobación de lint en Java o Kotlin

Para inhabilitar la comprobación de lint para una clase o un método específicos en tu proyecto de Android, agrega la anotación @SuppressLint a ese código.

En el siguiente ejemplo, se muestra la manera de desactivar la comprobación por parte de lint en busca del error de NewApi en el método onCreate. La herramienta lint continúa realizando la comprobación en busca del error de NewApi en otros métodos de esta clase.

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);

Lo mismo se puede lograr en cualquier elemento componible. En el siguiente fragmento de código, se muestra cómo puedes desactivar las verificaciones de NewApi en cualquier elemento componible.

Kotlin

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

En el siguiente ejemplo, se muestra la manera de desactivar la comprobación que realiza lint en busca del error ParserError en la clase FeedProvider:

Kotlin

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

Java

@SuppressLint("ParserError")
public class FeedProvider extends ContentProvider {

Para eliminar la comprobación de todos los errores de lint en el archivo, usa la palabra clave all:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

Puedes usar la misma anotación para suprimir las verificaciones de lint en cualquier función de componibilidad.

Cómo configurar la comprobación de lint en XML

Usa el atributo tools:ignore para inhabilitar la comprobación que realiza lint en busca de secciones específicas de tus archivos en formato XML. Ingresa el siguiente valor de espacio de nombres en el archivo lint.xml, de modo que la herramienta lint reconozca el atributo:

namespace xmlns:tools="http://schemas.android.com/tools"

En el siguiente ejemplo, se muestra la manera de desactivar la comprobación que realiza lint en busca del error UnusedResources en un elemento <LinearLayout> de un archivo de diseño XML. El atributo ignore es heredado por los elementos secundarios del elemento primario en el que se declara el atributo. En este ejemplo, la comprobación de lint también está inhabilitada para el elemento secundario <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 inhabilitar más de un error, enumera los errores que desees inhabilitar en una string separada por comas. Por ejemplo:

tools:ignore="NewApi,StringFormatInvalid"

Para eliminar la comprobación de todos los errores de lint en el elemento XML, usa la palabra clave all:

tools:ignore="all"

Cómo configurar las opciones de lint con Gradle

El complemento de Android para Gradle te permite configurar ciertas opciones de lint, como las comprobaciones que deben ejecutarse o ignorarse, a través del bloque lint{} de tu archivo build.gradle de nivel de módulo.

En el siguiente fragmento de código, se muestran algunas propiedades que puedes configurar:

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 los métodos de lint que anulan el nivel de gravedad de un problema respetan el orden de configuración. Por ejemplo, si se configura un problema como fatal en finalizeDsl(), se anula la inhabilitación en el DSL principal.

Cómo crear un modelo de referencia de advertencias

Puedes tomar una instantánea del conjunto de advertencias actual de tu proyecto y, luego, usar la instantánea como modelo de referencia para futuras ejecuciones de inspección, de modo que solo se notifiquen errores nuevos. La instantánea de modelo de referencia te permite comenzar a usar lint para detener la compilación sin tener que regresar y abordar todos los errores existentes.

Para crear un resumen de modelo de referencia, modifica el archivo build.gradle de tu proyecto de la siguiente manera.

Kotlin

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

Groovy

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

Cuando agregas esta línea por primera vez, se crea el archivo lint-baseline.xml para establecer tu modelo de referencia. A partir de ese momento, las herramientas solo leen el archivo para determinar el modelo de referencia. Si deseas crear un modelo de referencia nuevo, borra manualmente el archivo y vuelve a ejecutar lint para recrearlo.

Luego, ejecuta lint desde el IDE. Para ello, selecciona Code > Inspect Code o desde la línea de comando de la siguiente manera. El resultado muestra la ubicación del archivo lint-baseline.xml (es posible que en tu configuración sea diferente de la que se muestra aquí).

$ ./gradlew lintDebug -Dlint.baselines.continue=true
...
Wrote XML report to file:///app/lint-baseline.xml
Created baseline file /app/lint-baseline.xml

La ejecución de lint registra todos los errores actuales en el archivo lint-baseline.xml. El conjunto de errores actuales se denomina modelo de referencia. Puedes verificar el archivo lint-baseline.xml en el control de versiones si deseas compartirlo con otras personas.

Cómo personalizar el modelo de referencia

Si quieres agregar solo algunos tipos de errores al modelo de referencia, especifícalos editando el archivo build.gradle de tu proyecto de la siguiente manera:

Kotlin

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

Groovy

android {
    lintOptions {
        checkOnly 'NewApi', 'HandlerLeak'
        baseline file("lint-baseline.xml")
    }
}

Si agregas nuevas advertencias a la base de código después de crearla, lint solo muestra los errores introducidos recientemente.

Alerta de modelo de referencia

Cuando un modelo de referencia está vigente, recibes una alerta informativa que te indica que se filtraron uno o más errores porque ya estaban incluidos en el modelo de referencia. Esta advertencia te ayuda a recordar que configuraste un modelo de referencia y que tienes que corregir todos los errores en algún momento.

Esta advertencia informativa también hace un seguimiento de los errores que ya no se informan. Estos datos te permiten saber si realmente corregiste los errores, por lo que puedes volver a crear el modelo de referencia para evitar que un error pase desapercibido.

Nota: Los modelos de referencia se habilitan cuando ejecutas inspecciones en modo por lotes en el IDE, pero se ignoran para las comprobaciones en el editor que se ejecutan en segundo plano cuando editas un archivo. La razón es que los modelos de referencia están destinados para los casos en los que una base de código tiene una gran cantidad de alertas existentes, pero deseas corregir los errores a nivel local mientras modificas el código.

Cómo ejecutar inspecciones manualmente

Para ejecutar inspecciones lint o del IDE de otro tipo, selecciona Code > Inspect Code. Los resultados de la inspección aparecen en la ventana Inspection Results.

Cómo establecer el alcance y el perfil de la inspección

Selecciona los archivos que desees analizar (alcance de inspección) y las inspecciones que quieras ejecutar (perfil de inspección), de la siguiente manera:

En la vista Android, abre tu proyecto y selecciona el proyecto, la carpeta o el archivo que desees analizar.
Desde la barra de menú, selecciona Code > Inspect Code.
En el diálogo Specify Inspection Scope, revisa la configuración.

Figura 3: Revisa la configuración del alcance de inspección.

Las opciones que aparecen en el diálogo Specify Inspection Scope varía dependiendo de si seleccionaste un proyecto, una carpeta o un archivo.
- Cuando seleccionas un proyecto, un archivo o un directorio, en el diálogo Specify Inspection Scope se muestra la ruta de acceso al proyecto, archivo o directorio que seleccionaste.
- Cuando eliges más de un proyecto, archivo o directorio, el diálogo Specify Inspection Scope muestra un botón de selección marcado para Selected files.
Para cambiar lo que quieres inspeccionar, marca uno de los botones de selección. Consulta el diálogo Specify Inspection Scope para ver una descripción de todos los campos posibles en el diálogo Specify Inspection Scope.
En Inspection profile, selecciona el perfil que quieres usar.
Haz clic en OK para ejecutar la inspección.

En la Figura 4, se muestran los resultados de la inspección que realiza lint, y de otras inspecciones del IDE, desde la ejecución de Inspect Code:

Figura 4: Resultados de la inspección. Selecciona un error para ver la resolución.
En el panel Inspection Results observa los resultados de la inspección. Puedes expandir el árbol y seleccionar categorías y tipos de errores.

El panel Inspection Report muestra el informe de inspección de la categoría de error el tipo o el problema seleccionado en el panel Inspection Results y muestra el nombre y la ubicación del error. Cuando es posible, en este informe se muestra información adicional; por ejemplo, una sinopsis del problema para ayudarte a corregirlo.
En la vista de árbol del panel Inspection Results, haz clic con el botón derecho en una categoría, un tipo o un error para ver el menú contextual.

Según el contexto, puedes hacer lo siguiente:
- Ir a la fuente
- Excluir o incluir elementos seleccionados
- Suprimir problemas
- Editar la configuración
- Administrar alertas de inspección
- Volver a ejecutar una inspección

Para ver las descripciones de los botones de la barra de herramientas, los elementos del menú contextual y los campos de informe de inspección, consulta Inspection Results tool window.

Cómo usar un alcance personalizado

Usa uno de los alcances personalizados incluidos en Android Studio, como se observa a continuación:

En el diálogo Specify Inspection Scope, selecciona Custom scope.
Haz clic en la lista Custom scope para mostrar tus opciones:

Figura 5: Selecciona qué alcance personalizado quieres usar.
- All Places: Todos los archivos.
- Project files: Todos los archivos del proyecto actual.
- Project Source Files: Solo los archivos del origen del proyecto actual.
- Archivos de producción del proyecto: Solo los archivos de producción del proyecto actual.
- Project Test Files: Solo los archivos de prueba del proyecto actual.
- Scratches and Consoles: Solo los archivos reutilizables y las consolas que tienes abiertas en el proyecto actual.
- Recently Viewed Files: Solo los archivos vistos recientemente en el proyecto actual.
- Current file: Solo el archivo actual del proyecto en curso. Aparece cuando tienes un archivo o una carpeta seleccionada.
- Selected Directory: Solo la carpeta actual del proyecto actual. Aparece cuando tienes una carpeta seleccionada.
- Class Hierarchy: Cuando seleccionas esta opción y haces clic en OK, aparece un diálogo con todas las clases en el proyecto actual. En el diálogo, usa el campo Search by Name para filtrar y seleccionar las clases que se inspeccionarán. Si no filtras la lista de clases, la inspección de código realiza una inspección en todas ellas.

Si tienes un VCS configurado para el proyecto, también hay opciones para restringir la búsqueda a solo los archivos que se modificaron.

Haz clic en OK

Cómo crear un alcance personalizado

Cuando deseas inspeccionar una selección de archivos y directorios que no se contemplen en ninguno de los alcances personalizados disponibles, puedes crear un alcance personalizado:

En el diálogo Specify Inspection Scope, selecciona Custom scope.
Haz clic en los tres puntos después de la lista Custom Scope.

Figura 6: Diálogo Specify Inspection Scope.

Aparecerá el diálogo Scopes.

Figura 7: Cómo crear un alcance personalizado.
Haz clic en el botón de la esquina superior izquierda para definir un nuevo alcance.
En la lista Add Scope que aparece, selecciona Local.
Ambos alcances, local y compartido, se usan dentro del proyecto para la función Inspect Code. Un alcance Compartido también se puede usar con otras funciones del proyecto que tienen un campo de alcance. Por ejemplo, cuando haces clic en Edit Settings para cambiar la configuración de Find Usages, en el diálogo resultante se incluye un campo Scope en el que puedes seleccionar un alcance compartido.

Figura 8: Selecciona un alcance compartido en el diálogo Find Usages.
Asígnale un nombre al alcance y haz clic en OK.
El panel derecho del diálogo Scopes se completa con opciones que te permiten definir el alcance personalizado.
En la lista, selecciona Project.
Aparecerá una lista de proyectos disponibles.

Nota: Puedes crear el alcance personalizado para proyectos o paquetes. Los pasos son los mismos.
Expande las carpetas del proyecto, selecciona lo que desees agregar al alcance personalizado y selecciona si quieres incluirlo o excluirlo.

Figura 9: Definición de un alcance personalizado.
- Include: Incluye esta carpeta y sus archivos, pero no sus subcarpetas.
- Include Recursively: Incluye esta carpeta con todos sus archivos y las subcarpetas con sus archivos.
- Exclude: Excluye esta carpeta y sus archivos, pero no sus subcarpetas.
- Exclude Recursively: Excluye esta carpeta y sus archivos, además de sus subcarpetas y sus archivos.
En la Figura 10, se muestra que se incluye la carpeta main, y que las carpetas java y res se incluye de forma recursiva. El color azul indica que una carpeta se incluyó parcialmente y el verde indica que se incluyeron carpetas y archivos de forma recursiva.

Figura 10: Patrón de ejemplo para un alcance personalizado.
- Si seleccionas la carpeta java y haces clic en Exclude Recursively, el resaltado verde desaparece de la carpeta java y de todas las carpetas y archivos abarcados.
- Si seleccionas el archivo MainActivity.kt destacado en color verde y haces clic en Exclude, MainActivity.kt ya no se destaca en color verde, pero todo lo demás dentro de la carpeta java permanece en color verde.
Haz clic en OK. El alcance personalizado aparece al final de la lista.

Cómo revisar y editar perfiles de inspección

Android Studio tiene una selección de perfiles de lint y otros perfiles de inspección que se actualizan a través de actualizaciones de Android. Puedes usar estos perfiles como se encuentran o editar sus nombres, descripciones, niveles de gravedad y alcances. También puedes activar y desactivar grupos enteros de perfiles o perfiles separados dentro de un grupo.

Para acceder a la configuración de Inspections, haz lo siguiente:

Selecciona File > Settings (en Windows) o Android Studio > Preferences (en macOS o Linux).
Selecciona Editor > Inspections.
El panel Inspections muestra una lista de inspecciones admitidas y sus descripciones.

Figura 11: Inspecciones admitidas y sus descripciones.
Selecciona la lista Profile para activar o desactivar las inspecciones Default (Android Studio) y Project Default (el proyecto activo).

Para obtener más información, consulta la página Manage profiles de IntelliJ.
En la lista Inspections del panel izquierdo, selecciona una categoría de perfil de nivel superior o expande un grupo y selecciona un perfil específico.

Cuando seleccionas una categoría de perfil, puedes editar todas las inspecciones de esa categoría como una única inspección.
Selecciona la lista Show Schema Actions para copiar inspecciones, cambiar sus nombres, agregarles descripciones, importarlas y exportarlas.
Cuando termines, haz clic en OK.