Skip to content

Most visited

Recently visited

navigation

Configurar variantes de compilación

Esta página se basa en las especificaciones de Información general sobre la configuración de tu compilación con el propósito de mostrarte la manera de configurar variantes de compilación para crear diferentes versiones de tu app desde un mismo proyecto, y de administrar correctamente tus dependencias y configuraciones de firma.

Cada variante de compilación representa una versión diferente de tu app que puedes compilar. Por ejemplo, es posible que desees compilar una versión de tu app que sea gratuita, con contenido limitado, y una versión paga que incluya más contenido. También puedes compilar diferentes versiones de tu app para diferentes dispositivos, según el nivel de API u otras variantes de dispositivos. No obstante, si deseas compilar diferentes versiones según la ABI del dispositivo o la densidad de pantalla, usa divisiones de APK.

Las variantes de compilación surgen del uso de un conjunto específico de reglas a través de Gradle para combinar configuraciones, código y recursos configurados en tus tipos de compilación y tipos de productos. Aunque no configuras variantes de compilación directamente, sí configuras los tipos de compilación y los tipos de productos que las forman.

Por ejemplo, en un tipo de producto de “demostración” pueden especificarse diferentes funciones y requisitos de dispositivo, como código fuente personalizado, y recursos y niveles de API mínimos, mientras que en el tipo de compilación de “depuración” se aplican diferentes configuraciones de compilación y empaquetado, como opciones de depuración y claves de firma. La variante de compilación resultante es la versión “demoDebug” de tu app e incluye una combinación de las configuraciones y los recursos incluidos en el tipo de producto “demo”, el tipo de compilación “depuración” y el conjunto de orígenes main/.

Configurar tipos de compilaciones

Puedes crear y configurar tipos de compilación en el archivo build.gradle de nivel de módulo dentro del bloque android {}. Cuando creas un módulo nuevo, Android Studio crea automáticamente los tipos de compilación de depuración y lanzamiento. Si bien el tipo de compilación de depuración no aparece en el archivo de configuración de la compilación, Android Studio lo configura con debuggable true. Esto te permite depurar la app en dispositivos Android seguros y configura la firma del APK con un keystore de depuración genérico.

Puedes agregar el tipo de compilación de depuración a tu configuración si deseas agregar o cambiar determinados ajustes. En el siguiente ejemplo, se especifica un applicationIdSuffix para el tipo de compilación de depuración y se configura un tipo de compilación “jnidebug” que se inicializa usando configuraciones del tipo de compilación de depuración.

android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

Nota: Cuando realizas cambios en un archivo de configuración de la compilación, Android Studio exige que sincronices tu proyecto con la nueva configuración. Para sincronizar tu proyecto, puedes hacer clic en Sync Now en la barra de notificaciones que aparece no bien realizas un cambio, o en Sync Project en la barra de herramientas. Si Android Studio detecta un error en la configuración, aparecerá la ventana Messages y se describirá el problema.

Para obtener más información sobre todas las propiedades que puedes configurar con tipos de compilación, lee la referencia DSL del tipo de compilación.

Configurar tipos de productos

Crear tipos de productos es similar a crear tipos de compilación: agrégalos al bloque productFlavors {} y configura los ajustes que desees. Los tipos de productos admiten las mismas propiedades que defaultConfig; esto se debe a que defaultConfig en realidad pertenece a la clase ProductFlavor. Esto significa que puedes proporcionar la configuración básica para todos los tipos en el bloque defaultConfig {}, y cada tipo puede cambiar cualquiera de estos valores predeterminados; por ejemplo, applicationId. Para obtener más información sobre el ID de aplicación, consulta Configurar el ID de aplicación.

Nota: No obstante, debes especificar un nombre de paquete usando el atributo package en el archivo de manifiesto main/. También debes usar ese nombre de paquete en tu código fuente para hacer referencia a la clase R, o bien resolver cualquier actividad o registro de servicio relacionados. Esto te permite usar applicationId a fin de asignar a cada tipo de producto un ID exclusivo para el empaquetado y la distribución, sin necesidad de cambiar el código fuente.

