Jak usunąć wszystkie wywołania rejestrowania debugowania przed zbudowaniem wersji wydania aplikacji na Androida?

Według Google muszę „ dezaktywować wszelkie wywołania metod rejestrowania w kodzie źródłowym ” przed opublikowaniem mojej aplikacji na Androida w Google Play. Wyciąg z sekcji 3 listy kontrolnej publikacji :

Przed skompilowaniem aplikacji do wydania należy wyłączyć rejestrowanie i opcję debugowania. Można dezaktywować rejestrowanie, usuwając wywołania metod rejestrowania w plikach źródłowych.

Mój projekt typu open source jest duży i trudno go robić ręcznie za każdym razem, gdy go wypuszczam. Ponadto usunięcie wiersza dziennika jest potencjalnie trudne, na przykład:

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

Jeśli komentuję wiersz dziennika, wówczas warunek dotyczy następnego wiersza, a szanse, że load () nie zostaną wywołane. Czy takie sytuacje są na tyle rzadkie, że mogę zdecydować, że nie powinny istnieć?

Czy istnieje lepszy sposób na zrobienie tego na poziomie kodu źródłowego? A może sprytna składnia ProGuard, aby skutecznie, ale bezpiecznie usuwać wszystkie wiersze dziennika?

Uważam, że o wiele łatwiejszym rozwiązaniem jest zapomnienie wszystkich ifkontroli w dowolnym miejscu i po prostu skorzystanie z ProGuard, aby usunąć wszelkie wywołania metod Log.d()lub Log.v()metody, gdy wywołujemy nasz releasecel Ant .

W ten sposób zawsze otrzymujemy informacje debugowania dla regularnych kompilacji i nie musimy wprowadzać żadnych zmian w kodzie dla kompilacji wersji. ProGuard może również wykonywać wiele przejść przez kod bajtowy w celu usunięcia innych niepożądanych instrukcji, pustych bloków i może automatycznie wstawiać krótkie metody, jeśli to konieczne.

Na przykład, oto bardzo podstawowa konfiguracja ProGuard dla Androida:

-dontskipnonpubliclibraryclasses
-dontobfuscate
-forceprocessing
-optimizationpasses 5

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

Więc zapisz to w pliku, a następnie zadzwoń do ProGuard z Anta, przekazując właśnie skompilowany plik JAR i używany plik JAR platformy Android.

Zobacz także przykłady w podręczniku ProGuard.

Aktualizacja (4,5 roku później): Obecnie korzystam z rejestrowania drewna w systemie Android.

Jest nie tylko nieco ładniejszy niż domyślna Logimplementacja - znacznik dziennika jest ustawiany automatycznie, a także łatwo rejestrować sformatowane ciągi i wyjątki - ale można także określić różne zachowania rejestrowania w czasie wykonywania.

W tym przykładzie instrukcje rejestrowania zostaną zapisane do logcat tylko w kompilacjach debugowania mojej aplikacji:

W mojej Application onCreate()metodzie skonfigurowano drewno :

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

Następnie gdziekolwiek indziej w moim kodzie mogę się łatwo zalogować:

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

Zobacz przykładową aplikację Timber, aby uzyskać bardziej zaawansowany przykład, w którym wszystkie instrukcje dziennika są wysyłane do logcat podczas programowania, a podczas produkcji nie są rejestrowane żadne instrukcje debugowania, ale błędy są bezgłośnie zgłaszane Crashlytics.

Wszystkie dobre odpowiedzi, ale kiedy skończyłem mój rozwój, nie chciałem używać instrukcji if w obrębie wszystkich wywołań dziennika, ani nie chciałem używać narzędzi zewnętrznych.

Rozwiązaniem, którego używam, jest zastąpienie klasy android.util.Log własną klasą Log:

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

Jedyną rzeczą, którą musiałem zrobić we wszystkich plikach źródłowych, było zastąpienie importu android.util.Log własną klasą.

Proponuję mieć gdzieś statyczną wartość logiczną wskazującą, czy należy się zalogować:

klasa MyDebug {
  statyczny końcowy logiczny LOG = true;
}

Następnie, gdziekolwiek chcesz się zalogować, po prostu zrób to:

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

Teraz, gdy ustawisz MyDebug.LOG na false, kompilator usunie cały kod z takich kontroli (ponieważ jest to statyczny finał, wie, że w czasie kompilacji kod nie jest używany).

W przypadku większych projektów możesz chcieć zacząć mieć logiczne wartości w poszczególnych plikach, aby móc łatwo włączyć lub wyłączyć rejestrowanie w razie potrzeby. Na przykład są to różne stałe rejestrowania, które mamy w menedżerze okien:

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;

Z odpowiednim kodem, takim jak:

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

Rozwiązanie Christopher's Proguard jest najlepsze, ale jeśli z jakiegokolwiek powodu nie podoba ci się Proguard, oto bardzo mało zaawansowane rozwiązanie:

Dzienniki komentarzy:

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

Dzienniki odkomentowania:

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

Ograniczeniem jest to, że instrukcje rejestrowania nie mogą obejmować wielu linii.

(Wykonaj te wiersze w powłoce UNIX w katalogu głównym projektu. Jeśli używasz systemu Windows, uzyskaj warstwę UNIX lub użyj równoważnych poleceń systemu Windows)

Chciałbym dodać pewne szczegóły dotyczące używania Proguard z Android Studio i gradle, ponieważ miałem wiele problemów z usunięciem linii logów z ostatecznego pliku binarnego.

Warunkiem wykonania assumenosideeffectsprac Proguard jest spełnienie warunku wstępnego.

W pliku ocen musisz określić użycie proguard-android-optimize.txtpliku domyślnego.

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

W rzeczywistości w proguard-android.txtpliku domyślnym optymalizacja jest wyłączona z dwiema flagami:

-dontoptimize
-dontpreverify

proguard-android-optimize.txtPlik nie dodawać tych linii, więc teraz assumenosideeffectsmoże pracować.

Następnie osobiście używam SLF4J , tym bardziej, gdy rozwijam niektóre biblioteki, które są dystrybuowane do innych. Zaletą jest to, że domyślnie nie ma wyjścia. A jeśli integrator chce wyjść z dziennika, może użyć Logback dla Androida i aktywować logi, aby dzienniki mogły zostać przekierowane do pliku lub LogCat.

Jeśli naprawdę muszę usunąć dzienniki z ostatecznej biblioteki, dodaję do mojego pliku Proguard ( proguard-android-optimize.txtoczywiście po włączeniu pliku):

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

Gorąco polecam użycie drewna z Jake Wharton

https://github.com/JakeWharton/timber

rozwiązuje problem z włączaniem / wyłączaniem oraz automatycznie dodaje klasę znaczników

właśnie

