Logging the Android Way

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.

Advertisement

Debug Tricks

A debug trick

public stackTraceOrHeapDumpConstructor(String LOG_TAG, String someName) {
boolean mLoggable = Log.isLoggable(LOG_TAG, Log.DEBUG);
		if(mLoggable=true){
                    the stacktrace(someName) or heap dump here
                } else {
               }
}

Now your stacktraces and Heapdump statements are not enabled if debugging is off.

Android SDK Fine Print and Debugging

Sometimes it helps to read the fine print for example, adb:

You can use the adb commands pull and push to copy files to and from an emulator/device instance’s data file. Unlike the install command, which only copies an .apk file to a specific location, the pull and push commands let you copy arbitrary directories and files to any location in an emulator/device instance.

combined with startMethodTracing(‘tracefileName’)  and  stopMethodTracing() and dumpHprofData(‘filename’) can make debugging using an ANT build script a whole lot easier and more fun. And there is some more interesting stuff in the android.os.debug class. For example buffer size of *.trace files defautls to 8 megs so one could supply a higher buffer size amount for the startMethodTracing() calls. Basically, what yu can o dis have the *trace fiel created with startMethodTracing() and the  *hprof file created with dumpHprofData() named by by the moethod as you are calling those debug statements within your method. You woudl set it up so that you have a new dirsuch as:

startMethodtracing(‘/sdcard/trace/methodName.trace’);

dumpHprofData(‘/scard/hprof/methodName.hprof’);

Then its simple manner to do an:

adb pull /sdcard/trace /userhome/project/trace

adb pull /sdcard/hprof /userhome/project/hprof

..which of course makes it a lot easier. And since android.os.Debug is a wrapper on VMDebug lets check that class for juts a second and see what other goodies we can find.  Ah aha!

startInstructionCounting(), stopInstructionCounting(), and getInstructionCounts() leap to focus. Why? If you have constructed any thing involving memory or process time such as mathematics library, a graphics library, or a game engine you are in the mobile space attempting to optimize of the last amount of executed instructions. Having ways to log the amount of instructions a method might use to the log file becomes somewhat important. In this case to get access to call you need to use dalvik.system.VMDebug as its public.