Why should I keep BuildConfig in ProGuard?
Asked Answered
S

3

11

I've met several proguard examples with these lines:

# Keep the BuildConfig
-keep class com.example.BuildConfig { *; }

I've run app with and without this line (of course, with my package) and haven't found any differences. I've also looked in generated/.../BuildConfig.java and there are no changes too.

What for do I need to keep my BuildConfig in ProGuard?

Thanks!

Syrup answered 25/4, 2016 at 11:46 Comment(0)
L
3

As with any other class, you need to -keep the class if you're accessing it indirectly via reflection so ProGuard won't obfuscate it or optimize it away as unused.

Most often the access patterns with BuildConfig are direct without reflection so in those cases it's fine to have ProGuard process your BuildConfig, too.

Lectionary answered 25/4, 2016 at 12:48 Comment(1)
I did not access it via reflection (at least not wittingly ;-) and it still failed when I did not exclude it from reflection. I did add paramerets via Gradle to it. But this should be done before obfuscation so I don't see why it failed.Bawdy
B
7

BuildConfig contains a number of useful values that are set at compile time. Specifically these:

boolean DEBUG – if the build is debuggable.
int VERSION_CODE
String VERSION_NAME
String APPLICATION_ID
String BUILD_TYPE – name of the build type, e.g. "release"
String FLAVOR – name of the flavor, e.g. "paidapp"

You can also set your own config values, e.g. different urls for testing and production, and retrieve them from the BuildConfig file instead of maintaining your own Config.java file. This can be done by adding buildConfigFields to your gradle buildTypes like so:

buildTypes {
    debug {
        buildConfigField "boolean", "SOME_VAR", "true"
    }
    release {
        buildConfigField "boolean", "SOME_VAR", "false"
    }
}

So to answer your question, as far as I know you don't have to keep the file, but it's good practice to do so and to use it for your config needs.

Barneybarnhart answered 25/4, 2016 at 12:24 Comment(0)
L
3

As with any other class, you need to -keep the class if you're accessing it indirectly via reflection so ProGuard won't obfuscate it or optimize it away as unused.

Most often the access patterns with BuildConfig are direct without reflection so in those cases it's fine to have ProGuard process your BuildConfig, too.

Lectionary answered 25/4, 2016 at 12:48 Comment(1)
I did not access it via reflection (at least not wittingly ;-) and it still failed when I did not exclude it from reflection. I did add paramerets via Gradle to it. But this should be done before obfuscation so I don't see why it failed.Bawdy
U
0

Some crash reporter libraries like ACRA does access BuildConfig via reflection, so if you use one and want to have info from it in your crash reports, you should -keep it.

Upside answered 19/5, 2020 at 10:54 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.