public class MyApp extends Application {

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

dzienniki będą używane tylko w wersji debugowania, a następnie użyj

Timber.d("lol");

lub

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

drukować

„Twoja klasa / msg” bez określania tagu

Użyłem klasy LogUtils jak w przykładowej aplikacji Google IO. Zmodyfikowałem to, aby użyć stałej DEBUG specyficznej dla aplikacji zamiast BuildConfig.DEBUG, ponieważ BuildConfig.DEBUG jest zawodny . Następnie w moich klasach mam następujące.

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

Rozważałbym skorzystanie z funkcji logowania roboguice zamiast wbudowanego android.util.Log

Ich funkcja automatycznie wyłącza dzienniki debugowania i pełne dla kompilacji wersji. Ponadto masz kilka fajnych funkcji za darmo (np. Konfigurowalne zachowanie rejestrowania, dodatkowe dane dla każdego dziennika i więcej)

Korzystanie z programu proguard może być dość kłopotliwe, a ja nie przejdę przez kłopot z konfiguracją i sprawieniem, aby działał z aplikacją, chyba że masz ku temu dobry powód (wyłączenie logów nie jest dobre)

Publikuję to rozwiązanie, które dotyczy w szczególności użytkowników Androida Studio. Niedawno odkryłem Timber i pomyślnie go zaimportowałem do mojej aplikacji, wykonując następujące czynności:

Umieść najnowszą wersję biblioteki w swoim build.gradle:

compile 'com.jakewharton.timber:timber:4.1.1'

Następnie w Android Studios, przejdź do Edycja -> Znajdź -> Zamień na ścieżce ...

Wpisz Log.e(TAG,lub jakkolwiek zdefiniowałeś swoje wiadomości w polu "Text to find"tekstowym. Następnie wystarczy go zastąpićTimber.e(

Kliknij Znajdź, a następnie zamień wszystko.

Android Studios przejrzy teraz wszystkie twoje pliki w projekcie i zastąpi wszystkie dzienniki drewna.

Jedynym problemem, jaki miałem z tą metodą, jest to, że gradle ma później milion komunikatów o błędach, ponieważ nie może znaleźć „Timber” w importach dla każdego z plików Java. Wystarczy kliknąć błędy, a Android Studios automatycznie zaimportuje „Timber” do Twojej java. Gdy zrobisz to dla wszystkich plików błędów, gradle ponownie się skompiluje.

Musisz także umieścić ten fragment kodu w onCreatemetodzie swojej Applicationklasy:

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

Spowoduje to rejestrowanie aplikacji tylko wtedy, gdy jesteś w trybie programowania, a nie w produkcji. Możesz również mieć BuildConfig.RELEASEdo logowania w trybie zwolnienia.

Na android.util.Log zapewnia sposób na włączenie / wyłączenie dziennika:

public static native boolean isLoggable(String tag, int level);

Domyślnie metoda isLoggable (...) zwraca false, tylko jeśli ustawisz w urządzeniu, jak to lubi:

adb shell setprop log.tag.MyAppTag DEBUG

Oznacza to, że można wydrukować dowolny dziennik powyżej poziomu DEBUG. Dokumentacja Androida:

Sprawdza, czy dziennik dla określonego znacznika może być rejestrowany na określonym poziomie. Domyślny poziom dowolnego znacznika jest ustawiony na INFO. Oznacza to, że każdy poziom powyżej, w tym INFO, zostanie zarejestrowany. Przed wykonaniem jakichkolwiek wywołań metody logowania należy sprawdzić, czy tag powinien zostać zalogowany. Możesz zmienić domyślny poziom, ustawiając właściwość systemową: 'setprop log.tag. „Gdzie poziom to VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT lub SUPPRESS. SUPPRESS wyłączy wszystkie rejestrowanie tagu. Możesz również utworzyć plik local.prop, który zawiera następujące elementy: 'log.tag. =' I umieścić go w /data/local.prop.

Możemy więc użyć niestandardowego logu:

public final class Dlog 
{
    public static void v(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.VERBOSE))
            Log.v(tag, msg);
    }

    public static void d(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.DEBUG))
            Log.d(tag, msg);
    }

    public static void i(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.INFO))
            Log.i(tag, msg);
    }

    public static void w(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.WARN))
            Log.w(tag, msg);
    }

    public static void e(String tag, String msg)
    {
        if (Log.isLoggable(tag, Log.ERROR))
            Log.e(tag, msg);
    }
}

Jeśli można uruchomić globalny zastąpić (raz), a potem zachować pewne standardy kodowania, można śledzić wzór często używane w Android ram .

Zamiast pisać

Log.d(TAG, string1 + string2 + arg3.toString());

mieć to jako

if (BuildConfig.DEBUG) Log.d(TAG, string1 + String.format("%.2f", arg2) + arg3.toString());

Teraz proguard może usunąć StringBuilder oraz wszystkie ciągi i metody, których używa po drodze, ze zoptymalizowanego wydania DEX. Użyj proguard-android-optimize.txti nie musisz się martwić o android.util.Log w proguard-rules.pro:

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

