Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

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 con una estructura ineficiente que puede afectar la confiabilidad y eficacia 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 el rendimiento de lint aún más, 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 severidad, a fin de que puedas priorizar rápidamente las mejoras críticas necesarias. Además, puedes reducir el nivel de severidad de un problema para ignorar los inconvenientes que no sean relevantes para tu proyecto, o elevar el nivel de severidad 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 al compilar 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 severidad.
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 app de 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:lint
    Ran lint on variant release: 5 issues found
    Ran lint on variant debug: 5 issues found
    Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results.html
    Wrote XML report to file:<path-to-project>/app/build/reports/lint-results.xml
    

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 y, en cambio, deseas ejecutar la tarea lint para solo una variante de compilación específica, debes escribir en mayúsculas el nombre de la variante y agregarle un prefijo con lint.

    gradlew lintDebug
    

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 del SDK de Android desde SDK Manager. Luego, puedes ubicar la herramienta lint en el directorio android_sdk/tools/.

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 severidad 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 severidad 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

Puede especificar tus preferencias de comprobación de lint en el archivo lint.xml. Si creas este archivo manualmente, 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 más elementos <issue> secundarios. lint define un valor de atributo de id único para cada <issue>.

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

Puedes cambiar el nivel de severidad del problema o inhabilitar la comprobación del error por parte de lint configurando el atributo de severidad en la etiqueta <issue>.

Sugerencia: Para ver una lista completa de los 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 cómo puedes desactivar la comprobación de lint para el problema de NewApi en el método onCreate. La herramienta lint continúa buscando el 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 cómo desactivar la comprobación de lint para el 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 XML. Ingresa el siguiente valor de espacio de nombres en el archivo lint.xml, de modo que la herramienta de 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 lintOptions {} de tu archivo build.gradle a nivel de módulo. En el siguiente fragmento de código, se muestran algunas propiedades que puedes configurar:

    android {
      ...
      lintOptions {
        // 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.
        check '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
      }
    }
    ...
    

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 una instantánea de modelo de referencia, modifica el archivo build.gradle de tu proyecto de la siguiente manera.

    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.

    android {
      lintOptions {
        check '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:

  1. En la vista Android, abre tu proyecto y selecciona el proyecto, la carpeta o el archivo que desees analizar.
  2. Desde la barra de menú, selecciona Analyze > Inspect Code.
  3. En el diálogo Specify Inspection Scope, revisa la configuración. Especificar el alcance de la inspecció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.
  4. En Inspection profile, conserva el perfil predeterminado (Project Default).
  5. 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 su resolución

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

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

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

    Seleccionar el alcance de la inspección

    Figura 5: Selecciona el alcance personalizado que quieras usar

    • Archivos de proyecto: Todos los archivos del proyecto actual.
    • Archivos de producción del proyecto: Solo los archivos de producción del proyecto actual.
    • Archivos de prueba del proyecto: Solo los archivos de prueba del proyecto actual. Consulta Ubicación y tipos de pruebas.
    • Abrir archivos: Solo los archivos que tienes abiertos en el proyecto actual.
    • Módulo <tu-módulo>: Solo los archivos de la carpeta del módulo correspondiente al proyecto actual.
    • Archivo actual: Solo el archivo actual del proyecto en curso. Aparece cuando tienes un archivo o una carpeta seleccionada.
    • Jerarquía de clases: 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.
  3. 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.

  1. En el diálogo Specify Inspection Scope, selecciona Custom scope.
  2. 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

  3. Haz clic en Agregar para definir un alcance nuevo.
  4. 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

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

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

  7. 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.
  8. Haz clic en OK. El alcance personalizado aparecerá 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 severidad 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:

  1. Selecciona Analyze > Inspect Code.
  2. 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 descripciones

  3. Selecciona la lista desplegable Profile para activar o desactivar las inspecciones Default (Android Studio) y Project Default (proyecto activo). Para obtener más información, consulta la página Diálogo Specify Inspection Scope de IntelliJ.
  4. En el diálogo Inspections del subpanel 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.
  5. Selecciona la lista desplegable Manage para copiar inspecciones, cambiar sus nombres, agregarles descripciones, importarlas y exportarlas.
  6. Al terminar, haz clic en OK.