[R8] Consumer Proguard rules

[ffournier]

Hi :)

We use this library and when we consume the proguard emebeded rules in the library, we found this in the configuration.txt generated

Tealium Specific for integratability

-keeppackagenames
-keepparameternames
-keepattributes InnerClasses, Signature, Exceptions, EnclosingMethod, SourceFile, LineNumberTable

-keep public class com.tealium.collect.** {
public protected *;
}

The rules
-keeppackagenames
-keepparameternames

are not restricted to tealium packages, and thus impact the whole project, preventing package obfuscation for the rest of our app.

Could you provide a fix that would only target tealium classes on next release, please?

In the mean time, how can we bypass those rules so we can obfuscate the rest of the project again?

Thanks :)

[jameskeith]

@ffournier - thanks for flagging this with us. I'll get a task raised internally to have this looked at. I've found when this was added, but I'm yet to find a description as to why they were specifically added as consumer-rules, rather than the regular obfuscation we ourselves undertake during publication.

I'll keep you updated.

[ffournier]

Maybe I found something ^^
#71
That's relative to this issue ?
After the consumer it's a good practice !

But if you want to keep parameter name and package you need to specify a reg ex after

-keeppackagenames com.tealium.**
-keepparameternames com.tealium.**

But what i don't understand , that you already have a specific rules for the directory collect so why do you need to keep the other packages ?

If you need I can test directly in my application and watch if the date was received on tealium server
I found a way to ignore the consumer , and I just need to retreive your consumer in configuration and fix it

Thanks :)

PS: Do you advise us to pass on the module tealium-kotlin or stay on tealium-android ?
I just discover the module tealium kotlin

[jameskeith]

Perhaps I haven't explained my thinking properly here. We obfuscate a certain amount of the SDK before it gets published, so that any code that should not be used by the user, can't be used (not reliably anyway).
The purpose of the consumer rules, on the other hand, are to ensure that any classes that need to be kept accessible under the original fully-qualified name, for reflection purposes, or android system loading purposes (e.g. Activity/Services etc)

It looks to me like the consumer rules were duplicated from our own R8 rules that run prior to publishing the public artifacts. This isn't correct, hence the unnecessary keep statements.
Since none of our code is loaded reflectively, or as a system component, in theory our consumer rules should be very small as the majority of it should be eligible for obfuscation/shrinking. But we'd need to do a proper review of each of the published libraries here to say for certain.

The link to #71 is certainly good to know about, but I expect that the underlying issue there was actually an Android bug not correctly recognizing that our code needs to be in the appropriate dex file. Don't quote me on that, I'd have to have a look into it a bit further to see if there were known issues.

The tealium-kotlin library was the replacement to this one, and we would tend to suggest migrating if it's possible, yes.

[ffournier]

Sorry I thought that you have just the consumer and not the proguard. But the lib is in copyright, so my guess was stupid.

The tealium-kotlin library was the replacement to this one, and we would tend to suggest migrating if it's possible, yes. -> Thanks :), We will do the migration so.

It looks to me like the consumer rules were duplicated from our own R8 rules that run prior to publishing the public artifacts. -> No, we have nothing on your side on this rules. I found the rules generated by the minify on the output /configuration.txt that you can found all rules that the R8 generated

So for me the rules that I found is provided by the library.

[jameskeith]

It looks to me like the consumer rules were duplicated from our own R8 rules that run prior to publishing the public artifacts. -> No, we have nothing on your side on this rules. I found the rules generated by the minify on the output /configuration.txt that you can found all rules that the R8 generated

Just to clarify, I meant it looks like we have mistakenly duplicated them at our end. It definitely looks like something for us to resolve on our side 👍