Kiedy narzędzie ADT ustawia wartość BuildConfig.DEBUG na false?

W najnowszej wersji ADT (r17) dodano wygenerowaną stałą, BuildConfig.DEBUGktóra jest ustawiana zgodnie z typem kompilacji. Problem polega na tym, że nigdy nie jest ustawiony na false, spodziewałem się, że zmieni się podczas wykonywania „Narzędzia Android -> Eksportuj podpisany pakiet aplikacji”, ale tak się nie stało.

Jak więc zmienić typ kompilacji?

Dodano funkcję, która umożliwia uruchamianie części kodu tylko w trybie debugowania. Kompilacje generują teraz klasę o nazwie BuildConfig zawierającą stałą DEBUG, która jest automatycznie ustawiana zgodnie z typem kompilacji. Możesz sprawdzić stałą (BuildConfig.DEBUG) w kodzie, aby uruchomić funkcje tylko do debugowania

Obecnie można uzyskać poprawne zachowanie, wyłączając opcję „Buduj automatycznie”, czyszcząc projekt, a następnie eksportując za pomocą opcji „Narzędzia systemu Android -> Eksportuj podpisany pakiet aplikacji”. Po uruchomieniu aplikacja BuildConfig.DEBUGpowinna być fałszywa.

W Eclipse zawsze wyłączam opcję „Buduj automatycznie” przed wyeksportowaniem aplikacji w wersji. Następnie czyszczę projekt i eksportuję. W przeciwnym razie rozpocznie kompilację w trybie debugowania, a następnie wartość BuildConfig.DEBUG może być nieprawidłowa.

W Android Studio po prostu dodaję własną zmienną niestandardową w pliku build.gradle:

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

Kiedy buduję projekt, BuildConfig.java jest generowany w następujący sposób:

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

Następnie w swoim kodzie mogę użyć:

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

Polecam wyczyścić po przełączeniu kompilacji debugowania / wydania.

Nie działa poprawnie:

Problem 27940 : BuildConfig.DEBUG ma wartość „prawda” dla wyeksportowanego pakietu aplikacji

To rozczarowujące, że czasami wypuszczają błędne funkcje.

Działa, ale pamiętaj, że plik kodu nigdy się nie zmienia, nawet podczas eksportowania podpisanego pliku. Eksport proces zmienia wartość tej zmiennej na FALSE, co może dać fałszywe wrażenie, że to nie działa. Przetestowałem to z instrukcjami logowania, takimi jak

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

Podczas testowania moje instrukcje Log nie generują już żadnych danych wyjściowych.

Sprawdź imports, czy czasami BuildConfig jest importowany z dowolnej klasy biblioteki. Na przykład:

import io.fabric.sdk.android.BuildConfig;

W tym przypadku BuildConfig.DEBUG zawsze zwróci false ;

import com.yourpackagename.BuildConfig;

W tym przypadku BuildConfig.DEBUG zwróci Twój prawdziwy wariant kompilacji .

ps Po prostu skopiowałem ten z mojej odpowiedzi tutaj: BuildConfig.DEBUG zawsze fałsz podczas budowania projektów biblioteki za pomocą gradle

Od przygotowania do wydania :

Wyłącz rejestrowanie i debugowanie

Pamiętaj, aby dezaktywować rejestrowanie i opcję debugowania przed utworzeniem aplikacji do wydania. Możesz wyłączyć rejestrowanie, usuwając wywołania metod logowania w plikach źródłowych. Możesz wyłączyć debugowanie, usuwając atrybut android: debuggable z tagu w pliku manifestu lub ustawiając atrybut android: debuggable na false w pliku manifestu. Usuń również wszystkie pliki dziennika lub statyczne pliki testowe, które zostały utworzone w projekcie.

Należy również usunąć wszystkie wywołania śledzenia debugowania, które zostały dodane do kodu, takie jak wywołania metod startMethodTracing () i stopMethodTracing ().

Więcej informacji znajduje się pod linkiem.

Rozwiązanie dla mnie:

1. Projekt -> Buduj automatycznie
2. Projekt -> Wyczyść
3. Projekt -> Kompiluj
4. Aplikacja Project Export na Androida

Działa w r20

Chciałbym zaproponować proste obejście, jeśli używasz proguard podczas eksportu APK.

Proguard zapewnia sposób usuwania wywołań określonych funkcji w trybie wydania. Wszelkie wywołania dzienników debugowania można usunąć za pomocą następującego ustawienia w proguard-project.txt.

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

I ustawianie optymalizacji project.properties.

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

Dzięki temu nie musisz przejmować się niepotrzebnym przekazywaniem obliczeń String do dziennika debugowania, na który wskazywał @Jeremyfa. Obliczenia zostały właśnie usunięte w kompilacji wydania.

Tak więc obejście dla BuildConfig.DEBUG używa tej samej funkcji proguard, co śledzenie.

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

I po ustawieniu proguard-project.txt.

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

Wolałbym używać tego Build Automaticallyzamiast wyłączać opcję, ponieważ nie zależy to od indywidualnych ustawień IDE konstruktora, ale jest utrzymywane jako zatwierdzony plik, który jest współdzielony przez programistów.

O ile zrozumiałem, nie działa poprawnie ( numer 22241 )

Miałem problemy z projektem (praca z Eclipse), ta stała nie była ustawiona na true podczas eksportowania podpisanego pliku APK mojego projektu :(

Chciałbym usłyszeć, że to działa

dobrym sposobem jest stworzenie własnej klasy:

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

}

Widziałem dziwne zachowanie, które ma związek z ustawieniem wartości w BuildConfig na ostateczne wartości. Może to mieć coś wspólnego z Twoim problemem.

Proste wyjaśnienie jest takie, że wartości domyślne są ustawiane początkowo przed uruchomieniem Proguard, a następnie po uruchomieniu Proguard plik BuildConfig jest ponownie generowany z odpowiednimi wartościami. Jednak Proguard już zoptymalizował Twój kod do tego momentu i masz problemy.

Oto błąd, który stworzyłem przeciwko Gradle. https://code.google.com/p/android/issues/detail?id=182449