Wann setzt ADT BuildConfig.DEBUG auf false?

In der neuesten Version von ADT (r17) wurde eine generierte Konstante hinzugefügt BuildConfig.DEBUG, die entsprechend dem Build-Typ festgelegt wird. Das Problem, das ich habe, ist, dass es nie auf false gesetzt ist. Ich habe erwartet, dass es sich ändert, wenn ich "Android Tools -> Signiertes Anwendungspaket exportieren" mache, aber es hat nichts für mich.

Wie ändere ich den Build-Typ?

Es wurde eine Funktion hinzugefügt, mit der Sie Code nur im Debug-Modus ausführen können. Builds generieren jetzt eine Klasse namens BuildConfig, die eine DEBUG-Konstante enthält, die automatisch entsprechend Ihrem Build-Typ festgelegt wird. Sie können die Konstante (BuildConfig.DEBUG) in Ihrem Code überprüfen, um Nur-Debug-Funktionen auszuführen

Derzeit können Sie das richtige Verhalten erzielen, indem Sie "Automatisch erstellen" deaktivieren, das Projekt bereinigen und dann über "Android Tools -> Signiertes Anwendungspaket exportieren" exportieren. Wenn Sie die Anwendung ausführen, BuildConfig.DEBUGsollte sie falsch sein.

Mit Eclipse deaktiviere ich immer die Option "Automatisch erstellen", bevor ich die App in der Version exportiere. Dann bereinige ich das Projekt und exportiere. Andernfalls wird die Kompilierung im Debug-Modus gestartet, und der Wert von BuildConfig.DEBUG ist möglicherweise falsch.

Mit Android Studio füge ich einfach meine eigene benutzerdefinierte Variable in das build.gradle ein:

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

Wenn ich das Projekt erstelle, wird die Datei BuildConfig.java wie folgt generiert:

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

Dann kann ich in meinem Code Folgendes verwenden:

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

Ich empfehle, nach dem Wechsel von Debug / Release Build zu bereinigen.

Es funktioniert nicht richtig:

Ausgabe von 27940 : BuildConfig.DEBUG ist „true“ für exportierte Anwendungspaket

Es ist enttäuschend, dass sie manchmal fehlerhafte Funktionen veröffentlichen.

Es funktioniert, aber beachten Sie, dass sich die Codedatei auch beim Exportieren der signierten Datei nie ändert. Der Exportprozess ändert den Wert dieser Variablen auf false, mit dem Sie den falschen Eindruck erwecken könnte , dass es funktioniert nicht. Ich habe dies mit Protokollierungsanweisungen wie getestet

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

Beim Testen erzeugen meine Log-Anweisungen keine Ausgabe mehr.

Überprüfen Sie imports, ob BuildConfig manchmal unbeabsichtigt aus einer beliebigen Bibliotheksklasse importiert wird. Beispielsweise:

import io.fabric.sdk.android.BuildConfig;

In diesem Fall gibt BuildConfig.DEBUG immer false zurück .

import com.yourpackagename.BuildConfig;

In diesem Fall gibt BuildConfig.DEBUG Ihre echte Build-Variante zurück .

ps Ich kopiere nur diese aus meiner Antwort hier: BuildConfig.DEBUG immer falsch, wenn Bibliotheksprojekte mit gradle erstellt werden

Von der Vorbereitung auf die Veröffentlichung :

Deaktivieren Sie die Protokollierung und das Debuggen

Stellen Sie sicher, dass Sie die Protokollierung deaktivieren und die Debugging-Option deaktivieren, bevor Sie Ihre Anwendung für die Freigabe erstellen. Sie können die Protokollierung deaktivieren, indem Sie Aufrufe von Protokollmethoden in Ihren Quelldateien entfernen. Sie können das Debuggen deaktivieren, indem Sie das Attribut android: debuggable aus dem Tag in Ihrer Manifestdatei entfernen oder das Attribut android: debuggable in Ihrer Manifestdatei auf false setzen. Entfernen Sie auch alle Protokolldateien oder statischen Testdateien, die in Ihrem Projekt erstellt wurden.

Außerdem sollten Sie alle Debug-Ablaufverfolgungsaufrufe entfernen, die Sie Ihrem Code hinzugefügt haben, z. B. die Methodenaufrufe startMethodTracing () und stopMethodTracing ().

Weitere Informationen finden Sie unter dem Link.

Die Lösung für mich:

1. Projekt -> Automatisch erstellen
2. Projekt -> Reinigen
3. Projekt -> Erstellen
4. Projekt Android-Anwendung exportieren

Es ist Arbeit in R20

Ich würde eine einfache Problemumgehung vorschlagen wollen, wenn Sie während des APK-Exports Proguard verwenden.

Proguard bietet eine Möglichkeit, Aufrufe bestimmter Funktionen im Freigabemodus zu entfernen. Alle Aufrufe zum Debuggen von Protokollen können mit der folgenden Einstellung entfernt werden proguard-project.txt.

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

Und die Optimierung setzt ein project.properties.

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

Damit müssen Sie sich nicht um unnötige String-Berechnungen kümmern, die an das Debug-Protokoll übergeben werden, auf das @Jeremyfa verwiesen hat. Die Berechnungen werden gerade im Release Build entfernt.

Die Problemumgehung für BuildConfig.DEBUG verwendet also dieselbe Proguard-Funktion wie die folgende.

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;
    }
}

Und nach dem Einstellen proguard-project.txt.

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

Ich würde es vorziehen, dies zu verwenden, um die Build AutomaticallyOption zu deaktivieren , da dies nicht von der individuellen IDE-Einstellung des Builders abhängt, sondern als festgeschriebene Datei verwaltet wird, die von Entwicklern gemeinsam genutzt wird.

Funktioniert meines Wissens nicht richtig ( Android-Ausgabe 22241 )

Ich hatte einige Probleme mit einem Projekt (bei der Arbeit mit Eclipse). Diese Konstante wurde beim Exportieren einer signierten APK meines Projekts nicht auf true gesetzt :(

Würde gerne hören, dass es funktioniert

Ein guter Weg ist es, eine eigene Klasse zu erstellen:

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
        );
}

}

Ich habe ein seltsames Verhalten gesehen, das damit zu tun hat, dass die Werte in BuildConfig auf ihre endgültigen Werte gesetzt werden. Dies hat möglicherweise etwas mit Ihrem Problem zu tun.

Die einfache Erklärung ist, dass die Standardwerte zunächst vor der Ausführung von Proguard festgelegt werden. Nach der Ausführung von Proguard wird die BuildConfig-Datei mit den richtigen Werten neu generiert. Proguard hat Ihren Code jedoch bereits zu diesem Zeitpunkt optimiert, und Sie haben Probleme.

Hier ist ein Fehler, den ich gegen Gradle erstellt habe. https://code.google.com/p/android/issues/detail?id=182449