8

I have noticed that my release build, which i made in eclipse via:

Android Tools -> Export signed application package ...

My proguard-project.txt contains:

-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int i(...);
    public static int w(...);
    public static int d(...);
    public static int e(...);
}

Yet, if I run the app on a device und use CatLog to look at logs I see that there are all the Log.d(), Log.v() messages that shouldn't be there. Is there something else I should set? I have spent many hours googling but there are no clear instructions on that subject. Well most of the things i find are people with similar problems but no solutions.

fasteque
  • 4,309
  • 8
  • 38
  • 50
f470071
  • 1,527
  • 3
  • 18
  • 30

3 Answers3

21

Make sure your proguard configuration does not have -dontoptimize in it. It's the proguard optimizer that removes method calls that have "no side effects".

The SDK default proguard-android.txt has -dontoptimize in it. Use proguard-android-optimize.txt instead, and don't add -dontoptimize in your project-specific proguard configuration.

Could you please state some source where I could read up on the subject. If it exists of course.

Well, for starters -assumenosideeffects is listed under optimization options in the documentation.

One more thing bothers is that, I have read that using proguard-android-optimize.txt can cause problems on some devices. So, it is a sort od catch 22 situation.

Proguard in general can have side effects. You need to test your proguard-processed application thoroughly.

If you want to remove logging from release builds without using proguard at all, you can e.g. add

if (BuildConfig.DEBUG)

before every logging call where BuildConfig is the build configuration generated by the Gradle Android plugin. Since the DEBUG there is a compile-time constant, the Java compiler sees the condition can never be true on a release configuration and won't emit the bytecode inside the conditional block.

laalto
  • 150,114
  • 66
  • 286
  • 303
  • Thank you. Could you please state some source where I could read up on the subject. If it exists of course. One more thing bothers is that, I have read that using proguard-android-optimize.txt can cause problems on some devices. So, it is a sort od catch 22 situation. – f470071 Oct 11 '15 at 17:53
  • Thank you. I have accepted and upvoted your answers because it points to error in my settings. Thing are still not clear though and I have posted another question: http://stackoverflow.com/questions/33070599/expanation-needed-on-proguard-config-setting-in-project-properties-file. – f470071 Oct 11 '15 at 22:05
5

did you try this?

-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** v(...);
public static *** i(...);
public static *** w(...);
public static *** e(...);
    }
schwertfisch
  • 4,549
  • 1
  • 19
  • 32
1

In my application, I wrapped the logger calls with my own class, which checks a Boolean- "debugMode" before logging. This way, changing the Boolean flag to false, results in not having logs (actually, this is just the concept since I want to allow different levels of logging as well, but the idea is the same). You can configure each level as you wish, so you still see severe logs but exclude the debug ones.

Daniel L.
  • 5,060
  • 10
  • 36
  • 59
  • While this will remove the log *output*, it won't remove the log *calls* unless you do the boolean check against a constant at the call site (allowing the compiler to elide the call). Some people want to remove the log calls entirely for performance, binary size, or obfuscation. – fadden Oct 11 '15 at 18:31