How can I detect in my code that I am in Release mode or Debug mode?
10 Answers
The simplest, and best long-term solution, is to use BuildConfig.DEBUG
. This is a boolean
value that will be true
for a debug build, false
otherwise:
if (BuildConfig.DEBUG) {
// do something for a debug build
}
There have been reports that this value is not 100% reliable from Eclipse-based builds, though I personally have not encountered a problem, so I cannot say how much of an issue it really is.
If you are using Android Studio, or if you are using Gradle from the command line, you can add your own stuff to BuildConfig
or otherwise tweak the debug
and release
build types to help distinguish these situations at runtime.
The solution from Illegal Argument is based on the value of the android:debuggable
flag in the manifest. If that is how you wish to distinguish a "debug" build from a "release" build, then by definition, that's the best solution. However, bear in mind that going forward, the debuggable
flag is really an independent concept from what Gradle/Android Studio consider a "debug" build to be. Any build type can elect to set the debuggable
flag to whatever value that makes sense for that developer and for that build type.

- 986,068
- 189
- 2,389
- 2,491
-
39`BuildConfig` is located in your app's package, e.g. `import com.mycompany.myapp.BuildConfig;` – Chris Cirefice Jul 12 '15 at 20:44
-
16due to a bug in AndroiStudio this does not work anymore, it is always false, even in DEBUG mode – user387184 Jul 12 '15 at 23:35
-
1@user387184: In Android Studio 1.2.2, I get `public static final boolean DEBUG = Boolean.parseBoolean("true");` for a debug build. While that is a bizarre way to set `DEBUG` to `true`, it should work. If you are seeing this in one of the 1.3.0 test releases, or if you have a reproducible test case for 1.2.2, please [file an issue](http://b.android.com). I do not see any outstanding issues reporting this problem. – CommonsWare Jul 12 '15 at 23:39
-
2I am using v1.2.2 and BuildConfig.DEBUG is always false, then I tried the suggestion below which works for me - I will try yours as well - many thanks! – user387184 Jul 13 '15 at 09:10
-
1Doesn't seem to work, approach mentioned by Illegal Argument does work. – Peter Jul 15 '15 at 14:44
-
In Android Studio 1.3 `BuildConfig.DEBUG` can be `true` – AlvaroSantisteban Aug 05 '15 at 06:34
-
I have upgraded to AS-1.3 stable version but when I used `BuildConfig.DEBUG` in `MyApplication` class it still returned false. – Ankit Sep 15 '15 at 13:14
-
4As it turns out, this won't work when using a library (always returns true) : http://stackoverflow.com/q/20176284/878126 . Wonder what's the best alternative – android developer Jun 21 '16 at 09:33
-
Works fine on AndroidStudio 2.2.3 – Kirill Karmazin Feb 27 '17 at 14:52
-
In AndroidStudio, where can I switch between DEBUG and RELEASE? – digory doo Apr 09 '17 at 06:06
-
@digorydoo: See the Build Variants tool, default docked on the left edge of the IDE. – CommonsWare Apr 09 '17 at 11:09
-
This is always false for me, have never created a release build.. In every android studio version – behelit Jun 13 '17 at 00:18
-
@behelit: Then perhaps ask a separate Stack Overflow question, seeking help for your issue, with a [mcve]. – CommonsWare Jun 13 '17 at 10:51
-
3This answer will not work for library project (.aar) – Lavekush Agrawal Oct 26 '17 at 09:47
-
1What about `Build.gradle` I want to check if debug in gradle and not in java – user924 Oct 06 '18 at 09:27
-
@user924: That does not really work. `build.gradle` does not build Android apps. It builds a set of objects that describe how to build Android apps. So, `build.gradle` is used for every build type. At the time the `build.gradle` script is run, we are not yet building anything, and so there is no build type yet. That is why if you want different behavior for different build types you need to create custom tasks for *every* build type. – CommonsWare Oct 06 '18 at 10:44
Try the following:
boolean isDebuggable = ( 0 != ( getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE ) );
Kotlin:
val isDebuggable = 0 != applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE
It is taken from bundells post from here

- 10,760
- 10
- 47
- 69

- 10,090
- 2
- 44
- 61
-
11This answer will work in all cases regardless of library project or application project. – Lavekush Agrawal Oct 26 '17 at 09:48
-
-
3ok it just doesn't work in static context, see https://stackoverflow.com/questions/10641144/difference-between-getcontext-getapplicationcontext-getbasecontext-and – A1m Feb 28 '19 at 22:06
-
Without any imports: if (( getApplicationInfo().flags & android.content.pm.ApplicationInfo.FLAG_DEBUGGABLE ) != 0). Nice if you are writing a library and don't want to constantly be modifying the file to reference your application's package. Does require context though. – Al Ro May 12 '23 at 02:08
Yes, you will have no problems using:
if (BuildConfig.DEBUG) {
//It's not a release version.
}
Unless you are importing the wrong BuildConfig class. Make sure you are referencing your project's BuildConfig class, not from any of your dependency libraries.

- 1,949
- 17
- 18
-
2"Unless you are importing the wrong BuildConfig class"... Yeah, very good point :D – Benjamin Piette Jun 09 '17 at 14:24
-
Thanks! This was the problem in my project, somehow it was picking up library project's BuildConfig (which is always release mode until Android Studio 3 comes out) – Amit Garg Jun 09 '17 at 20:36
-
-
What if, indeed, I'm in a different module that of the project? For example I make an SDK for other apps and I wish to check it out? – android developer Mar 07 '21 at 15:01
Due to the mixed comments about BuildConfig.DEBUG
, I used the following to disable crashlytics (and analytics) in debug mode :
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'
}
}
}
then, in your code you detect the ENABLE_CRASHLYTICS
flag as follows:
if (BuildConfig.ENABLE_CRASHLYTICS)
{
// enable crashlytics and answers (Crashlytics by default includes Answers)
Fabric.with(this, new Crashlytics());
}
use the same concept in your app and rename ENABLE_CRASHLYTICS
to anything you want. I like this approach because I can see the flag in the configuration and I can control the flag.

