155

I am having lots of logging statements to debug for example.

Log.v(TAG, "Message here");
Log.w(TAG, " WARNING HERE");

while deploying this application on device phone i want to turn off the verbose logging from where i can enable/disable logging.

Frank Kusters
  • 2,544
  • 2
  • 21
  • 30
d-man
  • 57,473
  • 85
  • 212
  • 296
  • Possible duplicate of [Android logging levels](https://stackoverflow.com/questions/4126815/android-logging-levels) –  Apr 16 '18 at 04:14

18 Answers18

203

The Android Documentation says the following about Log Levels:

Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept.

So you may want to consider stripping the log Verbose logging statements out, possibly using ProGuard as suggested in another answer.

According to the documentation, you can configure logging on a development device using System Properties. The property to set is log.tag.<YourTag> and it should be set to one of the following values: VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or SUPPRESS. More information on this is available in the documentation for the isLoggable() method.

You can set properties temporarily using the setprop command. For example:

C:\android>adb shell setprop log.tag.MyAppTag WARN
C:\android>adb shell getprop log.tag.MyAppTag
WARN

Alternatively, you can specify them in the file '/data/local.prop' as follows:

log.tag.MyAppTag=WARN

Later versions of Android appear to require that /data/local.prop be read only. This file is read at boot time so you'll need to restart after updating it. If /data/local.prop is world writable, it will likely be ignored.

Finally, you can set them programmatically using the System.setProperty() method.

Community
  • 1
  • 1
David Webb
  • 190,537
  • 57
  • 313
  • 299
  • 5
    I've had the same experience; the API docs are pretty unclear about exactly how this should work and even seem to mention most of the `android.util.Config` constants being deprecated. The hardcoded values specified in the API docs are useless as these (supposedly) vary by build. Hence the ProGuard route seemed the best solution for us. – Christopher Orr Jan 07 '10 at 11:20
  • 3
    Have you had any luck in configuring Android logging using either the /data/local.prop file, the setprop method or with a System.setProperty? I'm having quite a bit of trouble getting a Log.isLoggable(TAG, VERBOSE) to return true for me. – seanoshea Feb 12 '11 at 20:16
  • 2
    I've gotten android debugging working. The trick is that when you call something like Log.d("xyz") the message is written to logcat even if debug is disabled for the logger. This means filtering generally happens after being written. In order to filter before something like Log.isLoggable(TAG, Log.VERBOSE)) { Log.v(TAG, "my log message"); } is needed. This is generally pretty tiresome. I use a modified version of slf4j-android to get what I want. – phreed Mar 01 '11 at 17:34
  • 1
    See [AndroidHandler code](http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/com/android/internal/logging/AndroidHandler.java). You can simply use java.util.logging.Logger which will use the `android.util.Log` class to print the output and add the appropriate `isLoggable()` calls automatically. – Christian Gawron Jun 22 '11 at 20:03
  • 3
    @Dave were you ever able to get the local.prop method working correctly. I am also unable to make this work, I have created an entry log.tag.test=INFO and then tried to change it running setprop log.tag.test SUPPRESS from the adb shell and it doesn't change anything. Also using System.getProperty and System.setProperty does nothing. Wanted to get an update from you. Thanks. – jjNford Feb 14 '12 at 22:06
  • @jjNford - I haven't really spent any time trying to get it to work since I wrote this answer. I'd been hoping that someone else would figure it out and post a new answer. :-) – David Webb Feb 15 '12 at 08:48
  • @DaveWebb from talking with other android developers, no one I know has personally gotten this to work on anything other than the emulator - would have been a simple solution, guess I'll write my own class. – jjNford Feb 15 '12 at 13:17
  • 3
    +1 for comment "the API docs are pretty unclear about exactly how this should work". – Alan Feb 08 '13 at 17:46
  • On a real device with API 22, setting system properties did not seem to do anything. I ended up using an ugly `if ( BuildConfig.DEBUG ) { Log.d( ...); }` – Bruno Grieder Apr 08 '15 at 08:43
  • "Finally, you can set them programmatically using the System.setProperty() method"- there's no relation between Android "system" properties and Java system properties. For one, Java system properties are a per-JVM thing and Android system properties are OS-wide. – Jeffrey Blattman Sep 03 '19 at 19:46