En el siguiente código de ejemplo, se crean los tipos de productos “demo” y “completo” con sus propios applicationIdSuffix y versionNameSuffix:

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

Nota: para distribuir tu app mediante la compatibilidad con varios APK en Google Play, asigna el mismo valor applicationId a todas las variantes y, a cada variante, un versionCode diferente. Para distribuir diferentes variantes de tu app como apps independientes en Google Play, debes asignar un applicationId diferente a cada variante.

Después de crear y configurar tus tipos de productos, haz clic en Sync Now en la barra de notificaciones. Una vez que se completa la sincronización, Gradle crea automáticamente variantes de compilación según tus tipos de compilación y de productos, y les asigna nombres según <product-flavor><Build-Type>. Por ejemplo, si creaste tipos de producto de “demostración” y “completo”, y conservaste los tipos de compilación predeterminados de “depuración” y “lanzamiento”, Gradle crea las siguientes variantes de compilación:

Puedes cambiar la variante de compilación por la que desees para la compilación y la ejecución. Simplemente, dirígete a Build > Select Build Variant y selecciona una del menú desplegable. No obstante, para comenzar a personalizar cada variante de compilación con sus funciones y recursos propios, debes saber crear y administrar conjuntos de orígenes.

Combinar varios tipos de productos

En algunos casos, es posible que desees combinar configuraciones de varios tipos de productos. Por ejemplo, puedes crear diferentes configuraciones para los tipos de productos “completo” y “demo” que se basen en el nivel de API. Para hacerlo, el complemento de Android para Gradle te permite crear grupos de tipos de productos, denominados “dimensiones de tipos”. Cuando compilas tu app, Gradle combina una configuración de tipo de producto de cada dimensión de tipo que defines, junto con una configuración de tipo de compilación, para crear la variante de compilación final. Gradle no combina tipos de productos que pertenecen a la misma dimensión de tipo.

Sugerencia: Para crear versiones diferentes de tu app según la densidad de pantalla y la ABI, debes configurar divisiones de APK en lugar de usar tipos de productos.

En el siguiente código de ejemplo, se usa la propiedad flavorDimensions para crear una dimensión de tipo “modo”, a fin de agrupar los tipos de productos “completo” y “demo”, y una dimensión de tipo “api” a fin de agrupar las configuraciones de tipos de productos basadas en el nivel de API:

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig {} block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

La cantidad de variantes de compilación que crea Gradle es igual al producto de la cantidad de tipos de cada dimensión de tipo y la cantidad de tipos de compilación que configuras. Cuando Gradle asigna un nombre a cada variante de compilación o APK correspondiente, los tipos de productos pertenecientes a la dimensión de tipo de mayor prioridad aparecen primero; luego, aparecen aquellos de dimensiones de menor prioridad y, por último, el tipo de compilación. Usando la configuración de compilación anterior como ejemplo, Gradle crea un total de 12 variantes de compilación con el siguiente esquema de nomenclatura:

Variante de compilación: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
APK correspondiente: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
El siguiente
Variante de compilación: minApi24DemoDebug
APK correspondiente: app-minApi24-demo-debug.apk

Además de los directorios de conjuntos de orígenes que puedes crear para cada tipo de producto y variante de compilación en particular, también puedes crear directorios de conjuntos de orígenes para cada combinación de tipos de productos. Por ejemplo, puedes crear y agregar orígenes Java al directorio src/demoMinApi24/java/, y Gradle usa esos orígenes únicamente cuando compila una variante que combina esos dos tipos de productos. Los conjuntos de orígenes que creas para las combinaciones de tipos de productos tienen una prioridad superior con respecto a los conjuntos de orígenes que pertenecen a cada tipo de producto en particular. Para obtener más información sobre los conjuntos de orígenes y la manera en que Gradle fusiona recursos, consulta la sección Crear conjuntos de orígenes.

Filtrar variantes

Gradle crea una variante de compilación para cada combinación posible de los tipos de productos y de compilación que configuras. Sin embargo, es posible que determinadas variantes de compilación no sean necesarias o no tengan sentido en el contexto de tu proyecto. Puedes quitar determinadas configuraciones de variantes de compilación creando un filtro de variantes en tu archivo build.gradle de nivel de módulo.

