Quando ADT imposta BuildConfig.DEBUG su false?


110

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


2
BuildConfig.java viene generato automaticamente dagli strumenti di build di Android e viene inserito nella cartella gen. L'APK firmato dovrebbe avere BuildConfig.DEBUG = false. Non dovrebbe essere un problema per te. Non dovresti toccare manualmente quel file ...
IgorGanapolsky

1
Se usi gradle per rilasciare questo flag è affidabile al 100%. Quindi, quando esegui un ./gradlew assemblaggioDebug è vero e quando fai assemblaggio rilascia è falso.
slott

Risposte:


56

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.


rotto anche. Che ha come conseguenza la visualizzazione di tutti i messaggi Log.d che dovrebbero essere omessi da questo flag. ps. dove archiviare la segnalazione di bug?
tomi

il mio è sempre falso, anche durante il debug
behelit

39

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.


1
Questa soluzione è la migliore se usi proguard perché genererà una costante con un valore letterale, quindi il tuo codice di debug verrà completamente rimosso dal binario in modalità di rilascio.
Victor Laerte

33

Non funziona correttamente:

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

È deludente che a volte rilasciano funzionalità difettose.


9
Vai al collegamento al problema sopra menzionato e aggiungilo a Speciali se desideri che venga risolto.
Guy

11

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.


1
Cosa hai fatto esattamente?
pbhowmick

2
Ho cambiato le istanze di BuildConfig.DEBUG in com.mypackage.BuildConfig.DEBUG, quindi ho rieseguito l'app ... e ha comunque restituito true tutto il tempo. Forse ho frainteso il tuo suggerimento.
Chris Rae

1
Quello che sto dicendo è che il codice NON cambierà. Tuttavia, com.mypackage.BuildConfig.DEBUG verrà impostato su False post compilation. Prova un'istruzione di registrazione di prova come sopra (scegli una stringa arbitraria da registrare), esegui l'esportazione e quindi eseguila. Verifica se adb mostra l'istruzione di registrazione. Sono pronto a scommettere che adb non riporterà quella dichiarazione di registrazione, a significare che DEUBUG è stato impostato su falso.
pbhowmick

1
Non sono sicuro di sapere cosa intendi per "codice" ... tuttavia, dirò che eseguire una pulizia prima di esportare l'APK (come suggerito nella risposta accettata) ha reso sia BuildConfig.DEBUG che com.mypackage.BuildConfig .DEBUG segnala falso come previsto.
Chris Rae

Avete capito bene. Questo è il comportamento previsto.
pbhowmick

10

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


1
Sì, per me è stato importato accidentalmente da android.support.compat. Immagino che sia un altro motivo per definire il tuo campo con un nome diverso.
arekolek

5

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.


1
Pensavo che questo processo ora avvenga automaticamente in fase di compilazione: developer.android.com/tools/sdk/tools-notes.html
IgorGanapolsky

Causa un errore in fase di compilazione: «Evita di codificare la modalità di debug; tralasciandolo consente il debug e il rilascio di build per assegnarne uno automaticamente »
Nikita Bosik

5

La soluzione per me:

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

Funziona in r20


1
Questo ha funzionato per me solo ora (usando l'ultimo ADT immagino). Forse la pulizia l'ha risolto, non ne sono sicuro.
Jonny

3

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.


1

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ò


1
Dovrebbe essere stato corretto in r17, è contrassegnato come tale nel bug tracker.
smith324

1
In realtà le librerie non vengono compilate in modalità di rilascio in ADT durante l'esportazione (funziona in Ant). Ho aggiornato code.google.com/p/android/issues/detail?id=27940
Xavier Ducrohet

1
@Xav grazie per aver esaminato il problema, ora smetterò di spamming te lo prometto. In realtà era il progetto principale con cui stavo avendo problemi (non guardavo la libreria dipendente). Se riesco a creare un test case concreto, lo pubblicherò nel bug tracker con lo stesso numero.
smith324

1

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

}

12
Il problema con questo metodo è che, se DEBUG è falso, java calcolerà comunque ogni stringa per passarla alla tua classe personalizzata. L'if (DEBUG) Log.d (...) è meno elegante ma più efficiente.
Jeremyfa,

0

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.