En la versión más reciente de ADT (r17) generar un constante fue añadido BuildConfig.DEBUG que se establece según el tipo de generación. El problema que tengo es que no se establece en false, yo esperaba que el cambio al hacer «Android Herramientas -> Exportar Firmado Paquete de Aplicación», pero no para mí.

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

Añadido una característica que permite ejecutar código en modo de depuración.
Construye ahora generar una clase llamada BuildConfig que contiene una DEPURACIÓN de
constante que se establece automáticamente de acuerdo a su tipo de construcción. Usted
puede comprobar el (BuildConfig.DEBUG) constante en el código a ejecutar
depuración de las funciones

  • BuildConfig.java es generado automáticamente por el Android herramientas de construcción, y se coloca en el gen de la carpeta. Al firmar la APK debe tener BuildConfig.DEBUG = false. No debería ser un problema para usted. Usted no debería tener que manualmente tocar ese archivo…
  • Si utiliza gradle para la liberación de este indicador es 100% fiable. Así que cuando usted haga una ./gradlew assembleDebug su verdadera y, al hacer assembleRelease su falsa.
InformationsquelleAutor smith324 | 2012-03-24

11 Comentarios

  1. 56

    Actualmente se puede obtener el comportamiento correcto mediante la desactivación de «Construir de forma Automática», de limpieza en el proyecto y, a continuación, exportar a través de «Android Herramientas -> Exportar Firmado Paquete de Aplicación». Cuando se ejecuta la aplicación BuildConfig.DEBUG debe ser false.

    • No funciona para mí (r21p2, junio, Win7)
    • Estoy de acuerdo con Tom. Característica roto de nuevo en r21…
    • roto también. Que tiene como consecuencia el hecho de mostrar todos los registros.d mensajes que deben ser omitidas por este indicador. ps. dónde archivo de informe de errores?
    • A mi me funciona en el R22.
    • la mía es siempre falso, incluso cuando la depuración de
    • No trabajo en mi proyecto android (escribir en Eclipse)

  2. 36

    Con Eclipse, siempre me deshabilitar «Construir Automáticamente la» opción antes de Exportar la aplicación en la liberación. Luego me limpio el proyecto y de exportación. De lo contrario, se inicia la compilación en modo de depuración y, a continuación, el valor de BuildConfig.DEPURACIÓN puede estar equivocado.

    Con Android Studio, yo simplemente agregar mi propia variable personalizada en la construcción.gradle:

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

    Cuando voy a construir el proyecto, la BuildConfig.java se genera de la siguiente manera:

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

    A continuación, en mi código que puede utilizar:

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

    Yo recomiendo a limpiar después de la conmutación de la depuración y compilación de la versión.

  3. 33

    No funciona correctamente:

    Problema Veintisiete mil novecientos cuarenta: BuildConfig.DEBUG es «true» para exportar el paquete de solicitud de

    Es decepcionante que a veces la liberación de buggy características.

    • Por favor siga el enlace para el tema de los mencionados anteriormente y ‘estrellas’ que si queremos que esto sea corregido.
  4. 10

    No funciona, pero tenga en cuenta que el archivo de código que nunca cambia, incluso cuando se exporta el archivo firmado. La exportación proceso cambia el valor de esta variable a false, lo que puede dar la falsa impresión de que no está funcionando.
    He probado con el registro de declaraciones como

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

    Cuando se prueba, a mi las declaraciones de Registro no produce ningún resultado.

    • Este no me funciona (R22).
    • ¿Qué fue exactamente lo que u hacer?
    • He cambiado las instancias de BuildConfig.De DEPURACIÓN para com.mypackage.BuildConfig.DEBUG, a continuación, reran la aplicación… y todavía devuelve true todo el tiempo. Tal vez no he entendido tu sugerencia.
    • Lo que yo estoy diciendo es que el código NO va a cambiar. Sin embargo, com.mypackage.BuildConfig.DEPURACIÓN se establece en False post de compilación. Intente una prueba de registro de la declaración anterior (elegir una cadena arbitraria registro), hacer la exportación y, a continuación, ejecútelo. A ver si adb muestra el registro de instrucción. Voy a tomar una apuesta que adb no se informe de que el registro de la declaración, lo que significa que DEUBUG se ha establecido en false.
    • No estoy seguro de que sé lo que quieres decir acerca de «el código»… sin embargo, he de decir que de hacer una limpia antes de exportar el APK (como se sugiere en la aceptó respuesta) tanto BuildConfig.DEPURACIÓN y com.mypackage.BuildConfig.DEPURACIÓN informe falso, como se esperaba.
    • Usted lo consiguió. Ese es el comportamiento esperado.
    • si usted, literalmente, se utiliza «com.mypackage.BuildConfig.DEPURAR» el que no iba a funcionar. El paquete es relativo a su aplicación.
    • esto es que la captura… echa un vistazo a la importación de la cláusula porque parecen muy fácilmente mal paquete de datos se importan de depuración no se propaga a las bibliotecas …

  5. 8

    De verificación para imports, a veces BuildConfig es importado de cualquier clase de biblioteca involuntariamente. Por ejemplo:

    import io.fabric.sdk.android.BuildConfig;

    En este caso BuildConfig.DEPURACIÓN siempre devolverá falso;

    import com.yourpackagename.BuildConfig;

    En este caso BuildConfig.DEPURACIÓN devolverá su real de construir la variante de.

    p.s yo solo copie esta de mi respuesta aquí:BuildConfig.DEPURACIÓN siempre falso cuando la construcción de la biblioteca de proyectos con gradle

    • Sí, para mí fue accidentalmente importados de android.support.compat. Supongo que es otra razón para definir su propio campo con un nombre diferente.
  6. 5

    De La preparación para el Lanzamiento:

    Desactivar el registro y depuración de

    Asegúrese de desactivar el registro y deshabilitar la opción de depuración
    antes de crear su aplicación para la liberación. Usted puede desactivar
    el registro mediante la eliminación de las llamadas a los métodos de Registro en los archivos de origen. Usted puede
    deshabilitar la depuración mediante la eliminación de android:depurables atributo de
    la etiqueta en el archivo de manifiesto, o mediante el establecimiento de la
    android:depurables atributo a false en el archivo de manifiesto. También,
    quitar los archivos de registro o prueba estática de los archivos que se crearon en su
    proyecto.

    También, se debe eliminar toda traza de Depuración de las llamadas que haya agregado a su
    código, tales como startMethodTracing() y stopMethodTracing() método
    las llamadas.

    Más información siguiendo el enlace.

    • Pensé que este proceso ocurre de forma automática en tiempo de compilación: developer.android.com/tools/sdk/tools-notes.html
    • Causas de error en tiempo de compilación: «Evitar codificar el modo de depuración, lo que permite depurar y las versiones de lanzamiento para asignar automáticamente una»
  7. 5

    La solución para mí:

    1. Proyecto -> Crear Automáticamente
    2. Proyecto -> Limpia
    3. Proyecto -> Construir
    4. Proyecto de Exportación de la aplicación de Android

    Es un trabajo en r20

    • Parece que está roto de nuevo en r21. Maldita sea, Google…
    • Esto funcionó para mí ahora mismo (usando la última ADT supongo). Tal vez la limpieza se fija, no estoy seguro.
  8. 3

    Me gustaría proponer una solución simple si el uso de proguard durante APK de exportación.

    Proguard proporciona una manera de eliminar las llamadas a funciones específicas en modo de lanzamiento. Llamadas para la depuración de los registros puede ser eliminado con la siguiente configuración en proguard-project.txt.

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

    Y configuración de optimización en project.properties.

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

    Con esto, usted no necesita preocuparse de cualquier innecesarios computación en Cadena, pasando de depurar el registro a que @Jeremyfa señaló. Los cálculos se acaba de quitar en la versión de lanzamiento.

    Así que la solución para BuildConfig.DEBUG utiliza la misma función de proguard como la siguiente.

    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 la siguiente configuración en proguard-project.txt.

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

    Yo preferiría el uso de este para la desactivación de la Build Automatically opción, porque esto no depende de que el generador individual de configuración IDE pero se mantiene como compromiso de archivos que se comparten entre los desarrolladores.

  9. 1

    No funciona correctamente por lo que entendía (Android cuestión 22241)

    Tuve algunos problemas en un proyecto (trabajo con Eclipse), que la constante no se había establecido a true cuando la exportación de una firma de APK de mi proyecto 🙁

    Encantaría escuchar funciona aunque

    • Debe de haber sido fijado en r17, sus marcados como tal en el bug tracker.
    • Yo sólo lo he probado y funciona para mí.
    • En realidad libs no se compila en modo de lanzamiento en ADT cuando la exportación (funciona en Ant). He actualizado code.google.com/p/android/issues/detail?id=27940
    • gracias por fijarse en él, voy a dejar de spam promesa ahora. De hecho fue el principal proyecto en el que estaba teniendo problemas con (no se ven en la biblioteca dependiente). Si puedo crear una prueba concreta caso voy a publicar en el rastreador de errores bajo el mismo tema.
  10. 1

    una buena manera es la creación de su 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
            );
    }
    
    }
    • El problema con este método es que, evento cuando DEPURACIÓN es falso, java se calcula cada una de las cuerdas para pasar a la clase personalizada. If (DEPURACIÓN) de Registro.d(…) es menos elegante pero más eficiente.
  11. 0

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

    La explicación simple es que los valores por defecto son inicialmente antes de Proguard es ejecutar, a continuación, después de Proguard se ejecuta, el BuildConfig archivo se regenera con los valores adecuados. Sin embargo, Proguard ya ha optimizado el código por este punto y tiene problemas.

    Aquí es un error que he creado en contra de Gradle. https://code.google.com/p/android/issues/detail?id=182449

Dejar respuesta

Please enter your comment!
Please enter your name here