Usando la configuración de compilación de la sección anterior como ejemplo, supongamos que planeas admitir solo los niveles de API 23 y versiones posteriores para la versión demo de la app. Puedes usar el bloque variantFilter {} para filtrar todas las configuraciones de variantes de compilación en las que se combinen los tipos de productos “minApi21” y “demo”:

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

Una vez que agregas un filtro de variantes a tu configuración de compilación y haces clic en Sync Now en la barra de notificaciones, Gradle ignora cualquier variante de compilación que cumpla con las condiciones que especificas, y estas dejan de aparecer en el menú desplegable cuando haces clic en Build > Select Build Variant en la barra de menú (o Build Variants en la barra de la ventana de herramientas).

Crear conjuntos de orígenes

De manera predeterminada, Android Studio crea el conjunto de orígenes main/ y directorios para todo lo que desees compartir entre todas tus variantes de compilación. Sin embargo, puedes crear nuevos conjuntos de orígenes para controlar exactamente los archivos que compila y empaqueta Gradle para tipos de compilación, tipos de productos (y combinaciones de tipos de productos cuando se usan dimensiones de tipos) y variantes de compilación específicos. Por ejemplo, puedes definir una funcionalidad básica en el conjunto de orígenes main/ y usar conjuntos de orígenes de tipo de producto a fin de cambiar la marca de tu app para diferentes clientes, o incluir permisos especiales y funcionalidad de registro solo para variantes de compilación que usan el tipo de compilación de depuración.

Gradle prevé que organices los directorios y archivos de conjuntos de orígenes de una forma determinada, caso similar al del conjunto de orígenes main/. Por ejemplo, Gradle prevé que los archivos de clase Java específicos del tipo de compilación de “depuración” se ubiquen en el directorio src/debug/java/.

El complemento de Android para Gradle proporciona una tarea de Gradle útil que te muestra la manera organizar tus archivos para cada tipo de compilación, tipo de producto y variante de compilación. Por ejemplo, en la siguiente sección del informe se describe el punto en el cual Gradle prevé que encontrará ciertos archivos para el tipo de compilación de “depuración”:

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: compile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

Si deseas generar y ver ese informe para la configuración de tu compilación, procede de la siguiente manera:

  1. Haz clic en Gradle en el costado derecho de la ventana de IDE.
  2. Dirígete a MyApplication > Tasks > android y haz doble clic en sourceSets.
  3. Para ver el informe, haz clic en Gradle Console en la parte inferior de la ventana de IDE.

Nota: En el informe también se muestra la manera de organizar los conjuntos de orígenes para archivos que desees usar en la ejecución de pruebas para tu app, como los conjuntos de orígenes de prueba test/ y androidTest/ .

Cuando creas una nueva variante de compilación, Android Studio no crea los directorios del conjunto de orígenes, pero te ofrece algunas opciones que te ayudarán. Por ejemplo, para crear solo el directorio java/ para el tipo de compilación “depuración”, sigue estos pasos:

  1. Abre el subpanel Project y selecciona la vista Project en el menú desplegable de la parte superior del subpanel.
  2. Dirígete a MyProject/app/src/.
  3. Haz clic con el botón secundario en el directorio src y selecciona New > Folder > Java Folder.
  4. En el menú desplegable junto a Target Source Set, selecciona debug.
  5. Haz clic en Finish.

Android Studio crea un directorio de conjunto de orígenes para tu tipo de compilación de depuración y luego crea el directorio java/ dentro de este. De manera alternativa, puedes hacer que Android Studio cree los directorios cuando agregues un nuevo archivo a tu proyecto para una variante de compilación específica. Por ejemplo, si deseas crear un archivo XML de valores para el tipo de compilación de “depuración”:

  1. En el mismo subpanel Project, haz clic con el botón secundario en el directorio src y selecciona New > XML > Values XML File.
  2. Ingresa el nombre del archivo XML o mantén el nombre predeterminado.
  3. En el menú desplegable junto a Target Source Set, selecciona debug.
  4. Haz clic en Finish.

