Cómo preparar tu biblioteca para el lanzamiento

En esta página, se describen las propiedades y opciones necesarias para preparar el proyecto de la biblioteca de Android para su publicación mediante el complemento de Android para Gradle (AGP). Incluso si configuras algunas de estas propiedades cuando creas tu biblioteca, revisa la siguiente guía para optimizar la configuración.

Cómo elegir un espacio de nombres

Las bibliotecas de Android deben declarar un espacio de nombres para que puedan generar una clase R única cuando se compilan sus recursos. Este espacio de nombres debe coincidir estrechamente con el paquete de clase raíz de la biblioteca para evitar confusiones cuando los usuarios importan las clases regulares de la biblioteca y su clase R.

A partir de AGP 7.0, puedes configurar el espacio de nombres en el archivo build.gradle de la app como se muestra en el siguiente ejemplo de código:

Groovy

android {
  namespace = 'com.example.library'
}

Kotlin

android {
  namespace = "com.example.library"
}

El espacio de nombres es una propiedad de la biblioteca orientada al desarrollador. No está relacionado con la identidad de la aplicación, que se establece mediante la propiedad applicationId.

En versiones anteriores de AGP, las propiedades applicationId (para una app) y namespace (para una biblioteca) podían configurarse con el atributo package del manifiesto, lo que generaba confusión.

Selecciona un valor de minSdkVersion

Elegir un valor de minSdkVersion para tu biblioteca es un aspecto importante a la hora de publicarla. minSdkVersion debe reflejar la versión mínima de Android que tu código puede admitir.

Ten en cuenta las siguientes consideraciones cuando elijas una minSdkVersion:

  • Elegir un valor bajo de minSdkVersion suele permitir una distribución más amplia de tu biblioteca.

    Por lo general, el código de una biblioteca no se ejecuta, a menos que la app lo llame de forma explícita. Una app se puede ejecutar en una versión de Android anterior a la requerida por una dependencia de la biblioteca (si la biblioteca no es esencial para la funcionalidad principal de la app) mediante verificaciones de tiempo de ejecución antes de llamar a la biblioteca. Por lo tanto, establece el valor minSdkVersion de la biblioteca en un nivel lo suficientemente bajo como para que se pueda incorporar en las apps y se pueda llamar cuando sea posible para llegar a más usuarios.

  • Elegir un valor alto de minSdkVersion podría evitar que las aplicaciones incluyan la biblioteca.

    La combinación de manifiestos, un paso en AGP que combina archivos de manifiesto de la app y sus dependencias, exige que ninguna dependencia tenga una minSdkVersion más alta que la app.

  • Si eliges un valor alto de minSdkVersion, es posible que los desarrolladores de apps inhabiliten las verificaciones de seguridad de la combinación de manifiestos, lo que causará problemas más adelante en el proceso de compilación.

    Como la combinación de manifiestos evita que los proyectos de apps incluyan bibliotecas con una minSdkVersion mayor que la de la propia app, los desarrolladores de apps pueden inhabilitar las verificaciones de seguridad de la combinación de manifiestos para minimizar los errores de compilación. Sin embargo, esto genera un verdadero problema de incompatibilidad en sentido descendente.

  • Es posible que sea necesario elegir un valor de minSdkVersion alto en casos especiales en los que el manifiesto de una biblioteca incluya un receptor de emisión o algún otro mecanismo mediante el cual su código se active automáticamente.

    En estos casos, elegir un valor alto de minSdkVersion garantiza que se pueda ejecutar el código. De manera alternativa, puedes inhabilitar el comportamiento automatizado de modo que la app pueda habilitar la ejecución de la biblioteca después de realizar las comprobaciones correctas.

Para permitir la incorporación en apps, usa la anotación RequiresApi en la biblioteca para indicar a los emisores que deben realizar verificaciones de tiempo de ejecución. Android Lint usa la información de RequiresApi para sus inspecciones. Si quieres obtener más recursos sobre el uso de anotaciones para mejorar el código de tu API y las APIs en general, consulta Cómo mejorar la inspección del código con anotaciones.

Cómo configurar los metadatos de AAR

Una biblioteca de Android se empaqueta en forma de un archivo Android ARchive (AAR). Los metadatos de AAR consisten en propiedades que ayudan a AGP a consumir bibliotecas. Si tu biblioteca se consume por una configuración incompatible y los metadatos de AAR están configurados, los usuarios verán un mensaje de error que los ayudará a resolver el problema.

Cómo elegir un valor de minCompileSdk

A partir de la versión 4.1, AGP es compatible con minCompileSdk. Esto indica el compileSdk mínimo que pueden usar los proyectos que realicen consumos. Si tu biblioteca contiene entradas de manifiesto o recursos que usan atributos de plataforma más recientes, debes configurar este valor.

El valor minCompileSdk se puede establecer en los bloques de defaultConfig{}, productFlavors{} y buildTypes{} en el archivo build.gradle al nivel del módulo:

Groovy

android {
  defaultConfig {
    aarMetadata {
      minCompileSdk = 29
    }
  }
  productFlavors {
    foo {
      ...
      aarMetadata {
        minCompileSdk = 30
      }
    }
  }
}

Kotlin

android {
  defaultConfig {
    aarMetadata {
      minCompileSdk = 29
    }
  }
  productFlavors {
    register("foo") {
      ...
      aarMetadata {
        minCompileSdk = 30
      }
    }
  }
}

Si configuras minCompileSdk en varios lugares, Gradle prioriza las ubicaciones de configuración de la siguiente manera durante el proceso de compilación:

  1. buildTypes{}

  2. productFlavors{}

  3. defaultConfig{}

En el ejemplo anterior, en el que minCompileSdk se define en defaultConfig{} y en productFlavors{}, se prioriza productFlavors{}, y minCompileSdk se establece en 30.

Si deseas obtener más información sobre la forma en que Gradle prioriza la configuración cuando se combinan código y recursos, consulta Cómo compilar con conjuntos de orígenes.

Cómo habilitar dispositivos de prueba

El uso general de los dispositivos de prueba está relacionado con configurar el código que se está probando o con facilitar las pruebas de un componente. A partir de la versión 7.1, AGP puede crear dispositivos de prueba para proyectos de biblioteca, además de proyectos de aplicaciones y funciones dinámicas.

Cuando publiques una biblioteca para que otras personas la consuman, considera crear dispositivos de prueba para tu API. Estos dispositivos se pueden activar en el archivo build.gradle al nivel del módulo:

Groovy

android {
  testFixtures {
    enable = true
  }
}

Kotlin

android {
  testFixtures {
    enable = true
  }
}

Cuando activas los dispositivos de prueba, Gradle crea automáticamente un conjunto de orígenes src/testFixtures en el que puedes escribir este tipo de dispositivos.

Si deseas obtener más información, consulta la documentación de Gradle para usar dispositivos de prueba.