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 plu

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.