Dado que el tipo de compilación de “depuración” se especificó como conjunto de orígenes de destino, Android Studio crea automáticamente los directorios necesarios cuando se crea el archivo XML. La estructura del directorio resultante se debe ser como la que se muestra en la figura 2.

Figura 2: Nuevos directorios del conjunto de orígenes para el tipo de compilación de depuración.

Usando el mismo procedimiento, también puedes crear directorios de conjunto de orígenes para tipos de productos (por ejemplo, src/demo/) y variantes de compilación (por ejemplo, src/demoDebug/). Además, puedes crear conjuntos de orígenes de prueba para variantes de compilación específicas; por ejemplo, src/androidTestDemoDebug/. Para obtener más información, consulta Cómo probar conjuntos de orígenes.

Cambiar configuraciones predeterminadas de conjuntos de orígenes

Si tienes orígenes que no están organizados en la estructura de archivo de conjunto de orígenes predeterminada que prevé Gradle, como se describe antes en la sección Crear conjuntos de orígenes, puedes usar el bloque sourceSets {} para cambiar la ubicación en la que Gradle espera reunir los archivos para cada componente de un conjunto de orígenes. No es necesario que reubiques los archivos; solo debes proporcionar a Gradle las rutas de acceso, en relación con el archivo build.gradle de nivel de módulo, donde Gradle debe encontrar los archivos para cada componente del conjunto de orígenes. Para determinar los componentes que puedes configurar y si puedes asignarlos a varios archivos o directorios, consulta la referencia sobre el complemento de Android para Gradle DSL.

En el siguiente código de ejemplo, se asignan orígenes del directorio app/other/ a determinados componentes del conjunto de orígenes main y se cambia el directorio raíz del conjunto de orígenes androidTest.

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you get an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: You should avoid specifying a directory which is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // You should specify either only the root 'other/res1' directory, or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

Realizar compilaciones con conjuntos de orígenes

Puedes usar los directorios de conjuntos de orígenes para contener el código y los recursos que deseas empaquetar solo con determinadas configuraciones. Por ejemplo, si compilas la variante de compilación “demoDebug”, que es el producto vectorial de un tipo de producto de “demostración” y el tipo de compilación de “depuración”, Gradle busca en esos directorios y les da la siguiente prioridad:

  1. src/demoDebug/ (conjunto de orígenes de variante de compilación)
  2. src/debug/ (conjunto de orígenes de tipo de compilación)
  3. src/demo/ (conjunto de orígenes de tipo de producto)
  4. src/main/ (conjunto de orígenes principal)

Nota: Si combinas varios tipos de productos, la prioridad entre los tipos de productos se determina por la dimensión de tipo a la que pertenecen. Cuando se listan las dimensiones de tipos con la propiedad android.flavorDimensions, los tipos de productos que pertenecen a la primera dimensión de tipo que incluyes en la lista tienen mayor prioridad que aquellos que pertenecen a la segunda dimensión de tipo, y así sucesivamente. Además, los conjuntos de orígenes que creas para las combinaciones de tipos de productos tienen una prioridad superior con respecto a los conjuntos de orígenes que pertenecen a cada tipo de producto en particular.

El orden indicado determina el conjunto de orígenes que tiene prioridad más alta cuando Gradle combina código y recursos. Debido a que es posible que el directorio de conjunto de orígenes demoDebug/ contenga archivos específicos de esa variante de compilación, si demoDebug/ incluye un archivo que también se define en debug/, Gradle usa el archivo en el conjunto de orígenes demoDebug/. De manera similar, Gradle otorga a los archivos de los conjuntos de orígenes de tipo de compilación y tipo de producto una prioridad más alta con respecto a los mismos archivos en main/. Gradle tiene en cuenta este orden de prioridad al aplicar las siguientes reglas de compilación:

Declarar dependencias

En el siguiente ejemplo, se declaran tres tipos de dependencias directas diferentes en el archivo build.gradle del módulo app/:

