¿Cuándo ADT establece BuildConfig.DEBUG en falso?

En la versión más reciente de ADT (r17) se agregó una constante generada BuildConfig.DEBUGque se establece de acuerdo con el tipo de compilación. El problema que tengo es que nunca se establece en falso, esperaba que cambiara al hacer "Herramientas de Android -> Exportar paquete de aplicación firmado", pero no es así para mí.

Entonces, ¿cómo cambio el tipo de construcción?

Se agregó una función que le permite ejecutar código solo en modo de depuración. Las compilaciones ahora generan una clase llamada BuildConfig que contiene una constante DEBUG que se establece automáticamente de acuerdo con su tipo de compilación. Puede verificar la constante (BuildConfig.DEBUG) en su código para ejecutar funciones de solo depuración

Actualmente, puede obtener el comportamiento correcto desactivando "Construir automáticamente", limpiando el proyecto y luego exportando a través de "Herramientas de Android -> Exportar paquete de aplicación firmado". Cuando ejecuta la aplicación BuildConfig.DEBUGdebe ser falsa.

Con Eclipse , siempre desactivo la opción "Construir automáticamente" antes de exportar la aplicación en el lanzamiento. Luego limpio el proyecto y exporto. De lo contrario, comienza a compilar en modo de depuración y, a continuación, el valor de BuildConfig.DEBUG puede ser incorrecto.

Con Android Studio , simplemente agrego mi propia variable personalizada en build.gradle:

buildTypes {
    debug {
        buildConfigField "Boolean", "DEBUG_MODE", "true"
    }
    release {
        buildConfigField "Boolean", "DEBUG_MODE", "false"
    }
}

Cuando construyo el proyecto, BuildConfig.java se genera de la siguiente manera:

public final class BuildConfig {
  // Fields from build type: debug
  public static final Boolean DEBUG_MODE = true;
}

Luego, en mi código puedo usar:

if (BuildConfig.DEBUG_MODE) {
    // do something
}

Recomiendo limpiar después de cambiar la versión de depuración / liberación.

No funciona correctamente:

Problema 27940 : BuildConfig.DEBUG es "true" para el paquete de aplicación exportado

Es decepcionante que a veces publiquen funciones con errores.

Funciona, pero tenga en cuenta que el archivo de código nunca cambia, incluso al exportar el archivo firmado. El proceso de exportación cambia el valor de esta variable a falso, lo que podría darle la falsa impresión de que no está funcionando. Probé esto con declaraciones de registro como

if (com.mypackage.BuildConfig.DEBUG)
            Log.d(TAG, location.getProvider() + " location changed");

Al realizar las pruebas, mis declaraciones de registro ya no producen ningún resultado.

Compruebe si imports, a veces, BuildConfig se importa de cualquier clase de biblioteca sin querer. Por ejemplo:

import io.fabric.sdk.android.BuildConfig;

En este caso, BuildConfig.DEBUG siempre devolverá falso ;

import com.yourpackagename.BuildConfig;

En este caso, BuildConfig.DEBUG devolverá su variante de compilación real .

ps Solo copio este de mi respuesta aquí: BuildConfig.DEBUG siempre es falso al construir proyectos de biblioteca con gradle

De Preparándose para el lanzamiento :

Desactivar el registro y la depuración

Asegúrese de desactivar el registro y deshabilitar la opción de depuración antes de crear su aplicación para su lanzamiento. Puede desactivar el registro eliminando las llamadas a los métodos de registro en sus archivos de origen. Puede deshabilitar la depuración eliminando el atributo android: debuggable de la etiqueta en su archivo de manifiesto, o configurando el atributo android: debuggable como falso en su archivo de manifiesto. Además, elimine los archivos de registro o los archivos de prueba estáticos que se crearon en su proyecto.

Además, debe eliminar todas las llamadas de seguimiento de depuración que agregó a su código, como las llamadas al método startMethodTracing () y stopMethodTracing ().

Más información sigue el enlace.

La solucion para mi:

1. Proyecto -> Construir automáticamente
2. Proyecto -> Limpiar
3. Proyecto -> Construir
4. Aplicación de Android Project Export

Es trabajo en r20

Me gustaría proponer una solución alternativa simple si usa proguard durante la exportación de APK.

Proguard proporciona una forma de eliminar llamadas a funciones específicas en el modo de liberación. Cualquier llamada para depurar registros se puede eliminar con la siguiente configuración en proguard-project.txt.

# Remove debug logs
-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

Y la optimización se instala project.properties.

proguard.config=${sdk.dir}/tools/proguard/proguard-android-optimize.txt:proguard-project.txt

Con esto, no necesita preocuparse por ningún cálculo de cadena innecesario que pase al registro de depuración al que señaló @Jeremyfa. Los cálculos simplemente se eliminan en la versión de versión.

Entonces, la solución para BuildConfig.DEBUG usa la misma característica de proguard como sigue.

public class DebugConfig {

    private static boolean debug = false;

    static {
        setDebug(); // This line will be removed by proguard in release.
    }

    private static void setDebug() {
        debug = true;
    }

    public static boolean isDebug() {
        return debug;
    }
}

Y después de instalarse proguard-project.txt.

-assumenosideeffects class com.neofect.rapael.client.DebugConfig {
    private static *** setDebug();
}

Preferiría usar esto a deshabilitar la Build Automaticallyopción, porque esto no depende de la configuración IDE individual del constructor, sino que se mantiene como un archivo comprometido que se comparte entre los desarrolladores.

No funciona correctamente, según tengo entendido ( problema de Android 22241 )

Tuve algunos problemas en un proyecto (trabajando con Eclipse), esa constante no estaba configurada como verdadera al exportar un APK firmado de mi proyecto :(

Aunque me encantaría escuchar que funciona

una buena forma es crear tu propia clase:

public class Log {

public static void d(String message) {
    if (BuildConfig.DEBUG)
        android.util.Log.d(
            "[" + (new Exception().getStackTrace()[1].getClassName()) + "]",
            "{" + (new Exception().getStackTrace()[1].getMethodName()) + "} "
            + message
        );
}

}

He visto un comportamiento extraño que tiene que ver con cuando los valores en BuildConfig se establecen en sus valores finales. Esto puede tener algo que ver con su problema.

La explicación simple es que los valores predeterminados se establecen inicialmente antes de que se ejecute Proguard, luego, después de que se ejecute Proguard, el archivo BuildConfig se regenera con los valores adecuados. Sin embargo, Proguard ya ha optimizado su código en este punto y tiene problemas.

Aquí hay un error que creé contra Gradle. https://code.google.com/p/android/issues/detail?id=182449