Conditional Compilation: I know if I have a large pile of isolated code, I can easily conditionally compile it via module. My context here is an a mobile device android app only. However, I want to remove a pervasively used function call throughout the app for release. Let's call it "PrintStuffWeMayNotWantPrintedIn Production(varargs:List<ValuableData>)". I don't want to inactivate it, but remove it. My app functions in a somewhat adversarial situation (a medical app, low risk, but does have pentesters and curious teens to work through). I wish to not leave these call sites throughout the app as a hook that is exploitable to easily gain a bunch of info with tools such as Frida. Would this plan work: Conditionally compile out the actual part that prints/logs via BuildConfig.DEBUG then use proguard to remove the actual statement calls too? Or do I need to inline the functions too? Or is there a more "kotlinesque" way to remove/elide all the PrintStuffWeMayNotWantPrinted() calls from the app using a feature I just can't find the name of? (I'd ask other places for Proguard tips re the above, but if there are kotlin specific caveats I should be reading about, I'm all over reading your feelings or specific reference doc on the topic or even years of developer forum debate. I just don't really see more than brief exchanges on this topic)

This might be a good place for

inline

functions to shine. I think if you make that function inline, make its body wrapped in a

if(BuildConfig.DEBUG)

, then use proguard, the function will disappear, and there won't be any hooks available. I think that proguard should optimize away the contents of the if block because

DEBUG

is known to be false at compile time, but it's worth a test just in case.

I think that proguard should optimize away the contents of the if block because

DEBUG

is known to be false at compile time, but it's worth a test just in case.

Indeed, that should work! Some other ProGuard config options that could be potentially be useful for you: •

-assumenosideeffects

to tell ProGuard that some method has no side effects and then ProGuard can potentially remove calls to that method (typically used for removing Android logging code). •

-assumevalues

to tell ProGuard that some method always returns some or some field always has some value. For example, you can potentially use any field you like in the same way as

BuildConfig.DEBUG

to guard some debug code by configuring

-assumevalues

false

for that field in your release ProGuard config If you have any specific ProGuard questions a good place to ask them is the Guardsquare community https://community.guardsquare.com/

Thanks a lot James! I agree those both look like good avenues to perhaps achieve the type of code removal I'm looking for. It may also be better at removing "unused" strings that would otherwise get passed to the logging functions than just the config flag.