Dzięki wtyczce stopniowej Android Studio jest dość niezawodny, więc nie potrzebujesz dodatkowych stałych do kontrolowania usuwania.BuildConfig.DEBUG

To właśnie robiłem w moich projektach na Androida.

W Android Studio możemy wykonać podobną operację, naciskając Ctrl + Shift + F, aby znaleźć z całego projektu (Command + Shift + F w MacOs) i Ctrl + Shift + R, aby zamienić ((Command + Shift + R w MacOs))

Mam bardzo proste rozwiązanie. Używam IntelliJ do programowania, więc szczegóły są różne, ale pomysł powinien dotyczyć wszystkich IDE.

Wybieram katalog główny mojego drzewa źródłowego, klikam prawym przyciskiem myszy i wybieram „zamień”. Następnie wybieram zastąpienie wszystkich „Logów”. z „// Log.”. Spowoduje to usunięcie wszystkich instrukcji dziennika. Aby odłożyć je później, powtarzam tę samą zamianę, ale tym razem zastępuję wszystkie „// Log”. za pomocą „Log”.

Działa po prostu świetnie dla mnie. Pamiętaj tylko, aby ustawić zamień na wielkość liter, aby uniknąć wypadków, takich jak „Dialog”. Dla dodatkowej pewności możesz również zrobić pierwszy krok z „Log”. jako ciąg do wyszukania.

Znakomity.

Zgodnie z sugestią zserge ,

Timber jest bardzo fajny, ale jeśli masz już istniejący projekt - możesz spróbować github.com/zserge/log. Jest to drop-in zamiennik dla android.util.Log i ma większość funkcji, które ma Timber, a nawet więcej.

jego biblioteka dzienników zapewnia proste włączanie / wyłączanie drukowania dziennika jak poniżej.

Ponadto wymaga jedynie zmiany importwierszy i nic nie wymaga zmiany dla Log.d(...);instrukcji.

if (!BuildConfig.DEBUG)
    Log.usePrinter(Log.ANDROID, false); // from now on Log.d etc do nothing and is likely to be optimized with JIT

Dodaj następujące do pliku proguard-rules.txt

-assumenosideeffects class android.util.Log {
  public static *** d(...);
  public static *** w(...);
  public static *** v(...);
  public static *** i(...);
}

Udoskonaliłem powyższe rozwiązanie, zapewniając obsługę różnych poziomów dziennika i automatycznie zmieniając poziomy dziennika w zależności od tego, czy kod jest uruchamiany na urządzeniu na żywo, czy na emulatorze.

public class Log {

final static int WARN = 1;
final static int INFO = 2;
final static int DEBUG = 3;
final static int VERB = 4;

static int LOG_LEVEL;

static
{
    if ("google_sdk".equals(Build.PRODUCT) || "sdk".equals(Build.PRODUCT)) {
        LOG_LEVEL = VERB;
    } else {
        LOG_LEVEL = INFO;
    }

}


/**
 *Error
 */
public static void e(String tag, String string)
{
        android.util.Log.e(tag, string);
}

/**
 * Warn
 */
public static void w(String tag, String string)
{
        android.util.Log.w(tag, string);
}

/**
 * Info
 */
public static void i(String tag, String string)
{
    if(LOG_LEVEL >= INFO)
    {
        android.util.Log.i(tag, string);
    }
}

/**
 * Debug
 */
public static void d(String tag, String string)
{
    if(LOG_LEVEL >= DEBUG)
    {
        android.util.Log.d(tag, string);
    }
}

/**
 * Verbose
 */
public static void v(String tag, String string)
{
    if(LOG_LEVEL >= VERB)
    {
        android.util.Log.v(tag, string);
    }
}


}

ProGuard zrobi to za Ciebie w kompilacji wydania, a teraz dobra wiadomość od android.com:

http://developer.android.com/tools/help/proguard.html