92

The easiest way is probably to run your compiled JAR through ProGuard before deployment, with a config like:

-assumenosideeffects class android.util.Log {
    public static int v(...);
}

That will — aside from all the other ProGuard optimisations — remove any verbose log statements directly from the bytecode.

Christopher Orr
  • 110,418
  • 27
  • 198
  • 193
  • do it contains any log.property file where we can define settings. – d-man Jan 07 '10 at 08:17
  • 1
    stripping out lines with proguard means that your stack traces from production may not line up with your code. – larham1 Oct 20 '11 at 19:14
  • 3
    @larham1: ProGuard acts on the bytecode, so I would imagine removing the logging calls wouldn't alter the embedded line number metadata. – Christopher Orr Oct 26 '11 at 16:13
  • @Christopher I saw line numbers not match up. I'm talking about the line numbering, not the function names. Please try it. – larham1 Nov 10 '11 at 07:40
  • 19
    Mind this - even if the actual call to Log.v() is being stripped, its arguments are still evaluated. So if you have some costly method call inside, e.g. Log.v(TAG, generateLog()) it may hurt your performance if it's in some hot code path. Even things like toString() or String.format() can be significant. – Błażej Czapp Jul 06 '12 at 16:34
  • Just as a side note, the Honeycomb ObjectAnimator uses reflection to loosely bind to functions. They warn about the use of ProGuard in general as it may remove methods needed during reflection, that aren't otherwise utilised. If you are utilising the new Android animations framework in your code I would bear this in mind. [See this article](http://android-developers.blogspot.co.uk/2011/02/animation-in-honeycomb.html "Article here") – Darius Nov 20 '12 at 15:29
  • @HodeCode Yeah, I believe the default ProGuard configuration in recent SDK versions includes rules to keep generic get/set methods that may be required for animations. – Christopher Orr Nov 20 '12 at 23:39
  • @BlazejCzapp The call to Log.v() is stripped at bytecode level. There is nothing left after the ProGuard optimization so even if you had costly methods inside Log.v() they are all removed. Hence there is NO performance impact – Ganesh Krishnan Aug 11 '15 at 05:52
  • 4
    @GaneshKrishnan No, that's not true. The call to Log.v() is stripped but, by default, method calls to build the string will not be removed. See this answer from the author of ProGuard: http://stackoverflow.com/a/6023505/234938 – Christopher Orr Aug 11 '15 at 07:07
  • Logs are printing in signed APK, i enabled prograd but my but code those written below the logs not execute. any one face this problem. – Rohitashv jain Apr 19 '16 at 06:18
81

A common way is to make an int named loglevel, and define its debug level based on loglevel.

public static int LOGLEVEL = 2;
public static boolean ERROR = LOGLEVEL > 0;
public static boolean WARN = LOGLEVEL > 1;
...
public static boolean VERBOSE = LOGLEVEL > 4;

    if (VERBOSE) Log.v(TAG, "Message here"); // Won't be shown
    if (WARN) Log.w(TAG, "WARNING HERE");    // Still goes through

Later, you can just change the LOGLEVEL for all debug output level.

matt5784
  • 3,065
  • 2
  • 24
  • 42
