IssueTracker

Any updates on the likelihood of this feature? Would sit nicely in the new DSL :)

feature request

Did we reach a point where you're not punting this any further, just deprioritizing it? Is there a way to work around this at the moment without creating a separate app / aar that has different settings just to run/not run R8 on it?

I would completely turn off R8 for test classes, it doesn't make any sense. I want to have obfuscated app to test if it is not break anything, but why test classes?

But testMinifyEnabled is OK, it just should be false by default.

I'm now fighting with it :-(

R8 does way more than obfuscation. If you enable R8 you get "tree-shaking" and "inlining" among million other optimizations, which means a few seconds running R8 could save gigabytes of CI (if you store the APKs long term), and minutes uploading, installing and running UI tests because the optimizations add up, especially considering how long it takes to dexopt APKs after install. Additionally tree-shaking could allow running without multidex even with all the AXT libraries as dependencies. (Fixing this issue, would enable all these!)

To answer your question: the reason this issue exists is because when you R8 your production code, you need to R8 your test code too to rename the references from test code to prod code. But we want to have the benefits I listed above, without changing production code.

I agree with it being off by default, and I think you bring a good point that prod and test code needs a totally separate R8 rules file. So we can add -dontobfuscate for tests.

the reason this issue exists is because when you R8 your production code, you need to R8 your test code too to rename the references from test code to prod code.

Note that is not why I filed the original issue. The original comment is pretty clear that it's for libraries which do not want to run R8 on their main code but want to on their test APK to validate things like the embedded rules.

That said there likely are more uses for the split boolean.

Yep, I saw that, but they were asking "Why obfuscate (R8) test classes?" as I read it. Anyway, we can see and agree there are many benefits to this change!

Updates: we are finalizing the dsl which means this feature needs more time to be landed.

The change Ifa2e928fe0acbf207264177ffa52d0746181338e is landed and should be available from 8.3 canary 11.

You can enable minification for android test in library projects with following dsl

android {
    buildTypes{
        debug {
            androidTest {
                enableMinification = true
            }
        }
    }
}

To add keep rules, please use

android.buildTypes.debug.testProguardFiles('xxx')

Keep it open until the "keep rule entry points" are documented properly. Currently, users need to add keep rules for test runner classes and the test classes.

AndroidX folks has tested the new feature and it works well for them. They are adding keep rules like this

# basic protection against junit/androidx.test reflection, shouldn't affect library/test code
-keepclasseswithmembers class androidx.test.** { *; }
-keepclasseswithmembers class org.junit.** { *; }
-dontwarn com.google.errorprone.annotations.MustBeClosed

## keep test classes
-keepclasseswithmembers @org.junit.runner.RunWith class * { *; }

## needed for org.junit.Test annotation to be discoverable by reflection
-keepattributes *Annotation*

Based on the discussion between r8 & androidx, having a complete list of keep rules added by default seems challenging and it is better to let users handle it.

Given the fact that androidx benchmark project is unblocked, mark it as done.

bi.../#19 will these rules be publicly available in https://github.com/androidx/androidx? In case they find issues and patch them it would be nice to have a link to the actual live solution that's always up to date.

Speaking for AndroidX performance testing - most likely yes, though we haven't decided how these will land in our repository for microbenchmarking. You can follow the R8-for-benchmarks progress at b/184378053.

This rule list is likely incomplete, as it's possible for other test infrastructure with different packages to use reflection internally. If you run into that though, for most use cases, it should be fine to just add extra lines to keep those additional packages.

In trying to use androidTest.enableMinification with microbenchmarks in a library module, I noticed two issues:

1. classes referenced by manifest entries from tests weren't kept automatically
2. only consumerProguardFiles was respected (the other two proguardFiles options didn't work)

Filed b/328649293 for these, just mentioning here in case others hit similar problems.