Should I comment my log calls when creating my final package?

Question

I have an application that uses a lot of Log.d() or Log.e() calls for debugging. Now I want to create my final package for release. The Android Export feature from Eclipse mentions to remove the "Debuggable" flag in the manifest, which I have done. Should I also comment all the Log calls to improve the performance of my application or these calls will do nothing in the non debuggable final version package ?

Answer 1

I have subclassed the Log class to a class called Trace, which mirrors methods on Log. So I do Trace.d(TAG,"blah") and then within the Trace.d method the code only executes based on a static final class variable called LOGGING_LEVEL, which has levels 1-5 (none, errors only, errors & warnings, errors & warnings & info, and everything including debug) . When producing a production APK, Proguard removes all the code that isn't used in the application, so it does it for me.

For me, logging is far too important to remove from the source, but it must be removed from the production application, for performance, secure and intellectual property reasons.

This structure allows me to add a lot MORE logging to the application, which makes debugging problems much easier, but with no impact whatsoever on the production APK

public class Trace
{
    public static final int    NONE                         = 0;
    public static final int    ERRORS_ONLY                  = 1;
    public static final int    ERRORS_WARNINGS              = 2;
    public static final int    ERRORS_WARNINGS_INFO         = 3;
    public static final int    ERRORS_WARNINGS_INFO_DEBUG   = 4;

    private static final int          LOGGING_LEVEL   = ERRORS_ONLY;        // Errors + warnings + info + debug (default)

    public static void e(String tag, String msg)
    {
        if ( LOGGING_LEVEL >=1) Log.e(tag,msg);
    }

    public static void e(String tag, String msg, Exception e)
    {
        if ( LOGGING_LEVEL >=1) Log.e(tag,msg,e);
    }

    public static void w(String tag, String msg)
    {
        if ( LOGGING_LEVEL >=2) Log.w(tag, msg);
    }

    public static void i(String tag, String msg)
    {
        if ( LOGGING_LEVEL >=3) Log.i(tag,msg);
    }

    public static void d(String tag, String msg)
    {
        if ( LOGGING_LEVEL >=4) Log.d(tag, msg);
    }

}

Answer 2

From developer.android.com:

Turn off logging and debugging and clean up data/files For release, you should make sure that debug facilities are turned off and that debug and other unnecessary data/files are removed from your application project.

Remove the android:debuggable="true" attribute from the element of the manifest. Remove log files, backup files, and other unnecessary files from the application project. Check for private or proprietary data and remove it as necessary. Deactivate any calls to Log methods in the source code.

Source

Answer 3

This made me check my assumption that the log.d lines in the code would somehow not appear on a signed release apk without the debuggable flag set in the manifest, I was wrong, they still appear.

A quick search on SO led me to the accepted answer to this question: Remove all debug logging calls before publishing: are there tools to do this?

It works very well and you don't have to change any code.

Answer 4

I would remove the logging code as below:

-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int i(...);
    public static int w(...);
    public static int d(...);
    public static int e(...);
    public static java.lang.String getStackTraceString(java.lang.Throwable);
}

-assumenosideeffects class java.lang.Exception {
    public void printStackTrace();
}

-assumenosideeffects class * implements org.slf4j.Logger {
    public void trace(...);
    public void debug(...);
    public void info(...);
    public void warn(...);
    public void error(...);
    public boolean isTraceEnabled(...);
    public boolean isDebugEnabled(...);
    public boolean isInfoEnabled(...);
    public boolean isWarnEnabled(...);
    public boolean isErrorEnabled(...);
}

If required, the error and warn categories may be retained. But be sure that optimization and shrinking is enabled for the build only then the code removal is effective