Narzędzie ProGuard zmniejsza, optymalizuje i zaciemnia kod, usuwając nieużywany kod i zmieniając nazwy klas, pól i metod za pomocą semantycznie niejasnych nazw. Wynikiem jest mniejszy plik .apk, który jest trudniejszy do odtworzenia. Ponieważ ProGuard utrudnia przekształcenie aplikacji w aplikację, ważne jest, aby używać jej, gdy aplikacja korzysta z funkcji wrażliwych na bezpieczeństwo, na przykład podczas licencjonowania aplikacji.

ProGuard jest zintegrowany z systemem kompilacji systemu Android, więc nie trzeba go wywoływać ręcznie. ProGuard działa tylko podczas budowania aplikacji w trybie wydania, więc nie musisz zajmować się zaciemnionym kodem podczas budowania aplikacji w trybie debugowania. Uruchomienie ProGuard jest całkowicie opcjonalne, ale wysoce zalecane.

W tym dokumencie opisano, jak włączyć i skonfigurować ProGuard, a także użyć narzędzia do śledzenia do dekodowania zaciemnionych śladów stosu

Lubię używać Log.d (TAG, jakiś ciąg znaków, często String.format ()).

TAG jest zawsze nazwą klasy

Przekształć Log.d (TAG, -> Logd (w tekście twojej klasy

private void Logd(String str){
    if (MainClass.debug) Log.d(className, str);
}

W ten sposób, gdy będziesz gotowy do wydania wersji, ustaw MainClass.debug na false!

Dzienniki można usunąć za pomocą bash w systemie Linux i sed:

find . -name "*\.java" | xargs sed -ri ':a; s%Log\.[ivdwe].*\);%;%; ta; /Log\.[ivdwe]/ !b; N; ba'

Działa dla dzienników wielowierszowych. W tym rozwiązaniu możesz mieć pewność, że dzienniki nie są obecne w kodzie produkcyjnym.

Wiem, że to stare pytanie, ale dlaczego nie zastąpiłeś wszystkich wywołań dziennika czymś w rodzaju logicznego logCallWasHere = true; // --- resztę twojego dziennika tutaj

Dlatego będziesz wiedział, kiedy chcesz je odłożyć, a nie wpłyną one na twoją instrukcję if :)

Dlaczego nie po prostu zrobić

if(BuildConfig.DEBUG)
  Log.d("tag","msg");

? Żadne dodatkowe biblioteki nie są potrzebne, żadne reguły proguard, które mają tendencję do psucia projektu, a kompilator Java po prostu pominie kod bajtowy dla tego wywołania podczas tworzenia kompilacji wydania.

Oto moje rozwiązanie, jeśli nie chcesz zadzierać z dodatkowymi bibliotekami lub edytować kodu ręcznie. Stworzyłem ten notatnik Jupyter, aby przeglądał wszystkie pliki Java i komentował wszystkie komunikaty dziennika. Nie idealnie, ale wykonało to za mnie zadanie.

Moja droga:

1) włącz tryb wyboru kolumny (alt + shift + wstaw)

2) wybierz jeden Log.d (TAG, „tekst”); część „Dziennik”.

3) następnie Shift + Ctrl + Alt + J

4) kliknij strzałkę w lewo

5) wykonaj Shift + End

6) naciśnij klawisz Delete.

to usuwa wszystkie wywołania LOG na raz w pliku Java.

Możesz spróbować użyć tej prostej konwencjonalnej metody:

Ctrl+ Shift+R

zastąpić

Log.e(

Z

// Log.e(

Łatwo z kotlinem, wystarczy zadeklarować kilka funkcji najwyższego poziomu

val isDebug: Boolean
    get() = BuildConfig.DEBUG

fun logE(tag: String, message: String) {
    if (isDebug) Log.e(tag, message)
}

fun logD(tag: String, message: String) {
    if (isDebug) Log.d(tag, message)
}

najprostszy sposób;

posługiwać się DebugLog

Wszystkie dzienniki są wyłączane przez DebugLog po wydaniu aplikacji.

https://github.com/MustafaFerhan/DebugLog