CODEWITHSUNDEEP
android
Someone Somewhere
Someone Somewhere

Reputation: 23787

Is BuildConfig.DEBUG still bugged?

According to this Blog BuildConfig.DEBUG was unreliable. Since my colleague is using BuildConfig.DEBUG extensively (seemingly like test code in production code), I'm wondering if this flag is still as bugged as it was a few years ago.

Upvotes: 10

Views: 7268

Answers (3)

Denny Weinberg
Denny Weinberg

Reputation: 2606

I had always problems with the predefined variable, so I created my own:

  buildTypes {
        // If we use the same keystore for debug and release, we don't have to wipe all preferences
        debug {
            //noinspection GroovyAssignabilityCheck
            signingConfig signingConfigs.releaseConfig
            zipAlignEnabled true

            resValue "bool", "DEBUG", "true"
        }
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            //noinspection GroovyAssignabilityCheck
            signingConfig signingConfigs.releaseConfig
            zipAlignEnabled true

            resValue "bool", "DEBUG", "false"
        }
    }

I your code you can read this variable: 

    if (!MyApplication.get().getResources().getBoolean(R.bool.DEBUG)) {
        // Firebase Crash reporting
        FirebaseCrash.report(e);
    }

Upvotes: 3

arne.jans
arne.jans

Reputation: 3856

I can confirm this bug still exists, tested with Android Studio 1.2 Build AI-140.1782451 and Gradle 1.1 compiling against Android API Level 21.

The issue is visible with a Nexus 10 on Android 5.0.2 or a similar device.

If you open BuildConfig.DEBUG in the source editor it says:

public static final boolean DEBUG = Boolean.parseBoolean("true");

But if you debug the app under question, DEBUG stays on false. This hinders my Retrofit-debugging, as I wanted to enable it conditionally depending on the build-type.

Upvotes: 11

Sam Dozor
Sam Dozor

Reputation: 40734

It seems the issue to which you are referring is specific to ADT + Eclipse. So I believe that if you're using Gradle and Android Studio, this should not be an issue.

Crucially: this only occurs if you're using the Build Automatically option, and you don't clean your project. Because of this, I would hardly consider this a bug. After all, who says what should and shouldn't be rebuilt whenever you make a code change and have Build Automatically enabled?

As a matter of good practice, you should always clean and rebuild your project prior to an actual release, in which case this is a non-issue.

So yes, this is still a problem if you're using this setting, and not rebuilding your project prior to release, and you're still using ADT and Eclipse (which seems to be destined for deprecation).

Here's the discussion of the bug: https://code.google.com/p/android/issues/detail?id=27940

Upvotes: 7

Related Questions