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

Question

I have a heck of a lot of Log.i Log.d Log.e in my code for a recent application that I made. I am going to publish this application, and I really do not want people to see it when they connected the phone to adb, but I want it there for my own debugging.

I would like to expand the android.util.log file and just have a logical switch so that I can just turn off the log when I publish it and turn it on during development, but this class is final, I don’t miss the trick?

I really do not want to go through my code, delete everything, however, if the worst comes to the worst, I could do ctrl + h global to replace Log for // Log, but it sucks as an answer.

I also understand that Log.d is being deleted at runtime, but it still works (losing a little performance), so not launching it will be an additional bonus.

Yes, so basically I'm looking for a way to turn debugging on and off programmatically, it can also allow me to make this preference later or something if people want to look at it or help and send it.

What are you guys implementing for this?

thank

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 (CD) { Log.d(CT, "your log text here " + foo + bar); } 

Bad practice:

 YourLog.d("your log text here " + foo + bar); // and in YourLog.java 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 a complex string operation to create your logging string, they will not be executed if debugging is disabled. The compiler can even delete these operations during compilation if D is false, which can lead to unnecessary overhead. The second (bad) solution will always build a whole line and call a method that you do not need overhead.

In general, the first solution would be best. And yes, I do call the class and members C, D and T (constants / debugging / tag) - for performance reasons when typing .; -)

Answer 2

obfuscate using Proguard since proguard has commands to filter it when you write your proguard.nice configuration file and is simple and works

Answer 3

As a general rule, it is good practice not to include them in your distribution code in any way, since they must be processed, which simply leads to unnecessary battery leakage.

You could set a boolean value in your application somewhere to indicate the version or version of the version of your code, and you have a lot of blocks checking the flag and the execution of your log code or not, but this just leads to bloating the code.

You must get rid of them as soon as you no longer need them.