para - eclipse for android developers download

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

Question

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

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

Se agregó una función que le permite ejecutar algunos códigos 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 solo de depuración

Answer 1

Actualmente puede obtener el comportamiento correcto deshabilitando "Crear automáticamente", limpiando el proyecto y exportándolo a través de "Herramientas de Android -> Exportar paquete de aplicación firmado". Cuando ejecuta la aplicación BuildConfig.DEBUG debe ser falso.

Answer 2

Compruebe las imports , a veces BuildConfig se importa de cualquier clase de biblioteca de forma involuntaria. 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 construcción real .

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

Answer 3

Con Eclipse , siempre deshabilito la opción "Crear automáticamente" antes de exportar la aplicación en el lanzamiento. Luego limpio el proyecto y exporto. De lo contrario, comienza la compilación en modo de depuración, y luego 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 / versión.

Answer 4

De la preparación para el lanzamiento :

Desactivar el registro y la depuración

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

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

Más información está siguiendo el enlace.

Answer 5

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 probar, mis declaraciones de Log ya no producen ningún resultado.

Answer 6

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 tu problema.

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

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

Answer 7

La solución para mí:

1. Proyecto -> Construir Automáticamente
2. Proyecto -> Limpio
3. Proyecto -> Construir
4. Proyecto Exportar aplicación de Android

Es trabajo en r20

Answer 8

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 lanzamiento. Cualquier llamada a los registros de depuración 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 configuración de optimización en project.properties .

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

Con esto, no necesita preocuparse de ningún cálculo de Cadena innecesario que pase al registro de depuración al que apuntó @Jeremyfa. Los cálculos se eliminaron en la versión de lanzamiento.

Entonces, la solución para BuildConfig.DEBUG usa la misma función de proguard que 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 configurar en proguard-project.txt .

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

Preferiría usar esto para deshabilitar la opción Build Automatically , 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.

Answer 9

No funciona correctamente por lo que yo entendí ( problema de Android 22241 )

Tuve algunos problemas en un proyecto (trabajando con Eclipse), esa constante no se configuró en verdadero cuando exporté una APK firmada de mi proyecto :(

Me encantaría escuchar que funciona aunque

Answer 10

No funciona correctamente:

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

Es decepcionante que a veces publiquen funciones defectuosas.

Answer 11

una buena manera 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
        );
}

}