- 23,475
- 11
- 118
- 166
-
You shouldn't call Crashlytics and Answers separately. Just use: Fabric.with(this, new Crashlytics()); to include Crashlytics and Answers. – Mike Bonnell Dec 13 '16 at 14:10
-
1Thanks, @MikeBonnell, I made the code change to the example code – Someone Somewhere Jul 22 '17 at 12:56
-
I don't see how this is any different from using BuildConfig.DEBUG - if you only set BuildConfig.ENABLE_CRASHLYTICS for your debug builds then BuildConfig.DEBUG and BuildConfig.ENABLE_CRASHLYTICS will always have the same value right? – k2col Sep 23 '17 at 12:28
-
I think dev's working on library projects had problems detecting debug/release builds using BuildConfig.DEBUG. There might have been an early Android Studio bug involved too... – Someone Somewhere Sep 26 '17 at 13:54
Alternatively, you could differentiate using BuildConfig.BUILD_TYPE;
If you're running debug build
BuildConfig.BUILD_TYPE.equals("debug");
returns true. And for release build BuildConfig.BUILD_TYPE.equals("release");
returns true.

- 2,276
- 7
- 34
- 54
-
2This is the correct answer. Returns "release" whereas BuildConfig.DEBUG always returns `true`. – Minas Mina Oct 23 '17 at 21:50
-
I am using this solution in case to find out that my app is running on debug version.
if (BuildConfig.BUILD_TYPE.equals("debug")){
//Do something
}

- 1,073
- 12
- 12
-
1Please add description to your answer. It would be more helpful than just a piece of code. – Mathews Sunny Dec 11 '17 at 13:39
-
I was using `if (BuildConfig.DEBUG) {} ` in a dependant gradle module which had (of course) NO REFERENCE to the app's build.gradle file - this caused debug mode to be recognised in a wrong way. `if (BuildConfig.BUILD_TYPE.equals("Debug")){ }` FIXED the issue. Thanks – kosiara - Bartosz Kosarzycki Feb 07 '19 at 12:22
-
-
-
1@Kamlesh at the point of writing this answer Flutter was nowhere near our minds. Please be aware of that – Giedrius Šlikas Oct 09 '20 at 13:50
-
If you are using Flutter for mobile app, you can use the constant kReleaseMode from package:flutter/foundation.dart – Kamlesh Oct 10 '20 at 04:43
-
This is close, but don't hard code the name of the build variant in. See other answers below and just make sure you are importing the correct BuildConfig. – Nicolas Mage Jan 26 '22 at 23:16
Make sure that you are importing the correct BuildConfig class And yes, you will have no problems using:
if (BuildConfig.DEBUG) {
//It's not a release version.
}

- 1,073
- 1
- 9
- 21
-
-
Not working for me. I am getting an error undefined BuildConfig class in flutter. – Kamlesh Oct 09 '20 at 13:28
You need to use this in the gradle/kts file , so that the BuildConfig file will be generated for you :
buildFeatures {
buildConfig = true
}
Then, reach the field BuildConfig.DEBUG
that belongs to the package name of your app.
Something similar to this which is less recommended (as it won't remove code when creating the release version) is to check if the app is debuggable:
val isDebuggable = context.applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE != 0

- 114,585
- 152
- 739
- 1,270
Build.IS_DEBUGGABLE could be all right. It comes from "ro.debuggable"
-
What if the release version was made to be debuggable, for some reason? – android developer Mar 07 '21 at 15:03
-
-
1
-
1@KhalidLakhani Not only that, but a debug build can be non-debuggable – android developer Jul 22 '23 at 18:20
-
@androiddeveloper got it like buildTypes { debug { debuggable true } release { debuggable false } – Khalid Lakhani Jul 23 '23 at 13:20
-
1@KhalidLakhani Indeed. Would be weird to have it for the debug build of not being debuggable, though :) – android developer Jul 23 '23 at 13:53