Home » Android » android – Using Log.d() or Log.e() in my code

android – Using Log.d() or Log.e() in my code

Posted by: admin June 15, 2020 Leave a comment


I have used Log.d() and Log.e() through out my android application for debugging purpose.
I would like to know if I release my application like this, will the user sees all those debug statement that I put in? Do I need to do something special so that user won’t see the debug log even if they hook up ‘adb logcat’?

Thank you.

How to&Answers:

Consider using this : isLoggable()

Checks to see whether or not a log for the specified tag is loggable at the specified level. The default level of any tag is set to INFO. This means that any level above and including INFO will be logged. Before you make any calls to a logging method you should check to see if your tag should be logged. You can change the default level by setting a system property: setprop log.tag.<YOUR_LOG_TAG> <LEVEL> Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or SUPPRESS. SUPPRESS will turn off all logging for your tag. You can also create a local.prop file that with the following in it: log.tag.<YOUR_LOG_TAG>=<LEVEL> and place that in /data/local.prop

Personally for releases, I’d remove the debug logs and keep the error logs using Proguard.

It is better to wrap it like so:

public class MyLog {

public static void d(String tag, String msg) {
   if (Log.isLoggable(tag, Log.DEBUG)) {
       Log.d(tag, msg);

public static void i(String tag, String msg) {
    if (Log.isLoggable(tag, Log.INFO)) {
     Log.i(tag, msg);
}  // and so on... 

You can set logging level by issuing an adb command


Leaving logging statements can, in some cases, be very bad:

You can use ProGuard to automatically remove them all:

-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** e(...);


Not only can the user (or any app with log access) see your logs, but your logs also cause your app to run slower and use more battery power.

Writing a log, especially from Java, is probably much more expensive than you think: just building the string in Java is a lot of work.


There are apps in the Market that allow users to see logs even without hooking up a development environment.

CatLog is one I have personally used and it will show you everything.

What I’ve done in my app is create a wrapper class that I can turn off myself with a boolean flag. It has the added benefit of having the TAG parameter being common throughput my code.

public class QLog {
    private static final String TAG = "MyAppTag";
    private static final boolean DEBUG_MODE = true;

    public static void d(String msg) {
        if(DEBUG_MODE) {
            Log.d(TAG, msg);


As it is said in android.developer.com

when you’re building the string to pass into Log.d, the compiler uses a StringBuilder and at least three allocations occur: the StringBuilder itself, the buffer, and the String object. Realistically, there is also another buffer allocation and copy, and even more pressure on the gc. That means that if your log message is filtered out, you might be doing significant work and incurring significant overhead.

here is the link:


They can be used when developing. When release, it is better to remove or obfuscate the message to protect PII(Personally identifiable information). The answer here is very useful: Android Log.v(), Log.d(), Log.i(), Log.w(), Log.e() – When to use each one?

Here is the one teach you the tool to deal with these logs when release the software.Remove all debug logging calls before publishing: are there tools to do this?


If your user is a developer, and connects the device to a developing machine and have LogCat opened he will se all logs on Logcat if he interracts with that application. When you are going to publish the application to the final user you should remove those logs.