Logging the Android Way

Posted: July 19, 2010 in Android
Tags: , , ,
In Android Java Applications we use a logging system to record log events including errors, debugging, etc.
Log levels are:

Verbose 2
Debug 3
Info 4
Warn 5
Error 6
Assert 7

The default log level set by the Android OS is 4 and above. Its the reverse for the levels of detail
in that verbose is the most detailed log level you can use. And debug is compield but stripped out
at runtime and obvoously you do not want Verbose triggered in your producition application.

At bare minimum to get debug and verbose to show you have to set it, which you can do via:

$adb setprops log.tag. DEBUG

Quick question, if you do this what log levels show in logcat? The log level you have sset and
everything above that log level shows in logcat. Thus if you want everything to show you set Verbose log level.

Okay so where does it show up? The Android OS by default logs to logcat four ‘log streams’;

Main
Radio
Events
System

Logs of levels Verbose through Assert are sent to the Main Log stream, in other words all application logging.

Thus, how do we prevent verbose and debug from being triggered in the produciton application but have it
triggered in the application we are debugging without changing any code?

You wrap the log calls with isLogable, for example in log wrapper class:

public static void debug(final Class myClass, final String tag,
final String msg) {
if (Log.isLoggable(tag, Log.DEBUG)) {
Log.d(tag, myClass.getSimpleName() + “:” + msg);
}
}

In this case if setprops is not used to set either Verbose or debug than log debug never gets executed
because android OS defaults to INFO log level and above if not set via setprops. if you use log calls
wrapped by isLoggable than you never have to worry about removing log calls to Debug or Verbose
as the isLoggable if statements ensure its not executed if not set to Loggable.

One of the best coding practices for Android Java Application Development is code wrapper classes that
make your code development easier by saving steps. Cdoing a log wrapper class should one of your
first steps in best coding practices.

Enhanced by Zemanta
Advertisements
Comments
  1. dimsuz says:

    Thanks for the tip!

    The only thing which still confuses me is that even though the calls to Log.d will not be executed, the String’s will still be created and formatted even in release mode.

    I mean debug(“Hey, “+20+ ” puppies “+” are jumping”); would still create 3 Strings and format them into 4th in release mode, even if it wouldn’t be displayed in the log….

    Is there a method to deal with this? 🙂

  2. Also, one might look at slf4j-anroid where they produced an adapter for Android that allows to use the popular slf4j API – and this also means that one can write portable code.

  3. zul says:

    thanks for sharing the tip

  4. Bob says:

    Using Proguard is also a good way to avoid having to write unwieldy wrappers and guard every single log statement in your application. You simply write whatever logging statements you want, and then strip out the appropriate bytecode when doing a *release* build (i.e. debug and verbose statements).

    See http://stackoverflow.com/questions/2018263/android-logging/2019002#2019002

  5. […] Logging the Android Way (mobilebytes.wordpress.com) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s