android – Should I comment my log calls when creating my final package?-ThrowExceptions

Exception or error:

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 ?

How to solve:

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);



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.



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.



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

Leave a Reply

Your email address will not be published. Required fields are marked *