Wann setzt ADT BuildConfig.DEBUG auf false?

110

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

smith324
quelle
2
BuildConfig.java wird automatisch von Android-Build-Tools generiert und im Ordner gen abgelegt. Das signierte APK sollte BuildConfig.DEBUG = false haben. Es sollte kein Problem für Sie sein. Sie sollten diese Datei nicht manuell berühren müssen ...
IgorGanapolsky
1
Wenn Sie gradle verwenden, um dieses Flag freizugeben, ist es 100% zuverlässig. Wenn Sie also ein ./gradlew assembleDebug ausführen, ist es wahr und wenn Sie assembleRelease ausführen, ist es falsch.
Slott

Antworten:

56

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.

smith324
quelle
auch kaputt. Dies hat zur Folge, dass alle Log.d-Nachrichten angezeigt werden, die von diesem Flag weggelassen werden sollten. ps. Wo kann ich einen Fehlerbericht einreichen?
Tomi
meins ist immer falsch, auch beim Debuggen
siehe
39

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.

Arnaud SmartFun
quelle
1
Diese Lösung ist die beste, wenn Sie proguard verwenden, da dadurch eine Konstante mit einem Literalwert generiert wird, sodass Ihr Debug-Code im Release-Modus vollständig aus der Binärdatei entfernt wird.
Victor Laerte
33

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.

Randy Sugianto 'Yuku'
quelle
9
Bitte gehen Sie zu dem Link zu dem oben genannten Problem und "markieren" Sie es, wenn Sie möchten, dass dies behoben wird.
Guy
11

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.

pbhowmick
quelle
1
Was genau hast du gemacht?
pbhowmick
2
Ich habe die Instanzen von BuildConfig.DEBUG in com.mypackage.BuildConfig.DEBUG geändert und dann die App erneut ausgeführt ... und sie hat immer noch true zurückgegeben. Vielleicht habe ich Ihren Vorschlag falsch verstanden.
Chris Rae
1
Was ich sage ist, dass sich der Code NICHT ändern wird. Com.mypackage.BuildConfig.DEBUG wird jedoch nach der Kompilierung auf False gesetzt. Versuchen Sie eine Testprotokollierungsanweisung wie oben (wählen Sie eine beliebige Zeichenfolge zum Protokollieren aus), führen Sie den Export durch und führen Sie sie dann aus. Überprüfen Sie, ob adb die Protokollierungsanweisung anzeigt. Ich werde wetten, dass adb diese Protokollierungsanweisung nicht meldet, was bedeutet, dass DEUBUG auf false gesetzt wurde.
pbhowmick
1
Ich bin mir nicht sicher, ob ich weiß, was Sie mit "dem Code" meinen. Ich werde jedoch sagen, dass eine Bereinigung vor dem Exportieren der APK (wie in der akzeptierten Antwort vorgeschlagen) sowohl BuildConfig.DEBUG als auch com.mypackage.BuildConfig verursacht hat .DEBUG-Bericht wie erwartet falsch.
Chris Rae
Du hast es. Das ist das erwartete Verhalten.
pbhowmick
10

Ü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

Gent Berani
quelle
1
Ja, für mich wurde es versehentlich aus importiert android.support.compat. Ich denke, das ist ein weiterer Grund, einfach Ihr eigenes Feld mit einem anderen Namen zu definieren.
Arekolek
5

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.

Peter
quelle
1
Ich dachte, dass dieser Prozess jetzt automatisch zur Erstellungszeit
abläuft
Verursacht Fehler beim Kompilieren: «Vermeiden Sie das Hardcodieren des Debug-Modus.
Wenn Sie es weglassen
5

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

e.shishkin
quelle
1
Das hat gerade bei mir funktioniert (mit dem neuesten ADT, denke ich). Vielleicht hat die Reinigung das Problem behoben, nicht sicher.
Jonny
3

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.

neo.kim
quelle
1

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

Vincent Mimoun-Prat
quelle
1
Es sollte in r17 behoben worden sein, es ist im Bug-Tracker als solches markiert.
Smith324
1
Tatsächlich werden Bibliotheken beim Exportieren in ADT nicht im Release-Modus kompiliert (funktioniert in Ant). Ich habe code.google.com/p/android/issues/detail?id=27940
Xavier Ducrohet am
1
@Xav, danke, dass du es dir angesehen hast. Ich werde jetzt aufhören, dich zu spammen. Es war eigentlich das Hauptprojekt, mit dem ich Probleme hatte (ich habe mir die abhängige Bibliothek nicht angesehen). Wenn ich einen konkreten Testfall erstellen kann, werde ich ihn unter demselben Problem an den Bug-Tracker senden.
Smith 324
1

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

}
Bouchehboun Saad
quelle
12
Das Problem bei dieser Methode ist, dass Java bei einem Fehler von DEBUG weiterhin jeden String berechnet, um ihn an Ihre benutzerdefinierte Klasse zu übergeben. Das if (DEBUG) Log.d (...) ist weniger elegant, aber effizienter.
Jeremyfa
0

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

GESCHICHTE
quelle