Missing classes dectected while running R8 about tink

[tholenst]

I see, thank you.

I will have to contact this team then. Did you already file an issue for androidx.security? If so, I will reuse that.

Also, did you try different versions of androidx.security? If so, what was the result?

[tholenst]

You may be able to test it if you tell gradle explicitly that you need at least Tink 1.9. I don't know Gradle at all, so I cannot help you with how to do that.

But basically, if you can say explicitly that you need com.google.crypto.tink:tink-android:1.9.0 the issue should go away.

I filed an issue in the Google internal bug tracker, I hope that they can soon upgrade androidx.security:security-crypto:1.1.0-alpha06. I didn't find a public component for this.

Please wait a week and then Ping this issue if there is no new release.

[GuilhE]

I filed an issue in the Google internal bug tracker, I hope that they can soon upgrade androidx.security:security-crypto:1.1.0-alpha06. I didn't find a public component for this.

Thanks, I was indeed trying to find on Google Issue Tracker but I couldn't also, only for generic AndroidX.

You may be able to test it if you tell gradle explicitly that you need at least Tink 1.9. I don't know Gradle at all, so I cannot help you with how to do that.

But basically, if you can say explicitly that you need com.google.crypto.tink:tink-android:1.9.0 the issue should go away.

This makes a lot of sense, and the way to do that is by doing the following:

implementation("androidx.security:security-crypto:1.1.0-alpha06") {
     exclude(group = "com.google.crypto.tink", module = "tink-android")
}
implementation("com.google.crypto.tink:tink-android:1.9.0")

And it works 🥳

But now I end up again with the runtime error which made me think it was a false positive. A bit of research and I found that either way I need to add the following rules:

# Keep generic signature of Call, Response (R8 full mode strips signatures from non-kept items).
-keep,allowobfuscation,allowshrinking interface retrofit2.Call
-keep,allowobfuscation,allowshrinking class retrofit2.Response

# With R8 full mode generic signatures are stripped for classes that are not
# kept. Suspend functions are wrapped in continuations where the type argument
# is used.
-keep,allowobfuscation,allowshrinking class kotlin.coroutines.Continuation

This leaves me with 2 solutions:

• With the new rules, add the following and leave the dependency as is:

-dontwarn com.google.api.client.http.**
-dontwarn org.joda.time.**

• With the new rules, exclude the dependency on 1.8.0 and force 1.9.0

Which do you think is the cleanest/safest? I prefer the second because as soon as the security-crypto uses officially the 1.9.0 I just need to remove the gradle configuration. Having the 2 new rules added sounds like code smell 😅

[tholenst]

Can you expand on the runtime error? A stacktrace would be helpful.

Please do try to use 1.9.0 -- in the end, we do fix a problem with 1.9.0 over 1.8.0, and if there is another problem we need to debug that one too. We will upgrade to 1.9.0 anyhow, and if it doesn't work then you cannot avoid it in the medium term.

[tholenst]

Hey, thanks for the report.

What version of Tink do you use?

In general, the dependencies referenced (http-client and joda-time) are needed for the class com.google.crypto.tink.util.KeysDownloader -- and we didn't list them in early versions of Tink. We later added them, but they really shouldn't be there: unless you use exactly KeysDownloader directly, Tink doesn't need them.

Are you using tink-android? They shouldn't be there.

[GuilhE]

I'm not using Tink directly, only via androidx.security:security-crypto:1.1.0-alpha06

[morambro]

androidx.security:security-crypto:1.1.0-alpha06 depends on com.google.crypto.tink:tink-android:1.8.0 (source) which doesn't explicitly depend on http-client (source). I am not very familiar with R8, but if IIUC adding -dontwarn com.google.api.client.http.* and -dontwarn org.joda.time.* to theproguard-rules.pro file (https://developer.android.com/build/shrink-code#configuration-files) should solve the issue.

[tholenst]

Oh I see. And somehow in 1.8 we included the keys downloader by mistake :(

https://github.com/tink-crypto/tink-java/blob/1.8/BUILD.bazel#L696-L699

This should be fixed with 1.9 though: https://github.com/tink-crypto/tink-java/blob/1.9/BUILD.bazel#L780-L782

So what remains to do is for someone to try to see if androidx.security:security-crypto can update to 1.9

[GuilhE]

androidx.security:security-crypto:1.1.0-alpha06 depends on com.google.crypto.tink:tink-android:1.8.0 (source) which doesn't explicitly depend on http-client (source). I am not very familiar with R8, but if IIUC adding -dontwarn com.google.api.client.http.* and -dontwarn org.joda.time.* to theproguard-rules.pro file (https://developer.android.com/build/shrink-code#configuration-files) should solve the issue.

This doesn't work, by adding:

-dontwarn com.google.api.client.http.**
-dontwarn org.joda.time.**

The build will succeed (because it mutes the warnings/errors) but then it will fail in runtime:

java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType at retrofit2.HttpServiceMethod.parseAnnotations(HttpServiceMethod.java:46) at retrofit2.ServiceMethod.parseAnnotations(ServiceMethod.java:39)
at retrofit2.Retrofit.loadServiceMethod(Retrofit.java:202)
at retrofit2.Retrofit$1.invoke(Retrofit.java:160)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at $Proxy3.login(Unknown Source)
...

I'm using EncryptedSharedPreferences to store some credentials.

Oh I see. And somehow in 1.8 we included the keys downloader by mistake :(

https://github.com/tink-crypto/tink-java/blob/1.8/BUILD.bazel#L696-L699

This should be fixed with 1.9 though: https://github.com/tink-crypto/tink-java/blob/1.9/BUILD.bazel#L780-L782

So what remains to do is for someone to try to see if androidx.security:security-crypto can update to 1.9

Is it something I can test on my end?

I will have to contact this team then. Did you already file an issue for androidx.security? If so, I will reuse that.

I have not, I'll so you can reuse 😉

[GuilhE]

The runtime error was a false positive towards Tink, the stacktrace was relative to coroutines and retrofit, thus the 3 proguard rules that also saved the day 🙏🏼

[tholenst]

I will mark this as finished as you said it was a false positive. I will also do another release as in Java Tink 1.9.0 still has some problems with regard to this class. However, if anyone has still issues with this, please comment here or open a new issue in https://github.com/tink-crypto/tink-java