AppSetId Proguard Rules

[darnmason]

Summary

This is not exactly an Amplitude issue, however I think it could be touched on in the documentation, especially as it would be expected that the instructions to add the appset dependency, and not reference it, would result in R8 stripping it from the final build or obfuscating the class and member names that Amplitude depends on.

I've attempted to add proguard rules such as the following with no luck:

-keep class com.google.android.gms.appset.**
-keep class com.google.android.gms.tasks.**

It would be great if the Amplitude SDK provided the necessary rules as consumer-rules.pro bundled with the library so that application developers don't need to reverse engineer the code to see what it needs to access through reflection.

This could incorporate the ProGuard -if option so that consumers that don't use app set ID do not get any warnings.

[darnmason]

This is the use of reflection I'm referring to: https://github.com/amplitude/Amplitude-Kotlin/blob/main/common-android/src/main/java/com/amplitude/common/android/AndroidContextProvider.kt#L220

[darnmason]

If someone comes across this I was missing the members, so this works as a pretty blunt tool:

-keep class com.google.android.gms.appset.** { *; }
-keep class com.google.android.gms.tasks.** { *; }

[darnmason]

These are the proguard rules I landed on:

-keep class com.google.android.gms.appset.AppSet {
  public getClient(android.content.Context);
}
-keep class com.google.android.gms.appset.AppSetIdClient {
  public getAppSetIdInfo();
}
-keep class com.google.android.gms.appset.AppSetIdInfo {
  public getId();
}
-keep class com.google.android.gms.tasks.Tasks {
  public await(com.google.android.gms.tasks.Task);
}
-keep class com.google.android.gms.tasks.Task