android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:27.0.0'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

A continuación, se describe cada una de estas dependencias directas.

Dependencias del módulo
En la línea compile project(':mylibrary') se declara un módulo de biblioteca de Android local llamado “mylibrary” como dependencia, y se requiere que el sistema de compilación compile e incluya el módulo local al compilar la app.
Dependencias binarias remotas
En la línea compile 'com.android.support:appcompat-v7:27.0.0' se declara una dependencia con respecto a la versión 27.0.0 de la biblioteca de compatibilidad de Android especificando sus coordenadas de JCenter. De forma predeterminada, Android Studio configura proyectos para usar el repositorio de JCenter en el archivo de compilación de nivel superior. Gradle toma automáticamente la dependencia de JCenter cuando sincronizas tu proyecto con los archivos de configuración de la compilación. Como alternativa, puedes descargar e instalar determinadas dependencias usando SDK Manager.
Dependencias binarias locales
La línea compile fileTree(dir: 'libs', include: ['*.jar']) solicita al sistema de compilación que incluya cualquier archivo JAR dentro del directorio app/libs/ en la classpath de compilación y en el paquete final de tu app. Si tienes módulos que requieren dependencias binarias locales, copia los archivos JAR para estas dependencias en <moduleName>/libs dentro de tu proyecto.

Algunas dependencias directas del módulo pueden tener dependencias propias, llamadas dependencias transitivas del módulo. Gradle reúne automáticamente cada dependencia transitiva y la agrega, evitando así que las declares manualmente. El complemento de Android para Gradle proporciona una tarea de Gradle útil que puede generar un árbol de dependencias para cada variante de compilación y conjunto de orígenes de prueba, de modo que puedas visualizar fácilmente las dependencias directas y transitivas de tu módulo. Para generar este informe, continúa de la siguiente manera:

  1. Haz clic en Gradle en el costado derecho de la ventana de IDE.
  2. Dirígete a MyApplication > Tasks > android y haz doble clic en androidDependencies.
  3. Para ver el informe, haz clic en Gradle Console en la parte inferior de la ventana de IDE.

En el siguiente informe de ejemplo se muestra el árbol de dependencias para la variante de compilación de depuración y se incluye la dependencia del módulo local y la dependencia remota del ejemplo anterior.

Executing tasks: [androidDependencies]
:app:androidDependencies
debug
/**
 * Both the library module dependency and remote binary dependency are listed
 * with their transitive dependencies.
 */
+--- MyApp:mylibrary:unspecified
|    \--- com.android.support:appcompat-v7:27.0.0
|         +--- com.android.support:animated-vector-drawable:27.0.0
|         |    \--- com.android.support:support-vector-drawable:27.0.0
|         |         \--- com.android.support:support-v4:27.0.0
|         |              \--- LOCAL: internal_impl-27.0.0.jar
|         +--- com.android.support:support-v4:27.0.0
|         |    \--- LOCAL: internal_impl-27.0.0.jar
|         \--- com.android.support:support-vector-drawable:27.0.0
|              \--- com.android.support:support-v4:27.0.0
|                   \--- LOCAL: internal_impl-27.0.0.jar
\--- com.android.support:appcompat-v7:27.0.0
     +--- com.android.support:animated-vector-drawable:27.0.0
     |    \--- com.android.support:support-vector-drawable:27.0.0
     |         \--- com.android.support:support-v4:27.0.0
     |              \--- LOCAL: internal_impl-27.0.0.jar
     +--- com.android.support:support-v4:27.0.0
     |    \--- LOCAL: internal_impl-27.0.0.jar
     \--- com.android.support:support-vector-drawable:27.0.0
          \--- com.android.support:support-v4:27.0.0
               \--- LOCAL: internal_impl-27.0.0.jar
...

Para obtener más información sobre cómo administrar dependencias en Gradle, consulta Aspectos básicos de la administración de dependencias en la Guía del usuario de Gradle.

Configurar dependencias

Puedes usar determinadas palabras claves de configuración para indicar a Gradle la manera y el momento de usar una dependencia; por ejemplo, la palabra clave compile de los ejemplos anteriores. A continuación, se describen algunas palabras clave que puedes usar para configurar tus dependencias:

