Open darnmason opened 3 months ago
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
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.** { *; }
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
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:
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.