I was hoping for a way to comment out code on release versions.
What led me to Ant was that Proguard's way of removing Log.D (debug) calls was unsatisfactory as it was leaving the string literals in the dex files, even though the Log.D code was being removed by it's optimisation technique.
As pointed out on this thread
Removing unused strings during ProGuard optimisation
There someone one has suggested Ant could be used with a replace algorithm but this wipes out the code when it is run. I was hoping if there was a way of commenting out the code so it became //ant Log.d, then once it compiles the //ant could be removed.
I am new to ant, and I wasn't able to find any search results for commenting out code in Ant. Is it not a recommended practice? I feel copying all the files to another directory and then removing the lines and then copying it back is overkill. If the compile fails you are left with your code in another directory.
So at the moment I am using the below regex pattern to comment out the code.
<regexp pattern="(\s*)Log\.d\s*(\(.*\))\s*;"/>
<substitution expression="\1\/\/AntComment Log\.d\2;"/>
I was wondering if there is a better way i.e. a built in way of handling comments.
Also is there a way trial run ant regex statements to see what it picks up?
Listening to Jean Waghetti i tried a few bits of code with conditional compilation
I just tried a few variations, it seems it needs you to have if(DEBUG) in the same function. So this piece of code will end up having the string literal in the classes.dex file.
Logger.myLog("Sensitive Info" + c); // you call this
//in Logger class - myLog method
static void myLog(String msg){
if(DEBUG){
If you try to have a bit more sophisticated logging, where it needs figure out whether to log but with an and (&&) with DEBUG it ends up adding the string literal in the dex file eg:
public class SomeClass{
public final boolean log = DEBUG && figure_Log();
private boolean figure_Log(){
// some condition based on other settings
}
//in the code
if (log){
To achieve a more sophisticated logging you have to have this:
if(DEBUG && log){
before all logging calls, it creates too many unused code warnings and looks ugly for me.
You can put the code to be removed on a conditional block depending on a final static field.
static final DEBUG = false;
if (DEBUG) {
System.out.println("debug message");
}
The Java Language Specification has some words about "conditional compilation". It does not enforce it, but the code in the if block can be optimized and not compiled in your class. Oracle javac does this.
You can pass your classes through proguard optimization and it will (almost) certainly strip this part of code if your compiler didn't before.
Related
We are building an Android application where we use Timber for Log-output. We have defined our own .e, .d, .v etc functions and use if (BuildConfig.DEBUG) to see if we should output the log. This takes care of the issue that we don't want to output Debug-logs in our releases but all the string literals used in our functions calls are still present in the compiled source code. We furthermore use ProGuard for obfuscation. To exemplify, in a class we can have:
somObj.normalFunction(variable)
Log.d("This secret class achieved its secret mission!");
In our release, this will not be seen in the app logs but if you reverse-engineer the APK you will see something like:
q.b(m)
z.a("This secret class achieved its secret mission!");
which can give a hint to the hackers about what class they are looking at.
So what we're looking for is to either be able to completely REMOVE all the Log function calls at compile time (using some pre-processing, annotation or something, but hopefully without having to add something before EVERY function call) OR to obfuscate all the String literal parameters to those function calls. So, two ideal solutions would be if the source, just before compilation, instead looks like:
q.b(m);
or
q.b(m);
z.a("jgasoisamgp23mmwaföfm,ak,ä")
Just by thinking I can see two bad ways to achieve this. Either we surround ALL calls to Log.d with if(BuildConfig.DEBUG) which will make the compiler remove them before compilation. But this is very tideous. OR, we make sure that every time you want to add a log-printout you need to do
Log.d(LogClass.getLog(1234))
and you then define ALL those logs inside LogClass and then remove them with if(BuildConfig.DEBUG) and return null in getLog if that's the case. But that makes it more tideous every time you want to add a log.
So finally, is there any GOOD solution to this?
DISCLAIMER: I work for PreEmptive, the company that makes PreEmptive Protection - DashO.
DashO is capable of removing calls to specific methods (e.g., Log methods). While this doesn't remove the instructions to load the string literal, just the call itself, DashO also offers String Encryption, which would offer some protection to those string literals.
As an example, I ran this class through DashO:
public class App {
public static void main(String[] args) {
Log.d("Secret message here");
}
}
After removing calls to Log.d with String Encryption on, the decompiled output looks like this:
public class App
{
public static void main(String[] paramArrayOfString)
{
a.replace("Bwpfpb7u|ih}z{?($0&", -12 - -61);
}
}
DashO offers other protections (e.g., Control Flow Obfuscation) that tend to break decompilers; I've turned those off for this demonstration.
What I would do is one or some of the following:
Use Timber (so you don't need to bother removing things or adding if statements). You simply do this once in your Application#onCreate(); if you are in DEBUG, then you plant a DebugTree that prints to the console. Else, you plant an "empty tree" that does nothing.
Simulate Timber but create your own "YourLogger" class and do the same (if you don't want to include a "third-party" library even though it's just one class). So you'd have YourLogger.v("tag", "string") and inside you'd do: if (debug) { Log.v(tag, string); } and so on and so forth for all other log types.
Use Proguard to strip the logging, and what not.
1 and 2 imply you go through your app and replace all Log. lines with either Timber. or YourLogger.
Option 3 wouldn't need that, since the code would be removed during obfuscation and the calls would do nothing, but this is mode complicated (and I haven't done it in years, don't even remember how it's done, probably easy to look it up).
I'd go for 1.
Update
Since apparently I don't know how to read, I think that in order to achieve this, your only bet is to have some sort of lookup mechanism for the actual text you want to emit/hide.
Strings.xml is the easiest, since it's included with Android and you can even localize the error messages (if that were needed, of course). Yes, there's a lookup time penalty, but I'd say unless you're iterating over thousands of items and logging different strings every time or something, the penalty wont' be noticeable (I don't have data for this, you'd have to benchmark).
Alternatively, instead of relying on resources, you could just use a file, read it, and load the strings in memory... a trade off; do you use more memory at the cost of simplicity and time to code the solution, or do you use the built-in mechanism and pay the CPU time?
Something has been bothering me for awhile, and I'm wondering if I'm misremembering how things work or if something is wrong with my IDE setup.
Say I have a method
public void normalDebuggerBehavior(String x) {
(BP) int y = 12;
int z = 10;
}
If I set a breakpoint on the first line of the method (BP), and the debugger stops on that breakpoint, shouldn't I be able to see the value of the passed parameter x without needing to step to the next line (int z = 10) either by right-clicking -> evaluate expression or by adding it to the watchlist? I would think this would be in scope at this point.
If I'm not able to do this, and I'm supposed to be able, what would cause this?
Screenshot:
Stepping to the next line brings vendor into scope. Yes, this is a "fresh" compile.
Debuggers run on bytecode and not on Java source code. The mapping between Java source and bytecode is not always one-to-one.
When you place a breakpoint on the first line of a method, it is placed on the method entry point in the bytecode. The bytecode that actually reads in the method parameters has not been executed yet. You can observe this by looking at the bytecode disassembly and noticing the aload instructions at the beginning of a method with parameters.
I would assume that, since you are not using the argument x (in your example) the compiler gets rid of it, thus the debugger cant "see" it.
I think its a similar thing in your picture. It might be that the compiler optimises some stuff and thus the debugger cant see some variables...
Try turning off your jacoco test coverage off for the debug build in your build.gradle file:
debug {
...
testCoverageEnabled false
}
This completely fixed the issue for me.
In C-derivative languages there is the possibility to have conditional code for debug and runtime. That way there is no overhead left in the runtime.
How would I do this with Java/Android and the Log.i statements? If I just use a constant global boolean debugOn that obviously leaves the redundant checks in the runtime.
What is the best approach for conditional Log-statements?
Many thanks
EDIT:
Since there are quite some comments following the accepted answer I post my conclusion here....
private static final boolean DEBUG = true;
if (DEBUG) Log.i("xxx",this.getClass().getName()+ "->" + Thread.currentThread().getStackTrace()[2].getMethodName() );
...just like in xCode :)
Android build system started providing a constant BuildConfig.DEBUG some time ago, so I suggest using it and writing the code like this:
if (BuildConfig.DEBUG) Log.i(TAG, "Message");
No redundant checks will be made since it's a constant. This code will be optimized even by compiler, but you also have ProGuard at your disposal. Even if the checks are in place, any possible impact on performance should be negligible.
This approach used to have one drawback that you had to edit this constant yourself, either manually or through a custom rule in the build file. Now, however, this is handled automatically by the build system, so you don't have to do anything yourself.
Create your own Log class by by extending Log class , create static variable debugLevel inside it , create your own methods and labels like INFO, DEBUG ect .
now change in value of static varable debugLevel , will reflect to whole application.
so no need for if(debug) everywhere .
Java doesn't have C-like conditional compilation, unless you implement it yourself. (It's not all that difficult, but IMO it's not worth the trouble.)
Your options are pretty limited. The best you can do is wrap expensive logging statements in an isLoggable.
if (Log.isLoggable(tag, Log.DEBUG)) {
Log.d(tag, expensiveStringGeneration());
}
For short log statements, it's more noise than it's worth.
Edit Malcolm might be right (although I still wouldn't bother, in all likelihood.)
Edit The comparison to a static DEBUG is still in the byte code; ProGuard should remove it the unnecessary branch. Without ProGuard, it would be up to the JIT, or the compiler implementation.
I am writing my first Android application and I am liberally using asserts() from junit.framework.Assert
I would like to find a way to ensure that the asserts are only compiled into the debug build, not in the release build.
I know how to query the android:debuggable attribute from the manifest so I could create a variable and accomplish this in the following fashon:
static final boolean mDebug = ...
if (mDebug)
Assert.assertNotNull(view);
Is there a better way to do this? i.e. I would prefer not to use an if() with each assert.
thanks
I think the Java language's assert keyword is likely what you want. Under the covers, the assert keyword essentially compiles into Dalvik byte code that does two things:
Checks whether the static variable assertionsDisabled (set in the class' static constructor via a call to java.lang.Class.desiredAssertionStatus()) is != 0 and if so, does nothing
If it is 0, then it checks the assertion expression and throws a java.lang.AssertionError if the expression resolves to false, effectively terminating your application.
The Dalvik runtime by default has assertions turned off, and therefore desiredAssertionStatus always returns 1 (or more precisely, some non-zero value). This is akin to running in "retail" mode. In order to turn on "debug" mode, you can run the following command against the emulator or the device:
adb shell setprop debug.assert 1
and this should do the trick (should work on the emulator or any rooted debugging-ready device).
Note however that the aforementioned Dalvik code that checks the value of assertionsDisabled and throws an AssertionError if the expression is false is always included in your byte code and liberal sprinkling of asserts in your code may lead to byte code bloat.
Please see this for a bit more detail: Can I use assert on Android devices?
If you're concerned about shipping code with the JUnit asserts in (or any other class path), you can use the ProGuard config option 'assumenosideeffects', which will strip out a class path on the assumption that removing it does nothing to the code.
Eg.
-assumenosideeffects class junit.framework.Assert {
*;
}
I have a common debug library I put all my testing methods in, and then use this option to strip it from my released apps.
This also removes the hard to spot problem of strings being manipulated that are never used in release code. For example if you write a debug log method, and in that method you check for debug mode before logging the string, you are still constructing the string, allocating memory, calling the method, but then opting to do nothing. Stripping the class out then removes the calls entirely, meaning as long as your string is constructed inside the method call, it goes away as well.
Make sure it is genuinely safe to just strip the lines out however, as it is done with no checking on ProGuard's part. Removing any void returning method will be fine, however if you are taking any return values from whatever you are removing, make sure you aren't using them for actual operational logic.
I mean if you were using a language feature, like assert(), the compiler should be able to strip that out. But this is an actual class and if a class is referenced by executable code it will be included or assumed included in the final product by the compiler.
However there is nothing stopping you from creating a script that removes all the references to the Assert class in all of your code base before compilation.
Another approach would be to make a test project that targets your application and within JUnit tests actually calls the Assert on the areas which you want to make sure work. I personally like this approach because it is a nice and clean separation of test and application.
If you are just worried about the having an if-statement everywhere, then just wrap Assert with your own class, DebuggableAssert which does that check before each call to Assert.X. It will be sort of less performant because of the method entry/exit and the conditionals but if you can maintain your code better then it might be worth it.
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
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. ;-)
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
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.