compile
Especifica una dependencia de tiempo de compilación. Gradle agrega dependencias con esta configuración a la variable classpath y al APK de tu app. Esta es la configuración predeterminada.
apk
Especifica una dependencia exclusiva de tiempo de ejecución que Gradle debe empaquetar con el APK de tu app. Puedes usar esta configuración con dependencias binarias JAR, pero no con otras dependencias del módulo de biblioteca ni con dependencias binarias AAR.
provided
Especifica una dependencia de tiempo de compilación que Gradle no empaquete con el APK de tu app. Esto ayuda a reducir el tamaño de tu APK si no se requiere la dependencia durante el tiempo de ejecución. Puedes usar esta configuración con dependencias binarias JAR, pero no con otras dependencias del módulo de biblioteca ni con dependencias binarias AAR.

Además, puedes configurar una dependencia para una variante de compilación o conjunto de orígenes de prueba específicos aplicando el nombre de la variante de compilación o del conjunto de orígenes de prueba a la palabra clave de configuración, como se muestra en el siguiente ejemplo.

dependencies {
    ...
    // Adds specific library module dependencies as compile time dependencies
    // to the fullRelease and fullDebug build variants.
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')

    // Adds a compile time dependency for local tests.
    testCompile 'junit:junit:4.12'

    // Adds a compile time dependency for the test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
}

Configurar ajustes de firma

Gradle no firma el APK de tu compilación de lanzamiento a menos que definas explícitamente una configuración de firma para esa compilación. Puedes crear fácilmente una clave de lanzamiento y firmar tu tipo de compilación de lanzamiento usando Android Studio.

Para configurar manualmente los ajustes de firma para tu tipo de compilación de lanzamiento usando configuraciones de compilación de Gradle:

  1. Crea un keystore. Un keystore es un archivo ejecutable que contiene un conjunto de claves privadas. Debes conservar tu keystore en un lugar seguro y protegido.
  2. Crea una clave privada. Una clave privada representa la entidad que se identificará con la app, como una persona o una empresa.
  3. Agrega la configuración de firma al archivo build.gradle de nivel de módulo:

    ...
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            release {
                storeFile file("myreleasekey.keystore")
                storePassword "password"
                keyAlias "MyReleaseKey"
                keyPassword "password"
            }
        }
        buildTypes {
            release {
                ...
                signingConfig signingConfigs.release
            }
        }
    }
    

Para generar un APK firmado, selecciona Build > Generate Signed APK en la barra de menú. El paquete en app/build/apk/app-release.apk ahora está firmado con tu clave de lanzamiento.

Nota: No es una buena práctica de seguridad incluir las contraseñas para tu clave de lanzamiento y keystore dentro del archivo de compilación. Como alternativa, puedes configurar el archivo de compilación para que obtenga estas contraseñas de variables de entorno o que el proceso de compilación te solicite estas contraseñas.

Para obtener estas contraseñas desde variables de entorno:

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

Para que el proceso de compilación te solicite estas contraseñas si invocas la compilación desde la línea de comandos:

storePassword System.console().readLine("\nKeystore password: ")
keyPassword System.console().readLine("\nKey password: ")

Luego de completar este proceso, puedes distribuir tu app y publicarla en Google Play.

Advertencia: Conserva tu keystore y tu clave privada en un lugar seguro y protegido, y asegúrate de contar con copias de seguridad protegidas de ellas. Si publicas una app en Google Play y luego pierdes la clave con la cual la firmaste, no podrás publicar actualizaciones para ella, ya que siempre deberás firmar todas las versiones con la misma clave.

Firmar apps de Android Wear

Cuando publicas apps de Android Wear, debes incluir en un paquete la app para wearables dentro de una app para dispositivos portátiles, ya que los usuarios no pueden buscar e instalar apps directamente en el wearable. Ambas apps deben estar firmadas. Para obtener más información sobre cómo empaquetar y firmar apps para Android Wear, consulta Empaquetado de apps para wearables.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)