Comment détecter si je suis en mode release ou debug?

374

Comment puis-je détecter dans mon code que je suis en mode Release ou Debug?

David
la source

Réponses:

770

La solution la plus simple et la meilleure à long terme est d'utiliser BuildConfig.DEBUG. C'est une booleanvaleur qui sera truepour une version de débogage, falsesinon:

if (BuildConfig.DEBUG) {
  // do something for a debug build
}

Il a été rapporté que cette valeur n'est pas fiable à 100% à partir de versions basées sur Eclipse, bien que personnellement je n'ai pas rencontré de problème, donc je ne peux pas dire à quel point c'est vraiment un problème.

Si vous utilisez Android Studio, ou si vous utilisez Gradle à partir de la ligne de commande, vous pouvez ajouter vos propres trucs BuildConfigou modifier les types de build debuget les releaseaider à distinguer ces situations lors de l'exécution.

La solution de Illegal Argument est basée sur la valeur de l' android:debuggableindicateur dans le manifeste. Si c'est ainsi que vous souhaitez distinguer une build "debug" d'une build "release", alors par définition, c'est la meilleure solution. Cependant, gardez à l'esprit qu'à l'avenir, le debuggabledrapeau est vraiment un concept indépendant de ce que Gradle / Android Studio considère comme une construction de «débogage». Tout type de build peut choisir de définir l' debuggableindicateur sur la valeur qui convient à ce développeur et à ce type de build.

CommonsWare
la source
34
BuildConfigse trouve dans le package de votre application, par exempleimport com.mycompany.myapp.BuildConfig;
Chris Cirefice
10
en raison d'un bug dans AndroiStudio cela ne fonctionne plus, c'est toujours faux, même en mode DEBUG
user387184
1
@ user387184: Dans Android Studio 1.2.2, j'obtiens public static final boolean DEBUG = Boolean.parseBoolean("true");une version de débogage. Bien que ce soit une façon bizarre de jeu DEBUGà true, il devrait fonctionner. Si vous voyez cela dans l'une des versions de test 1.3.0, ou si vous avez un cas de test reproductible pour 1.2.2, veuillez signaler un problème . Je ne vois aucun problème en suspens signalant ce problème.
CommonsWare
2
J'utilise v1.2.2 et BuildConfig.DEBUG est toujours faux, alors j'ai essayé la suggestion ci-dessous qui fonctionne pour moi - je vais également essayer la vôtre - merci beaucoup!
user387184
3
Il s'avère que cela ne fonctionnera pas lors de l'utilisation d'une bibliothèque (renvoie toujours true): stackoverflow.com/q/20176284/878126 . Je me demande quelle est la meilleure alternative
développeur Android
59

Essayez ce qui suit:

boolean isDebuggable =  ( 0 != ( getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE ) );

Kotlin:

val isDebuggable = 0 != applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE

Il est tiré du post bundells d' ici

Argument illégal
la source
3
Cette réponse fonctionnera dans tous les cas, quel que soit le projet de bibliothèque ou le projet d'application.
Lavekush Agrawal
Qu'est-ce qui doit être importé pour getApplicationInfo().flagsfonctionner?
A1m du
1
ok cela ne fonctionne tout simplement pas dans un contexte statique, voir stackoverflow.com/questions/10641144/…
A1m
54

Oui, vous n'aurez aucun problème à utiliser:

if (BuildConfig.DEBUG) {
   //It's not a release version.
}

Sauf si vous importez la mauvaise classe BuildConfig. Assurez-vous de référencer la classe BuildConfig de votre projet, pas à partir de vos bibliothèques de dépendances.

entrez la description de l'image ici

Vansuita Jr.
la source
1
"Sauf si vous importez la mauvaise classe BuildConfig" ... Oui, très bon point: D
Benjamin Piette
Merci! C'était le problème dans mon projet, en quelque sorte, il récupérait BuildConfig du projet de bibliothèque (qui est toujours en mode de sortie jusqu'à la sortie d'Android Studio 3)
Amit Garg
36

