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

Además de completar pruebas de compilación para garantizar que tu app cumpla con los requisitos funcionales, es importante que ejecutes el código mediante lint a fin de asegurarte de que no tenga 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.

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 aún más el rendimiento del análisis con lint, también debes 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, a fin de 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 siempre que compilas tu app. Sin embargo, puedes ejecutar inspecciones manualmente o ejecutar lint desde la línea de comandos.

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.

En la Figura 1, se muestra la forma en que la herramienta lint procesa los 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 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: 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 (consulta Cómo ejecutar inspecciones manualmente). La herramienta lint verifica si existen problemas de código estructural que puedan afectar la calidad y el rendimiento de tu aplicación para Android. Te recomendamos que corrijas cualquier error que detecte lint antes de publicar la app.
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. Consulta Cómo ejecutar inspecciones manualmente.

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

Si usas Android Studio o Gradle, puedes utilizar el wrapper de Gradle a fin de invocar la tarea lint para tu proyecto ingresando uno de los siguientes comandos desde el directorio raíz de tu proyecto:

En Windows:
```
gradlew lint
```
En Linux o Mac:
```
./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

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 desde SDK Manager. Luego, puedes ubicar la herramienta lint en android_sdk/cmdline-tools/version/bin/lint.

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

En el resultado anterior aparecen cuatro advertencias y no se muestran errores: tres advertencias (ManifestOrder, UsesMinSdkAttributes y UnusedResources) en el archivo AndroidManifest.xml del proyecto y una (IconMissingDensityFolder) en el archivo de diseño Preferences.xml.

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 errores que lint comprueba y asignar un nivel de gravedad a cada uno de ellos. 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.

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 lint en Android Studio

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 el editor de código. Cuando lint encuentra un problema, destaca el código problemático en amarillo o subraya el código en rojo en el caso de los errores más graves.
En la ventana Inspection Results, después de hacer clic en Analyze > Inspect Code. Consulta Cómo ejecutar inspecciones manualmente.

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>

Puedes cambiar el nivel de gravedad del problema o inhabilitar la comprobación del error por parte de lint configurando 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 given 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>

Cómo configurar la comprobación de lint para archivos fuente Java, Kotlin y XML

Puedes inhabilitar la comprobación de tus archivos de origen Java y XML por parte de lint.

Sugerencia: Puedes administrar la función de comprobación de lint para tus archivos de origen Java, Kotlin o XML en el diálogo Default Preferences. Selecciona File > Other Settings > Default Settings y, en el panel izquierdo del diálogo Default Preferences, selecciona Editor > Inspections.

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

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 de la siguiente manera:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

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

Puedes usar 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 el 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 que realiza lint en busca de todos los errores en el elemento XML, usa la palabra clave all, como se observa a continuación:

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:

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 true, only report errors.
        ignoreWarnings true
        // If true, lint also checks all dependencies as part of its analysis. Recommended for
        // projects consisting of an app with library dependencies.
        checkDependencies true
    }
}
...

Kotlin

android {
    ...
    lintOptions {
        // Turns off checks for the issue IDs you specify.
        disable("TypographyFractions")
        disable("TypographyQuotes")
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable("RtlHardcoded")
        enable("RtlCompat")
        enable("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 true, only report errors.
        ignoreWarnings = true
        // If true, lint also checks all dependencies as part of its analysis. Recommended for
        // projects consisting of an app with library dependencies.
        isCheckDependencies = true
    }
}
...

Todos los métodos de lint que anulan el nivel de gravedad de un problema (enable, disable/ignore, informational, warning, error y fatal) 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 alertas

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.

Groovy

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

Kotlin

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 (Analyze > 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

...

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, y 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 deseas agregar algunos tipos de errores al modelo de referencia, pero no todos, puedes especificar los errores que quieres agregar editando el objeto build.gradle, de tu proyecto, de la siguiente manera.

Groovy

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

Kotlin

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

Si agregas alertas nuevas a la base de código después de crear el modelo de referencia, lint solo muestra los errores introducidos recientemente.

Alerta de modelo de referencia

Cuando los modelos de referencia están vigentes, recibes una alerta informativa que te indica que se filtraron uno o más errores porque ya estaban incluidos en el modelo de referencia. El motivo de esta alerta es para recordarte que configuraste un modelo de referencia, ya que, en una situación ideal, te convendría corregir todos los errores en algún momento.

Esta alerta informativa no solo te indica el número exacto de errores y alertas que se filtraron, sino que también realiza 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 el 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 desea corregir los errores a nivel local mientras modificas el código.

Cómo ejecutar inspecciones manualmente

Para ejecutar manualmente las inspecciones configuradas de lint y otras inspecciones del IDE, selecciona Inspect Code > Analyze. 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 Analyze > Inspect Code.
En el diálogo Specify Inspection Scope, revisa la configuración.
Figura 3: Revisa la configuración del alcance de inspección

La combinación de opciones que aparecen en el diálogo Specify Inspection Scope varía según hayas seleccionado un proyecto, una carpeta o un archivo. Puedes elegir uno de los demás botones de selección para cambiar lo que se inspeccionará. Consulta el diálogo Specify inspection scope para ver una descripción de todos los campos posibles en el diálogo Specify Inspection Scope.
- Cuando seleccionas un proyecto, un archivo o un directorio, en el diálogo Specify Inspection Scope se muestra la ruta de acceso al objeto Project, File o Directory seleccionado.
- 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.
En Inspection profile, conserva el perfil predeterminado (Project Default).
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, mediante la ejecución de Inspect Code:

Figura 4: Selecciona un error para ver la resolución
En la vista de árbol del subpanel izquierdo, observa los resultados de la inspección. Puedes expandir el árbol y seleccionar categorías y tipos de errores.
En el panel derecho, se muestra el informe de inspección correspondiente a la categoría y el tipo de error o el problema seleccionado, y se proporcionan 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 izquierdo, haz clic con el botón derecho en una categoría, un tipo o un error para abrir el menú contextual.
Según el contexto, puedes aplicar todas o algunas de las siguientes opciones: ir al origen, excluir e incluir elementos seleccionados, eliminar problemas, editar configuración, administrar alertas de inspección y volver a ejecutar una inspección.

Para ver las descripciones de los botones de la barra de herramientas de la parte izquierda, los elementos del menú contextual y los campos de informe de inspección, consulta Inspection Tool Window.

Cómo usar un alcance personalizado

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

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

Figura 5: Selecciona el alcance personalizado que quieras usar
- Project files: Todos los archivos 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. Consulta Ubicación y tipos de pruebas.
- Open Files: Solo los archivos que tienes abiertos en el proyecto actual
- Module <tu-módulo>: Solo los archivos de la carpeta del módulo correspondiente al proyecto actual.
- Current file: Solo el archivo actual del proyecto en curso. Aparece cuando tienes un archivo o una carpeta seleccionada.
- Class Hierarchy: Cuando seleccionas este alcance y haces clic en OK, aparece un diálogo con todas las clases en el proyecto actual. Usa el campo Search by Name del diálogo 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.
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 ningún alcance personalizado disponible, puedes crear un alcance personalizado.

En el diálogo Specify Inspection Scope, selecciona Custom scope.
Haz clic en los tres puntos que aparecen después de la lista desplegable 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 Add para definir un alcance nuevo.
En la lista desplegable Add Scope resultante, 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 el 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 desplegable, selecciona Project.
Aparecerá una lista de proyectos disponibles.

Nota: Puedes crear el alcance personalizado para proyectos o paquetes. Los pasos son los mismos de cualquier manera.
Expande las carpetas del proyecto, selecciona lo que desees agregar al alcance personalizado y haz clic en uno de los botones de la derecha.

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 con todos sus archivos y las subcarpetas con sus archivos.
En la Figura 10, se muestra que se incluye la carpeta main y que la carpeta java se incluye de forma recursiva. El color azul indica las carpetas incluidas parcialmente, mientras que el verde indica las carpetas y los archivos incluidos 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 desaparecerá de la carpeta java y de todas las carpetas y archivos abarcados.
- Si seleccionas el archivo MainActivity.java resaltado en verde y haces clic en Exclude, MainActivity.java dejará de resaltarse en verde, pero todo lo demás dentro de la carpeta java seguirá estando resaltado con ese color.
Haz clic en OK. El alcance personalizado aparece en la parte inferior de la lista desplegable.

Cómo revisar y editar perfiles de inspección

Android Studio incluye una selección de perfiles de lint y otros perfiles de inspección que se actualizan mediante 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 al diálogo Inspections:

Selecciona Analyze > Inspect Code.
En el diálogo Specify Scope, en Inspection Profile, haz clic en More.
Aparecerá el diálogo Inspections con una lista de inspecciones admitidas y sus descripciones.

Figura 11: Inspecciones admitidas y sus descripciones
Selecciona la lista desplegable 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 Diálogo Specify Inspection Scope de IntelliJ.
En el diálogo 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 desplegable Manage para copiar inspecciones, cambiar sus nombres, agregarles descripciones, importarlas y exportarlas.
Cuando termines, haz clic en OK.