studio - Variantes de compilación en Gradle para un proyecto de biblioteca en Android

configure gradle android studio

Question

Estoy tratando de configurar con Gradle un proyecto que contiene algunas bibliotecas externas. Con Gradle puedo configurar diferentes Configuraciones Ambientales (con una clase dentro de un archivo de configuración) para la aplicación principal utilizando las Variantes de compilación para poder ejecutar el código de acuerdo con estas variables.

El problema es que ¿cómo puedo hacer lo mismo para un proyecto de biblioteca? Creé esta biblioteca para este proyecto y me gustaría configurar diferentes variantes de compilación para diferentes escenarios.

Como ejemplo: en la Biblioteca, cuando se ejecuta en modo de depuración, imprima todos los registros para poder verlos mientras desarrollo. En el modo de lanzamiento, no.

Estructura de los archivos:

src ----- > debug -> java -> config -> PlayerEnvConfig
main -> com.mypackagename -> etc...
release -> java -> config -> PlayerEnvConfig

Código en depuración: configuración del paquete;

/**
* Environment configuration for Release
*/
public final class PlayerEnvConfig {
public static final boolean USE_REPORTING = true;
public static final boolean USE_ANALYTICS = true;
public static final boolean USE_LOGGING = false;
public static final boolean USE_DEBUG_LOGGING = false;
public static final boolean USE_DEBUGING = false;
}

Código en la versión:

package config;
/**
* Environment configuration for Release
*/
public final class PlayerEnvConfig {
public static final boolean USE_REPORTING = true;
public static final boolean USE_ANALYTICS = true;
public static final boolean USE_LOGGING = false;
public static final boolean USE_DEBUG_LOGGING = false;
public static final boolean USE_DEBUGING = false;
}

El problema es que para el proyecto principal puedo usar este tipo de compilación para configurar de manera diferente la aplicación para diferentes escenarios, pero ¿cómo puedo hacer lo mismo para el proyecto de biblioteca?

Porque en este momento, por lo que he leído en http://tools.android.com/tech-docs/new-build-system/user-guide la biblioteca solo usará el modo de depuración durante la prueba.

¿Algunas ideas?

¡Gracias!

Answer 1

ACTUALIZACIÓN: desde el momento de esta publicación, se ha avanzado mucho en el proceso de compilación de gradle, por lo tanto, esta respuesta podría no ser la mejor práctica recomendada y los nuevos cambios podrían incluso frenarla. Use su propio criterio

Creo que hay un poco de confusión sobre toda la estructura y configuración del proyecto. Digamos que tiene la siguiente configuración build.gradle

sourceSets {
main {
manifest.srcFile ''src/main/AndroidManifest.xml''
java.srcDirs = [''src/main/java'']
//resources.srcDirs = [''src/main'']
//aidl.srcDirs = [''src/main'']
//renderscript.srcDirs = [''src/main'']
res.srcDirs = [''src/main/res'']
assets.srcDirs = [''src/main/assets'']
}
debug.setRoot(''build-types/debug'')
release.setRoot(''build-types/release'')
}

La estructura de su carpeta de proyecto debe ser la siguiente

project_root
-src
-main
-java
-com
-example
-build-types
-debug
-java
-com
-example
-FooBar.java
-release
-java
-com
-example
-FooBar.java

FooBar.java no debe estar en el prooject_root/src/main/java/com/example . Debe estar en la carpeta de debug y release que debe residir fuera de la carpeta src pero dentro build-types carpeta de build-types . Eso se configura mediante el setRoot(''build-types/*****'') . Mucha gente se confunde al ver ''debug / java'' y ''main / java'', donde el último se hace referencia de una manera ''src / main / java'' desde la presentación y termina poniendo ''debug / java'' en src, el carpeta equivocada. Espero esta ayuda.

Para un entorno más complejo que involucre otras bibliotecas, puede ver mi respuesta aquí https://.com/a/19918834/319058

Answer 2

Como señala Scott , esta es una falla conocida de Gradle . Como solución alternativa, puede usar este método, que usa la reflexión para obtener el valor de campo de la aplicación (no de la biblioteca):

/**
* Gets a field from the project''s BuildConfig. This is useful when, for example, flavors
* are used at the project level to set custom fields.
* @param context Used to find the correct file
* @param fieldName The name of the field-to-access
* @return The value of the field, or {@code null} if the field is not found.
*/
public static Object getBuildConfigValue(Context context, String fieldName) {
try {
Class<?> clazz = Class.forName(context.getPackageName() + ".BuildConfig");
Field field = clazz.getField(fieldName);
return field.get(null);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return null;
}

Para obtener el campo DEBUG , por ejemplo, solo llame a esto desde su Activity :

boolean debug = (Boolean) getBuildConfigValue(this, "DEBUG");

También he compartido esta solución en AOSP Issue Tracker .

Answer 3

Es una respuesta de @bifmadei del problema del código de Google y me ayuda:

Intenta configurar esto en el proyecto de dependencia

android {
publishNonDefault true
...
}

y esto en el proyecto que lo usa

dependencies {
releaseCompile project(path: '':theotherproject'', configuration: ''release'')
debugCompile project(path: '':theotherproject'', configuration: ''debug'')
}

Tomado desde aquí: https://code.google.com/p/android/issues/detail?id=66805

Answer 4

Esto está documentado en https://code.google.com/p/android/issues/detail?id=52962 . Como ha descubierto, el tipo de compilación no se propaga a los proyectos de la biblioteca, y no hay una buena solución. Si tiene control sobre el código del proyecto de la biblioteca, puede hacer que el estado de depuración sea una variable global mutable, y configurarlo desde su aplicación principal al inicio. Es algo así como un truco, y tiene la desventaja de que el compilador no puede optimizar las rutas de código no utilizadas lejos de las versiones de lanzamiento, pero a menos que algo inusual esté sucediendo debería funcionar.

Answer 5

Esto no es posible con proyectos de biblioteca como usted mismo mencionó.

Podrías simplemente cambiar el proyecto de la biblioteca a un proyecto de aplicación. Eso parece funcionar bien (al menos en teoría, no lo he probado yo mismo).

La otra forma sería anular esa clase en su proyecto de aplicación. La clase de proyecto de su aplicación se elegirá cuando se lleve a cabo la fusión y tendrá esos valores disponibles.

Answer 6

No estoy seguro de lo que está mal con su configuración, pero sobre su necesidad, lo haría de manera diferente.

En el archivo de compilación gradle puede usar la palabra clave buildConfig para agregar una línea específica a la clase generada BuildConfig.java .

Así que podrías agregar hacer algo así en tu build.gradle :

 release {
buildConfig "public static final String USE_REPORTING = true;"
}
debug {
buildConfig "public static final String USE_REPORTING = false;"
}

Y solo tienen un PlayerEnvConfig con

public static final boolean USE_REPORTING = BuildConfig.USE_REPORTING;

O incluso no más PlayerEnvConfig y usa directamente la clase BuildConfig .

EDITAR Desde una actualización, la sintaxis ha cambiado:

buildConfigField "<type>", "<name>", "<value>"