If you prefer, you can add a consumer-rules.pro file , but it's overkill in my opinion

Can you explain what errors this change is fixing for you and what the @Keep annotation is supposed to do?

Also: any comments from @markusfisch and @benjohnde ?

@axxel
For example :

ContentType, Position, Result, readYBuffer and readBitmap are used in C++ by reflection. So if proguard is activated, it will rename(obfuscate) those, and C++ will not be able to find them anymore.

@keep annotation allows to use proguard safely

👍 for enabling minification (even in the sample). Most real-world apps will choose to enable this anyway.

I would prefer adding this line to proguard-rules.pro since the file's already there:

-keep class com.zxingcpp.** { *; }

And maybe add a note about this in the README just like I did here.

On the other hand, using the `@Keep' annotation has the advantage that a client doesn't have to think about the proguard file, which is probably a bit less error-prone.

@markusfisch
Of course you can add this line, but this is not really optimized, even if, you're right, this will not change lot of things, because the code base is small 🙂 .
On the other hand, if you put this rule in proguard-rules.pro only on sample, each team will need to add it too on its codebase. To avoid this, and do it for us, you can add this line on consumer-rules.pro, which will be used automatically by ProGuard on projects.

if each library I used could provide a consumer-rules, it will be very much easier to enable minification 😅

On the other hand, if you put this rule in proguard-rules.pro only on sample, each team will need to add it too on its codebase. To avoid this, and do it for us, you can add this line on consumer-rules.pro, which will be used automatically by ProGuard on projects.

Yes, I agree 👍 Using the proguard file for this would just be a little less clutter, but it's probably totally be worth it in this case.

if each library I used could provide a consumer-rules, it will be very much easier to enable minification 😅

I know exactly what you mean 😉

So you both agree that consumer-rules.pro is the best choice? In that case: would you update the PR?

No, we both agree that the @Keep annotation is a good way to do it 😉

The alternative, from my point of view, would be to add the mentioned line to the already existing app/proguard-rules.pro, and to add a note about it. This is the traditional way to configure ProGuard, would be more general and keeps implicitly everything in com.zxingcpp, but has the downside that every user needs to add this manually to his/her app/proguard-rules.pro too.

Just to be clear: my interpretation of your discussion that the consumer-rules thingy would combine both advantages (wildcard Keep + no manual user intervention in their proguard-rules) in one approach was wrong then?

No, using a consumer-rules file, or rather the consumerProguardFiles statement (here's a bit documentation on what that means, scroll to the bullet "A library module might include its own ProGuard configuration file"), would indeed combine both advantages of the wildcard keep and no manual user intervention.

But then we probably shouldn't enable isMinifyEnabled in the library module, because consumerProguardFiles is only used when the library is included as an AAR (or via maven), but not in a multi-module build (like it's the case with the sample). So using consumerProguardFiles and isMinifyEnabled true would break the sample - at least without the @Keep annotation, which would be redundant for the AAR case then.

So, in my opinion, we should either use the consumerProguardFiles statement, with isMinifyEnabled set to false in the library, and without the @Keep annotation, or use the @Keep annotation, in which case we can enable isMinifyEnabled for the library (and use this in the sample too). The latter case is this PR.

I've just added #660 if you would like to go with the consumerProguardFiles option.

To make my confusion complete: now you both seem to agree that #660 is the best choice after all? ;-)

Sorry for the confusion 🙈 To sum it up:

This PR:

• no user configuration required
• works in any case
• but requires a few annotations, so is a tad more code

#660

• no user configuration required
• works only when included as AAR
• is the standard way of populating a proguard configuration for AARs

I would prefer #660 but would be fine with this PR too.

Superseded by #660