android.util.Log when publishing - what can I do / not do

Question

I've got a hell of a lot of Log.i Log.d Log.e in my code for a recent app I've done. I'm about to publish this app and I don't really want people seeing it when they plug there phone into adb, but I do want it there for my own debugging.

I was wanting to extend android.util.log and just have a boolean switch in there so I could just turn off the log when I publish and turn it on when developing but this class is final, am I missing a trick?

I don't really want to go through my code an remove all, true if worst comes to worst I could do a ctrl+h global replace Log for //Log but that does suck as an answer.

I also realise that Log.d is stripped out at runtime but it is still ran (losing a little performance) so not running this would be an added bonus.

Yeah so basically I'm looking for a way to toggle my debug on and off programatically, this can also allow me later on to make it a preference or something if people want to view it or help out and send it on.

What do you guys implement for this?

Thanks

Answer 1

As Octavian points out inserting a logging constant would be the best way to do this. Writing a new class for this that calls the original logging methods if debugging is enabled is not a good idea.

Good practice:

if (C.D) { Log.d(C.T, "your log text here " + foo + bar); }

Bad practice:

YourLog.d("your log text here " + foo + bar);

// and in YourLog.java's d() method:
... { if (debugging) Log.d(tag, text); }

The first solution is very fast if the constant D of class C is false. If you have complex string operations for creating your logging string they will not be executed if debugging is deactivated. The compiler can even remove these operations at compile time if D is false, which may result in zero runtime overhead. The second (bad) solution will always build the whole string and call a method, which is overhead you don't need.

In general the first solution would be best. And yes, I really call the class and members C, D and T (Constants/Debugging/Tag) - for performance reasons during typing. ;-)

Answer 2

obfuscate using Proguard as proguard has commands to use to filter it out when you write your proguard config file..nice and simple and it works

Answer 3

It is generally a good practice to not include them in your distribution code in any way since they will need to be processed which just leads to unnecessary battery drain.

You could set a boolean in your application somewhere to indicate development or release version of your code and have a lot of if blocks checking for the flag and executing your log code or not but this just leads to code bloat.

You should get rid of them once you no longer need them.