Quando ADT imposta BuildConfig.DEBUG su false?

Nella versione più recente di ADT (r17) è stata aggiunta una costante generata BuildConfig.DEBUGimpostata in base al tipo di build. Il problema che ho è che non è mai impostato su false, mi aspettavo che cambiasse quando facevo "Strumenti Android -> Esporta pacchetto di applicazioni firmate" ma non è stato così per me.

Quindi come cambio il tipo di build?

Aggiunta una funzionalità che consente di eseguire del codice solo in modalità debug. Le build ora generano una classe chiamata BuildConfig contenente una costante DEBUG che viene impostata automaticamente in base al tipo di build. È possibile controllare la costante (BuildConfig.DEBUG) nel codice per eseguire le funzioni di solo debug

Al momento è possibile ottenere il comportamento corretto disabilitando "Build Automatically", pulendo il progetto e quindi esportandolo tramite "Android Tools -> Export Signed Application Package". Quando esegui l'applicazione BuildConfig.DEBUGdovrebbe essere falso.

Con Eclipse , disabilito sempre l'opzione "Build Automatically" prima di esportare l'app in versione. Quindi pulisco il progetto ed esporto. Altrimenti inizia la compilazione in modalità debug e quindi il valore di BuildConfig.DEBUG potrebbe essere errato.

Con Android Studio , aggiungo semplicemente la mia variabile personalizzata in build.gradle:

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

Quando compilo il progetto, BuildConfig.java viene generato come segue:

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

Quindi nel mio codice posso usare:

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

Consiglio di pulire dopo aver cambiato build di debug / rilascio.

Non funziona correttamente:

Problema 27940 : BuildConfig.DEBUG è "true" per il pacchetto dell'applicazione esportato

È deludente che a volte rilasciano funzionalità difettose.

Funziona, ma tieni presente che il file di codice non cambia mai, anche durante l'esportazione del file firmato. Il processo di esportazione modifica il valore di questa variabile in false, il che potrebbe darti la falsa impressione che non funzioni. L'ho testato con dichiarazioni di registrazione come

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

Durante il test, le mie istruzioni Log non producono più alcun output.

Verifica imports, a volte BuildConfig viene importato involontariamente da qualsiasi classe di libreria. Per esempio:

import io.fabric.sdk.android.BuildConfig;

In questo caso BuildConfig.DEBUG restituirà sempre false ;

import com.yourpackagename.BuildConfig;

In questo caso BuildConfig.DEBUG restituirà la tua variante di build reale .

ps Ho appena copiato questo dalla mia risposta qui: BuildConfig.DEBUG sempre falso quando si costruiscono progetti di libreria con gradle

Dalla preparazione per il rilascio :

Disattiva la registrazione e il debug

Assicurati di disattivare la registrazione e disabilitare l'opzione di debug prima di creare l'applicazione per il rilascio. È possibile disattivare la registrazione rimuovendo le chiamate ai metodi Log nei file di origine. Puoi disabilitare il debug rimuovendo l'attributo android: debuggable dal tag nel tuo file manifest oppure impostando l'attributo android: debuggable su false nel tuo file manifest. Inoltre, rimuovi qualsiasi file di registro o file di test statico che sono stati creati nel tuo progetto.

Inoltre, è necessario rimuovere tutte le chiamate di traccia di debug aggiunte al codice, come le chiamate ai metodi startMethodTracing () e stopMethodTracing ().

Maggiori informazioni sono seguendo il link.

La soluzione per me:

1. Progetto -> Crea automaticamente
2. Progetto -> Pulisci
3. Progetto -> Costruisci
4. Applicazione Android Project Export

Funziona in r20

Vorrei proporre una semplice soluzione alternativa se utilizzi proguard durante l'esportazione dell'APK.

Proguard fornisce un modo per rimuovere le chiamate a funzioni specifiche in modalità di rilascio. Qualsiasi chiamata per i log di debug può essere rimossa con la seguente impostazione in proguard-project.txt.

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

E l'impostazione dell'ottimizzazione project.properties.

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

Con questo, non è necessario preoccuparsi di alcun calcolo String non necessario che passa al log di debug a cui puntava @Jeremyfa. I calcoli vengono rimossi solo nella build di rilascio.

Quindi la soluzione alternativa per BuildConfig.DEBUG utilizza la stessa funzionalità di proguard come segue.

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

E dopo l'impostazione proguard-project.txt.

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

Preferirei usarlo per disabilitare l' Build Automaticallyopzione, perché questo non dipende dall'impostazione IDE individuale del builder ma viene mantenuto come file di commit condiviso tra gli sviluppatori.

Non funziona correttamente per quanto ho capito ( problema Android 22241 )

Ho avuto qualche problema su un progetto (lavorando con Eclipse), quella costante non era impostata su true durante l'esportazione di un APK firmato del mio progetto :(

Mi piacerebbe sentire che funziona però

un buon modo è creare la tua classe:

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

}

Ho visto uno strano comportamento che ha a che fare con quando i valori in BuildConfig sono impostati sui valori finali. Questo potrebbe avere qualcosa a che fare con il tuo problema.

La semplice spiegazione è che i valori predefiniti vengono impostati inizialmente prima dell'esecuzione di Proguard, quindi dopo l'esecuzione di Proguard, il file BuildConfig viene rigenerato con i valori corretti. Tuttavia, Proguard ha già ottimizzato il tuo codice a questo punto e hai problemi.

Ecco un bug che ho creato contro Gradle. https://code.google.com/p/android/issues/detail?id=182449