En raison des commentaires mitigés sur BuildConfig.DEBUG, j'ai utilisé ce qui suit pour désactiver les crashlytics (et les analyses) en mode débogage:

update /app/build.gradle

android {
    compileSdkVersion 25
    buildToolsVersion "25.0.1"

    defaultConfig {
        applicationId "your.awesome.app"
        minSdkVersion 16
        targetSdkVersion 25
        versionCode 100
        versionName "1.0.0"
        buildConfigField 'boolean', 'ENABLE_CRASHLYTICS', 'true'
    }
    buildTypes {
        debug {
            debuggable true
            minifyEnabled false
            buildConfigField 'boolean', 'ENABLE_CRASHLYTICS', 'false'
        }
        release {
            debuggable false
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

puis, dans votre code, vous détectez l' ENABLE_CRASHLYTICSindicateur comme suit:

    if (BuildConfig.ENABLE_CRASHLYTICS)
    {
        // enable crashlytics and answers (Crashlytics by default includes Answers)
        Fabric.with(this, new Crashlytics());
    }

utilisez le même concept dans votre application et renommez ENABLE_CRASHLYTICSce que vous voulez. J'aime cette approche car je peux voir le drapeau dans la configuration et je peux contrôler le drapeau.

Quelqu'un quelque part
la source
Vous ne devez pas appeler Crashlytics et Answers séparément. Utilisez simplement: Fabric.with (ceci, nouveau Crashlytics ()); pour inclure Crashlytics et Answers.
Mike Bonnell
1
Merci, @MikeBonnell, j'ai fait le changement de code pour l'exemple de code
Someone Somewhere
Je ne vois pas en quoi cela diffère de l'utilisation de BuildConfig.DEBUG - si vous définissez uniquement BuildConfig.ENABLE_CRASHLYTICS pour vos versions de débogage, alors BuildConfig.DEBUG et BuildConfig.ENABLE_CRASHLYTICS auront toujours la même valeur, n'est-ce pas?
k2col
Je pense que les développeurs travaillant sur des projets de bibliothèque ont eu des problèmes pour détecter les versions de débogage / version à l'aide de BuildConfig.DEBUG. Il y a peut-être aussi eu un premier bogue Android Studio ...
Someone Somewhere
13

Alternativement, vous pouvez différencier en utilisant BuildConfig.BUILD_TYPE;

Si vous exécutez le débogage, la version BuildConfig.BUILD_TYPE.equals("debug");retourne true. Et pour la version, la version BuildConfig.BUILD_TYPE.equals("release");retourne true.

Prudhvi
la source
1
Ceci est la bonne réponse. Renvoie "release" alors que BuildConfig.DEBUG revient toujours true.
Minas Mina
6

J'utilise cette solution au cas où je découvrirais que mon application fonctionne sur la version de débogage.

if (BuildConfig.BUILD_TYPE.equals("Debug")){
   //Do something
}
Giedrius Šlikas
la source
1
Veuillez ajouter une description à votre réponse. Ce serait plus utile qu'un simple morceau de code.
Mathews Sunny
J'utilisais if (BuildConfig.DEBUG) {} dans un module gradle dépendant qui n'avait (bien sûr) AUCUNE RÉFÉRENCE au fichier build.gradle de l'application - cela a causé la reconnaissance du mode de débogage de manière incorrecte. if (BuildConfig.BUILD_TYPE.equals("Debug")){ }CORRIGÉ le problème. Merci
kosiara - Bartosz Kosarzycki
c'est la vraie réponse, changez simplement "Debug" en "debug"
Jetwiz
1

Assurez-vous que vous importez la classe BuildConfig correcte Et oui, vous n'aurez aucun problème à utiliser:

if (BuildConfig.DEBUG) {
   //It's not a release version.
}
Salim Lachdhaf
la source
Cela fonctionne très bien! Je vous remercie!
sud007