Conditional Compilation: I know if I have a large ...

# getting-started

[Michael Langford]

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)

[Michael Langford]

(I know about OWASP, they are just a few years out of date with recs, and they are almost never kotlin specific)

[Youssef Shoaib [MOD]]

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.

[James Hamilton]

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/

[Michael Langford]

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.