Wie entfernt man alle Debug-Logging-Aufrufe, bevor man die Release-Version einer Android-App erstellt?

Laut Google muss ich “Deaktivieren Sie alle Aufrufe von Log-Methoden im Quellcode” bevor ich meine Android-App bei Google Play veröffentliche. Auszug aus Abschnitt 3 der Checkliste für Veröffentlichungen:

Stellen Sie sicher, dass Sie die Protokollierung deaktivieren und die Debugging-Option deaktivieren, bevor Sie Ihre Anwendung für die Veröffentlichung erstellen. Sie können die Protokollierung deaktivieren, indem Sie Aufrufe von Log-Methoden in Ihren Quelldateien entfernen.

Mein Open-Source-Projekt ist groß und es ist mühsam, es jedes Mal manuell zu tun, wenn ich es veröffentliche. Darüber hinaus ist das Entfernen einer Protokollzeile möglicherweise schwierig, zum Beispiel:

if(condition)
  Log.d(LOG_TAG, "Something");
data.load();
data.show();

Wenn ich die Log-Zeile kommentiere, gilt die Bedingung für die nächste Zeile, und es besteht die Möglichkeit, dass load() nicht aufgerufen wird. Sind solche Situationen selten genug, dass ich entscheiden kann, dass es sie nicht geben sollte?

Gibt es also einen besseren Weg, dies auf Quellcodeebene zu tun? Oder vielleicht eine clevere ProGuard-Syntax, um alle Protokollzeilen effizient, aber sicher zu entfernen?

Ich finde eine viel einfachere Lösung ist, all das zu vergessen if Kontrolliert überall und einfach verwenden ProGuard irgendwelche abzustreifen Log.d() oder Log.v() Methodenaufrufe, wenn wir unsere Ant aufrufen release Ziel.

Auf diese Weise haben wir immer die Debug-Informationen, die für reguläre Builds ausgegeben werden, und müssen keine Codeänderungen für Release-Builds vornehmen. ProGuard kann den Bytecode auch mehrfach durchlaufen, um andere unerwünschte Anweisungen und leere Blöcke zu entfernen, und kann gegebenenfalls kurze Methoden automatisch einbetten.

Hier ist zum Beispiel eine sehr einfache ProGuard-Konfiguration für Android:

-dontskipnonpubliclibraryclasses
-dontobfuscate
-forceprocessing
-optimizationpasses 5

-keep class * extends android.app.Activity
-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

Sie würden das also in einer Datei speichern, dann ProGuard von Ant aus aufrufen und Ihr gerade kompiliertes JAR und das JAR der Android-Plattform, das Sie verwenden, übergeben.

Siehe auch die Beispiele im ProGuard-Handbuch.

Update (4,5 Jahre später): Heutzutage habe ich verwendet Holz für Android-Protokollierung.

Es ist nicht nur ein bisschen schöner als die Standardeinstellung Log -Implementierung – das Protokoll-Tag wird automatisch gesetzt, und es ist einfach, formatierte Zeichenfolgen und Ausnahmen zu protokollieren – aber Sie können auch zur Laufzeit unterschiedliche Protokollierungsverhalten festlegen.

In diesem Beispiel werden Protokollierungsanweisungen nur in Debug-Builds meiner App in logcat geschrieben:

Holz ist in meinem eingerichtet Application onCreate() Methode:

if (BuildConfig.DEBUG) {
  Timber.plant(new Timber.DebugTree());
}

Dann kann ich mich an einer anderen Stelle in meinem Code einfach anmelden:

Timber.d("Downloading URL: %s", url);
try {
  // ...
} catch (IOException ioe) {
  Timber.e(ioe, "Bad things happened!");
}

Siehe die Holzmuster-App für ein fortgeschritteneres Beispiel, bei dem alle Protokollanweisungen während der Entwicklung an logcat gesendet werden und in der Produktion keine Debug-Anweisungen protokolliert werden, aber Fehler stillschweigend an Crashlytics gemeldet werden.

Alles gute Antworten, aber als ich mit meiner Entwicklung fertig war, wollte ich weder if-Anweisungen um alle Log-Aufrufe herum verwenden, noch wollte ich externe Tools verwenden.

Die Lösung, die ich verwende, besteht also darin, die android.util.Log-Klasse durch meine eigene Log-Klasse zu ersetzen:

public class Log {
    static final boolean LOG = BuildConfig.DEBUG;

    public static void i(String tag, String string) {
        if (LOG) android.util.Log.i(tag, string);
    }
    public static void e(String tag, String string) {
        if (LOG) android.util.Log.e(tag, string);
    }
    public static void d(String tag, String string) {
        if (LOG) android.util.Log.d(tag, string);
    }
    public static void v(String tag, String string) {
        if (LOG) android.util.Log.v(tag, string);
    }
    public static void w(String tag, String string) {
        if (LOG) android.util.Log.w(tag, string);
    }
}

Das einzige, was ich in allen Quelldateien tun musste, war, den Import von android.util.Log durch meine eigene Klasse zu ersetzen.

Ich schlage vor, irgendwo einen statischen booleschen Wert zu haben, der angibt, ob geloggt werden soll oder nicht:

class MyDebug {
  static final boolean LOG = true;
}

Wo immer Sie sich dann mit Ihrem Code anmelden möchten, tun Sie einfach Folgendes:

if (MyDebug.LOG) {
  if (condition) Log.i(...);
}

Wenn Sie jetzt MyDebug.LOG auf false setzen, entfernt der Compiler den gesamten Code in solchen Prüfungen (da es sich um ein statisches Finale handelt, weiß er zur Kompilierzeit, dass kein Code verwendet wird).

