What's the point? Keeper adds so many keep rules that the tested sources doesn't reflect the release build.

[renaudcerrato]

I gave a try to Keeper after struggling with a few crashes due to missing R8 rules in production: I definitely needed to run my tests obfuscated. After setup, I tried to reproduce a bug I had in production (due to a missing @keep rule and the usage of reflection within the Retrofit library) with no luck. Keeper generated so many keep rules that it eventually included the missing rule I needed (just an example):

-keep class kotlinx.coroutines.flow.Flow

(the final fix was -keep,allowobfuscation,allowshrinking class kotlinx.coroutines.flow.Flow because R8 stripped the signatures required for reflection)

I looked at the mapping, and indeed, there's a lot of keep rules killing the purpose of it.

So, what's the point to use Keeper if the inferred rules are disabling obfuscation and shrinkage for so many classes ? The code under tests doesn't reflect the production code at all anymore.

[ZacSweers]

Keeper is only supposed to help with keeping APIs your tests touch. If you're seeing too many rules generated for your taste, it might be a sign that your tests are too whitebox and you should reduce how much they directly interact with APIs in your real app.

In general, without a good sample case it's hard to help you.

[renaudcerrato]

Thanks @ZacSweers for the clarifications. I ended up manually adding my -keep rules for my tests, there was an acceptable amount of them for now. I have another question, but I'll open a new post.