Release-debug Builds For Android Application

In C++ I would normally setup 2 builds - debug and release with each having DEBUG and RELEASE predefined respectively. I would then use these definitions to determine constant valu

Solution 1:

If you are running the application from Eclipse, it will always be a debug.

When you export the application (Android Tools -> Export (un)signed Application Package)

If you want to know dynamically if its release or debug, you can use BuildConfig.DEBUG (Its located in the gen folder, I don't know if this is supported by all the API levels)

Like as followed:

if (BuildConfig.DEBUG) {
    Log.d(TAG, "Text");
}

If you look at the generated bytecodes you will see the following (In debug mode):

publicclassSample{

    privatestatic final booleanLOG_ENABLED = true;

    publicstaticvoidmain(String args[]){
        if (BuildConfig.DEBUG){
            System.out.println("Hello World");
        }
    }
}

Produces the following bytecodes:

publicclassSampleextendsjava.lang.Object{
    publicSample();
      Code:
       0:   aload_0
       1:   invokespecial   #1; //Method java/lang/Object."<init>":()V4:   returnpublicstaticvoidmain(java.lang.String[]);
      Code:
       0:   getstatic   #2; //Field java/lang/System.out:Ljava/io/PrintStream;3:   ldc #3; //String Hello World5:   invokevirtual   #4; //Method Java/io/PrintStream.println(Ljava/lang/String;)V8:   return

}

And if the BuildConfig.DEBUG is false

publicclassSampleextendsjava.lang.Object{
    publicSample();
      Code:
       0:   aload_0
       1:   invokespecial   #1; //Method java/lang/Object."<init>":()V4:   returnpublicstaticvoidmain(java.lang.String[]);
      Code:
       0:   return
}

Solution 2:

There's no (by default) any preprocessor for Java, so no #ifdef stuff at compile time. But if you do not mind leaving debug code in your app, then you can check if app is release or debug at runtime with this code:

Booleanrelease= (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE);

which checks debuggable flag value. And said flad is automatically set to false for release builds and true for debug builds.

If you want to get rid of some debug code, you may try using ProGuard to strip certain classes or methods. And by default ProGuard is involved in building process for release builds only.

Solution 3:

I normally create a separate log class where i set a static DEBUG variable. Now all i need to go before getting a production build is to set that DEBUG variable to false.

publicclassLog {
     public final staticStringLOGTAG = "APP NAME";

      publicstatic final booleanDEBUG = true;

      publicstaticvoidv(String msg) {
        android.util.Log.v(LOGTAG, msg);
      }

      publicstaticvoide(String msg) {
        android.util.Log.e(LOGTAG, msg);
      }

      publicstaticvoidd(String msg) {
          android.util.Log.d(LOGTAG, msg);
      }
}

For logging -

if(Log.DEBUG) Log.v("In some function x. Doing y.");

Solution 4:

I was facing the same issue as everytime I was running the project as android application it used to open in debugger mode but then the problem was solved.

-If you are working in eclipse you must be using Java EE perspective -Instead just select Java perspective.

-Clean your app. -uninstall the app from the device. -Restart your device (Just like that so that no cache is stored) -Run your app.

The debugger mode won't show up this time. Copy the apk generated in your bin folder and try it out on other devices as well

Solution 5:

I found a way to decently emulate a preprocessing directive:

In my Gradle buildTypes I define:

release {
    buildConfigField "boolean", "isDebug", "false"
    ...
}

debug {
    buildConfigField "boolean", "isDebug", "true"
    ...
}

Then, in my code, I do as follows:

if (BuildConfig.isDebug) {
    ... dodebug stuff ...
}

and if needed, of course:

else {
    ... do release stuff ...
}

Both blocks are present in the debug APK, but when building a release version, Proguard is clever enough to determine that the debug block can be removed as it is dependant of a if (false) (which is also removed from the resulting code).

Should you call some debug-specific classes from the debug block and only from there, they will be stripped out from the resulting APK as they are considered unused, and this also an interesting point: your code cannot be tempered in a way it would use that code.

I could determine all that by checking my dump, mapping and usage Proguard output files.