Bei größeren Projekten möchten Sie möglicherweise Boolesche Werte in einzelne Dateien einfügen, um die Protokollierung dort nach Bedarf einfach aktivieren oder deaktivieren zu können. Dies sind beispielsweise die verschiedenen Protokollierungskonstanten, die wir im Fenstermanager haben:

static final String TAG = "WindowManager";
static final boolean DEBUG = false;
static final boolean DEBUG_FOCUS = false;
static final boolean DEBUG_ANIM = false;
static final boolean DEBUG_LAYOUT = false;
static final boolean DEBUG_RESIZE = false;
static final boolean DEBUG_LAYERS = false;
static final boolean DEBUG_INPUT = false;
static final boolean DEBUG_INPUT_METHOD = false;
static final boolean DEBUG_VISIBILITY = false;
static final boolean DEBUG_WINDOW_MOVEMENT = false;
static final boolean DEBUG_ORIENTATION = false;
static final boolean DEBUG_APP_TRANSITIONS = false;
static final boolean DEBUG_STARTING_WINDOW = false;
static final boolean DEBUG_REORDER = false;
static final boolean DEBUG_WALLPAPER = false;
static final boolean SHOW_TRANSACTIONS = false;
static final boolean HIDE_STACK_CRAWLS = true;
static final boolean MEASURE_LATENCY = false;

Mit entsprechendem Code wie:

    if (DEBUG_FOCUS || DEBUG_WINDOW_MOVEMENT) Log.v(
        TAG, "Adding window " + window + " at "
        + (i+1) + " of " + mWindows.size() + " (after " + pos + ")");

Christophers Proguard-Lösung ist die beste, aber wenn Sie Proguard aus irgendeinem Grund nicht mögen, hier ist eine sehr technisch einfache Lösung:

Kommentarprotokolle:

find . -name "*\.java" | xargs grep -l 'Log\.' | xargs sed -i 's/Log\./;\/\/ Log\./g'

Protokolle auskommentieren:

find . -name "*\.java" | xargs grep -l 'Log\.' | xargs sed -i 's/;\/\/ Log\./Log\./g'

Eine Einschränkung besteht darin, dass sich Ihre Protokollierungsanweisungen nicht über mehrere Zeilen erstrecken dürfen.

(Führen Sie diese Zeilen in einer UNIX-Shell im Stammverzeichnis Ihres Projekts aus. Wenn Sie Windows verwenden, erhalten Sie eine UNIX-Schicht oder verwenden Sie entsprechende Windows-Befehle.)

Ich möchte einige Präzisierungen zur Verwendung von Proguard mit Android Studio und Gradle hinzufügen, da ich viele Probleme hatte, Protokollzeilen aus der endgültigen Binärdatei zu entfernen.

Damit assumenosideeffects in Proguard funktioniert, gibt es eine Voraussetzung.

In Ihrer Gradle-Datei müssen Sie die Verwendung der proguard-android-optimize.txt als Standarddatei.

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

        // With the file below, it does not work!
        //proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

Eigentlich in der Voreinstellung proguard-android.txt Datei wird die Optimierung mit den beiden Flags deaktiviert:

-dontoptimize
-dontpreverify

Die proguard-android-optimize.txt Datei fügt diese Zeilen nicht hinzu, also jetzt assumenosideeffects kann arbeiten.

Dann verwende ich persönlich SLF4J, umso mehr, wenn ich einige Bibliotheken entwickle, die an andere verteilt werden. Der Vorteil ist, dass standardmäßig keine Ausgabe erfolgt. Und wenn der Integrator Protokollausgaben wünscht, kann er Logback für Android verwenden und die Protokolle aktivieren, sodass Protokolle in eine Datei oder an LogCat umgeleitet werden können.

Wenn ich die Protokolle wirklich aus der endgültigen Bibliothek entfernen muss, füge ich sie meiner Proguard-Datei hinzu (nachdem ich die proguard-android-optimize.txt Datei natürlich):

-assumenosideeffects class * implements org.slf4j.Logger {
    public *** trace(...);
    public *** debug(...);
    public *** info(...);
    public *** warn(...);
    public *** error(...);
}

Ich empfehle dringend, Timber von Jake Wharton zu verwenden

https://github.com/JakeWharton/timber

Es löst Ihr Problem mit dem Aktivieren / Deaktivieren und fügt die Tag-Klasse automatisch hinzu

gerade

public class MyApp extends Application {

  public void onCreate() {
    super.onCreate();
    //Timber
    if (BuildConfig.DEBUG) {
      Timber.plant(new DebugTree());
    }
    ...

Protokolle werden nur in Ihrer Debug-Version verwendet und dann verwendet

Timber.d("lol");

oder

Timber.i("lol says %s","lol");

zu drucken

“Ihre Klasse / msg” ohne Angabe des Tags

Ich habe eine verwendet LogUtils Klasse wie in der Google IO-Beispielanwendung. Ich habe dies geändert, um eine anwendungsspezifische DEBUG-Konstante anstelle von BuildConfig.DEBUG zu verwenden, weil BuildConfig.DEBUG ist unzuverlässig. Dann habe ich in meinen Klassen Folgendes.

import static my.app.util.LogUtils.makeLogTag;
import static my.app.util.LogUtils.LOGV;

public class MyActivity extends FragmentActivity {
  private static final String TAG = makeLogTag(MyActivity.class);

  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    LOGV(TAG, "my message");
  }
}