Cytown
  • 1,539
  • 9
  • 7
  • 1
    nice, but how would you disable DEBUG in your example, but still showing warnings.... – Andre Bossard Jan 30 '12 at 15:01
  • 1
    Wouldn't the if statements end up in the .apk byte code? I thought we wanted to (generally) turn off logging when the application was deployed but the if statement would not be removed. – chessofnerd Jun 23 '12 at 06:28
  • 2
    in your example, DEBUG messages will be shown, while WARNs won't? wouldn't you normally want to opposite? – Sam Nov 22 '12 at 11:44
  • Just put LOGLEVEL = -1 if want to disable debug – ARMAGEDDON Aug 01 '13 at 01:07
  • 19
    Use BuildConfig.DEBUG instead of custom variables – hB0 Nov 11 '13 at 02:27
  • 1
    @chessofnerd "in Java, the code inside the if won't even be part of the compiled code. It must compile, but it won't be written to the compiled bytecode." http://stackoverflow.com/questions/7122723/will-the-compiler-optimize-this-out – stoooops Nov 22 '13 at 01:11
  • @chessofnerd What do you think of this: https://github.com/JakeWharton/hugo . - doesn't affect debug build at all - and is very easy and clean. – nAndroid Apr 25 '17 at 15:49
19

I took a simple route - creating a wrapper class that also makes use of variable parameter lists.

 public class Log{
        public static int LEVEL = android.util.Log.WARN;


    static public void d(String tag, String msgFormat, Object...args)
    {
        if (LEVEL<=android.util.Log.DEBUG)
        {
            android.util.Log.d(tag, String.format(msgFormat, args));
        }
    }

    static public void d(String tag, Throwable t, String msgFormat, Object...args)
    {
        if (LEVEL<=android.util.Log.DEBUG)
        {
            android.util.Log.d(tag, String.format(msgFormat, args), t);
        }
    }

    //...other level logging functions snipped
sschuberth
  • 28,386
  • 6
  • 101
  • 146
kdahlhaus
  • 480
  • 5
  • 8
  • 1
    As I mentioned above. I have used a modified version of slf4j-android to implement this technique. – phreed Mar 01 '11 at 17:36
  • 3
    There is a big concern on that, see http://stackoverflow.com/questions/2446248/remove-all-debug-logging-calls-before-publishing-are-there-tools-to-do-this?lq=1#comment8849301_4592958 – OneWorld Jun 20 '13 at 20:19
10

The better way is to use SLF4J API + some of its implementation.

For Android applications you can use the following:

  1. Android Logger is the lightweight but easy-to-configure SLF4J implementation (< 50 Kb).
  2. LOGBack is the most powerful and optimized implementation but its size is about 1 Mb.
  3. Any other by your taste: slf4j-android, slf4android.
Fortess Nsk
  • 111
  • 1
  • 3
  • 2
    On Android, you would have to use [`logback-android`](http://tony.github.com/logback-android) (since `logback` proper is incompatible). `logback-android-1.0.10-1.jar` is 429 KB, which isn't too bad considering the features provided, but most developers would use Proguard to optimize their application anyway. – tony19 Apr 28 '13 at 01:35
  • This doesnt save u from using if statements to check the log level before logging. See http://stackoverflow.com/questions/4958860/should-i-comment-my-log-calls-when-creating-my-final-package/4959362?noredirect=1#comment24952637_4959362 – OneWorld Jun 20 '13 at 21:03
9

You should use

    if (Log.isLoggable(TAG, Log.VERBOSE)) {
        Log.v(TAG, "my log message");
    }
Diego Torres Milano
  • 65,697
  • 9
  • 111
  • 134
  • 2
    How to config the output of isLoggable? Are debug and verbose not loggable when isDebugable is set false in manifest? – OneWorld Jun 20 '13 at 21:06
6

Stripping out the logging with proguard (see answer from @Christopher ) was easy and fast, but it caused stack traces from production to mismatch the source if there was any debug logging in the file.

Instead, here's a technique that uses different logging levels in development vs. production, assuming that proguard is used only in production. It recognizes production by seeing if proguard has renamed a given class name (in the example, I use "com.foo.Bar"--you would replace this with a fully-qualified class name that you know will be renamed by proguard).

This technique makes use of commons logging.

private void initLogging() {
    Level level = Level.WARNING;
    try {
        // in production, the shrinker/obfuscator proguard will change the
        // name of this class (and many others) so in development, this
        // class WILL exist as named, and we will have debug level
        Class.forName("com.foo.Bar");
        level = Level.FINE;
    } catch (Throwable t) {
        // no problem, we are in production mode
    }
    Handler[] handlers = Logger.getLogger("").getHandlers();
    for (Handler handler : handlers) {
        Log.d("log init", "handler: " + handler.getClass().getName());
        handler.setLevel(level);
    }
}
Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
larham1
  • 11,736
  • 5
  • 35
  • 26
4

There is a tiny drop-in replacement for the standard android Log class - https://github.com/zserge/log

Basically all you have to do is to replace imports from android.util.Log to trikita.log.Log. Then in your Application.onCreate() or in some static initalizer check for the BuilConfig.DEBUG or any other flag and use Log.level(Log.D) or Log.level(Log.E) to change the minimal log level. You can use Log.useLog(false) to disable logging at all.

4

Log4j or slf4j can also be used as logging frameworks in Android together with logcat. See the project android-logging-log4j or log4j support in android

Community
  • 1
  • 1
Rolf Kulemann
  • 213
  • 2
  • 6
3

May be you can see this Log extension class: https://github.com/dbauduin/Android-Tools/tree/master/logs.

It enables you to have a fine control on logs. You can for example disable all logs or just the logs of some packages or classes.

Moreover, it adds some useful functionalities (for instance you don't have to pass a tag for each log).

Donkey
  • 1,176
  • 11
  • 19
3

Here is a more complex solution. You will get full stack trace and the method toString() will be called only if needed(Performance). The attribute BuildConfig.DEBUG will be false in the production mode so all trace and debug logs will be removed. The hot spot compiler has the chance to remove the calls because off final static properties.

import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import android.util.Log;

public class Logger {

    public enum Level {
        error, warn, info, debug, trace
    }

    private static final String DEFAULT_TAG = "Project";

    private static final Level CURRENT_LEVEL = BuildConfig.DEBUG ? Level.trace : Level.info;

    private static boolean isEnabled(Level l) {
        return CURRENT_LEVEL.compareTo(l) >= 0;
    }

    static {
        Log.i(DEFAULT_TAG, "log level: " + CURRENT_LEVEL.name());
    }

    private String classname = DEFAULT_TAG;

    public void setClassName(Class<?> c) {
        classname = c.getSimpleName();
    }

    public String getClassname() {
        return classname;
    }

    public boolean isError() {
        return isEnabled(Level.error);
    }

    public boolean isWarn() {
        return isEnabled(Level.warn);
    }

    public boolean isInfo() {
        return isEnabled(Level.info);
    }

    public boolean isDebug() {
        return isEnabled(Level.debug);
    }

    public boolean isTrace() {
        return isEnabled(Level.trace);
    }

    public void error(Object... args) {
        if (isError()) Log.e(buildTag(), build(args));
    }

    public void warn(Object... args) {
        if (isWarn()) Log.w(buildTag(), build(args));
    }

    public void info(Object... args) {
        if (isInfo()) Log.i(buildTag(), build(args));
    }

    public void debug(Object... args) {
        if (isDebug()) Log.d(buildTag(), build(args));
    }

    public void trace(Object... args) {
        if (isTrace()) Log.v(buildTag(), build(args));
    }

    public void error(String msg, Throwable t) {
        if (isError()) error(buildTag(), msg, stackToString(t));
    }

    public void warn(String msg, Throwable t) {
        if (isWarn()) warn(buildTag(), msg, stackToString(t));
    }

    public void info(String msg, Throwable t) {
        if (isInfo()) info(buildTag(), msg, stackToString(t));
    }

    public void debug(String msg, Throwable t) {
        if (isDebug()) debug(buildTag(), msg, stackToString(t));
    }

    public void trace(String msg, Throwable t) {
        if (isTrace()) trace(buildTag(), msg, stackToString(t));
    }

    private String buildTag() {
        String tag ;
        if (BuildConfig.DEBUG) {
            StringBuilder b = new StringBuilder(20);
            b.append(getClassname());

            StackTraceElement stackEntry = Thread.currentThread().getStackTrace()[4];
            if (stackEntry != null) {
                b.append('.');
                b.append(stackEntry.getMethodName());
                b.append(':');
                b.append(stackEntry.getLineNumber());
            }
            tag = b.toString();
        } else {
            tag = DEFAULT_TAG;
        }
    }

    private String build(Object... args) {
        if (args == null) {
            return "null";
        } else {
            StringBuilder b = new StringBuilder(args.length * 10);
            for (Object arg : args) {
                if (arg == null) {
                    b.append("null");
                } else {
                    b.append(arg);
                }
            }
            return b.toString();
        }
    }

    private String stackToString(Throwable t) {
        ByteArrayOutputStream baos = new ByteArrayOutputStream(500);
        baos.toString();
        t.printStackTrace(new PrintStream(baos));
        return baos.toString();
    }
}

use like this:

Loggor log = new Logger();
Map foo = ...
List bar = ...
log.error("Foo:", foo, "bar:", bar);
// bad example (avoid something like this)
// log.error("Foo:" + " foo.toString() + "bar:" + bar); 
Andreas Mager
  • 401
  • 4
  • 9
3

I created a Utility/Wrapper which solves this problem + other common problems around Logging.

A Debugging utility with the following features:

  • The usual features provided by Log class wrapped around by LogMode s.
  • Method Entry-Exit logs: Can be turned off by a switch
  • Selective Debugging: Debug specific classes.
  • Method Execution-Time Measurement: Measure Execution time for individual methods as well as collective time spent on all methods of a class.

How To Use?

  • Include the class in your project.
  • Use it like you use android.util.Log methods, to start with.
  • Use the Entry-Exit logs feature by placing calls to entry_log()-exit_log() methods at the beginning and ending of methods in your app.

I have tried to make the documentation self suffiecient.

Suggestions to improve this Utility are welcome.

Free to use/share.

Download it from GitHub.

Vinay W
  • 9,912
  • 8
  • 41
  • 47
2

In a very simple logging scenario, where you're literally just trying to write to console during development for debugging purposes, it might be easiest to just do a search and replace before your production build and comment out all the calls to Log or System.out.println.

For example, assuming you didn't use the "Log." anywhere outside of a call to Log.d or Log.e, etc, you could simply do a find and replace across the entire solution to replace "Log." with "//Log." to comment out all your logging calls, or in my case I'm just using System.out.println everywhere, so before going to production I'll simply do a full search and replace for "System.out.println" and replace with "//System.out.println".

I know this isn't ideal, and it would be nice if the ability to find and comment out calls to Log and System.out.println were built into Eclipse, but until that happens the easiest and fastest and best way to do this is to comment out by search and replace. If you do this, you don't have to worry about mismatching stack trace line numbers, because you're editing your source code, and you're not adding any overhead by checking some log level configuration, etc.

Jim
  • 6,753
  • 12
  • 44
  • 72
2

In my apps I have a class which wraps the Log class which has a static boolean var called "state". Throughout my code I check the value of the "state" variable using a static method before actually writing to the Log. I then have a static method to set the "state" variable which ensures the value is common across all instances created by the app. This means I can enable or disable all logging for the App in one call - even when the App is running. Useful for support calls... It does mean that you have to stick to your guns when debugging and not regress to using the standard Log class though...

It's also useful (convenient) that Java interprets a boolean var as false if it hasn't been assigned a value, which means it can be left as false until you need to turn on logging :-)

Darnst
  • 91
  • 1
  • 7
2

We can use class Log in our local component and define the methods as v/i/e/d. Based on the need of we can make call further.
example is shown below.

    public class Log{
        private static boolean TAG = false;
        public static void d(String enable_tag, String message,Object...args){
            if(TAG)
            android.util.Log.d(enable_tag, message+args);
        }
        public static void e(String enable_tag, String message,Object...args){
            if(TAG)
            android.util.Log.e(enable_tag, message+args);
        }
        public static void v(String enable_tag, String message,Object...args){
            if(TAG)
            android.util.Log.v(enable_tag, message+args);
        }
    }
    if we do not need any print(s), at-all make TAG as false for all else 
    remove the check for type of Log (say Log.d).
    as 
    public static void i(String enable_tag, String message,Object...args){
    //      if(TAG)
            android.util.Log.i(enable_tag, message+args);
    }

here message is for string and and args is the value you want to print.

Irshad
  • 3,071
  • 5
  • 30
  • 51
1

For me it is often useful being able to set different log levels for each TAG.

I am using this very simple wrapper class:

public class Log2 {

    public enum LogLevels {
        VERBOSE(android.util.Log.VERBOSE), DEBUG(android.util.Log.DEBUG), INFO(android.util.Log.INFO), WARN(
                android.util.Log.WARN), ERROR(android.util.Log.ERROR);

        int level;

        private LogLevels(int logLevel) {
            level = logLevel;
        }

        public int getLevel() {
            return level;
        }
    };

    static private HashMap<String, Integer> logLevels = new HashMap<String, Integer>();

    public static void setLogLevel(String tag, LogLevels level) {
        logLevels.put(tag, level.getLevel());
    }

    public static int v(String tag, String msg) {
        return Log2.v(tag, msg, null);
    }

    public static int v(String tag, String msg, Throwable tr) {
        if (logLevels.containsKey(tag)) {
            if (logLevels.get(tag) > android.util.Log.VERBOSE) {
                return -1;
            }
        }
        return Log.v(tag, msg, tr);
    }

    public static int d(String tag, String msg) {
        return Log2.d(tag, msg, null);
    }

    public static int d(String tag, String msg, Throwable tr) {
        if (logLevels.containsKey(tag)) {
            if (logLevels.get(tag) > android.util.Log.DEBUG) {
                return -1;
            }
        }
        return Log.d(tag, msg);
    }

    public static int i(String tag, String msg) {
        return Log2.i(tag, msg, null);
    }

    public static int i(String tag, String msg, Throwable tr) {
        if (logLevels.containsKey(tag)) {
            if (logLevels.get(tag) > android.util.Log.INFO) {
                return -1;
            }
        }
        return Log.i(tag, msg);
    }

    public static int w(String tag, String msg) {
        return Log2.w(tag, msg, null);
    }

    public static int w(String tag, String msg, Throwable tr) {
        if (logLevels.containsKey(tag)) {
            if (logLevels.get(tag) > android.util.Log.WARN) {
                return -1;
            }
        }
        return Log.w(tag, msg, tr);
    }

    public static int e(String tag, String msg) {
        return Log2.e(tag, msg, null);
    }

    public static int e(String tag, String msg, Throwable tr) {
        if (logLevels.containsKey(tag)) {
            if (logLevels.get(tag) > android.util.Log.ERROR) {
                return -1;
            }
        }
        return Log.e(tag, msg, tr);
    }

}

Now just set the log level per TAG at the beginning of each class:

Log2.setLogLevel(TAG, LogLevels.INFO);
Jack Miller
  • 6,843
  • 3
  • 48
  • 66
0

Another way is to use a logging platform that has the capabilities of opening and closing logs. This can give much of flexibility sometimes even on a production app which logs should be open and which closed depending on which issues you have for example:

Elisha Sterngold
  • 2,324
  • 1
  • 16
  • 14
0

https://limxtop.blogspot.com/2019/05/app-log.html

Read this article please, where provides complete implement:

  1. For debug version, all the logs will be output;
  2. For release version, only the logs whose level is above DEBUG (exclude) will be output by default. In the meanwhile, the DEBUG and VERBOSE log can be enable through setprop log.tag.<YOUR_LOG_TAG> <LEVEL> in running time.
Saint
  • 1,492
  • 1
  • 11
  • 20