> ProGuard analyses the calls you have specified and only if it can
> determine that there is no return value, then the call gets removed.

Maybe I mistunderstood "return value" concept there, but I created Log
wrapper class and all its public method "return" void. So to my
understanding all calls qualifies for removal. To ensure all wrapper
calls are as primitive as possible Method("string"), so PG would have
no doubts. I told PG to remove the wrapper class as whole by specifing
"-assumenosideeffects class WrapperLog" to the PG config. And I still
see some log calls remaining and I am unable to find a reason why is
this happening.

> It is hard to speculate, what each call to Log.d("foo") can cause, and
> whether ProGuard can actually trace that there are no side effects.

That's my question. To me all shall be stripped, because I told so no
call return value exists and I wonder if anyone else tried what I do
and got any comments. I consider asking on PG's ML though anyway, to
find out how PG evaluates this

> You can help ProGuard by having a central singleton Logger and each
> class requesting child Logger from this one. Then, when you release,
> setting the logger level to OFF on that master logger should give
> ProGuard enough to establish that none of the Log calls will ever take
> place therefore removing them.
>
> If that does not work, static final boolean IF switch around each call
> to Log is your only help.

Will try this but this sort of against of my former idea. I miss #ifdef

-- 
Regards,
Marcin Orlowski

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to