Closed
Description
According to the 3.8.0 CHANGELOG: "We've added a compile-time dependency on the JSR 305 annotations. This is a provided dependency and does not need to be included in your build configuration…"
However, ProGuard brings a lot of messages like this:
okhttp3.Address: can't find referenced class javax.annotation.Nullable
…
This can be worked around by adding jsr305 to the gradle configuration:
compile 'com.google.code.findbugs:jsr305:3.0.2'
However, according to the docs, this should be done by okhttp dependencies.
Activity
vanniktech commentedon May 14, 2017
Have a look at - #3354
rfc2822 commentedon May 14, 2017
Thanks
imattaullah commentedon Oct 26, 2017
it looks like minifyEnabled is set to true in your build.gradle so it is applying proguard rules. so you should add this rules to your proguard-rules.pro file
-dontwarn okio.**
-dontwarn com.squareup.okhttp3.**
-keep class com.squareup.okhttp3.** { ; }
-keep interface com.squareup.okhttp3.* { *; }
-dontwarn javax.annotation.Nullable
-dontwarn javax.annotation.ParametersAreNonnullByDefault
JakeWharton commentedon Oct 26, 2017
minchoikolev commentedon Feb 15, 2018
@attaullahpro was almost right...
Correct one:
-dontwarn okio.**
-dontwarn com.squareup.okhttp3.**
-keep class com.squareup.okhttp3.** { *; }
-keep interface com.squareup.okhttp3.** { *; }
-dontwarn javax.annotation.Nullable
-dontwarn javax.annotation.ParametersAreNonnullByDefault
JakeWharton commentedon Feb 15, 2018
AbandonedCart commentedon Mar 5, 2018
@JakeWharton I am sure you are aware that the side effect of having a popular library is that many other projects will utilize it. The side effect of offering a complete solution is that has a greater contribution to larger file size. The end result is a small portion of a larger library being used in a project that will then require tools, such as minifyEnabled, to compensate for the size increase.
I am using the parse-community replacement for Parse services and their library has introduced these errors. I am not using okhttp directly and cannot expect to have the changes to resolve this issue posted to a maven or jcenter repository immediately. It also seems absurd to recompile the entire library locally simply to bypass a warning that has no impact on the final output.
What rules would you suggest, even as a temporary solution? I appreciate pointing out that the library may not be an official version of okhttp or that the suggested rules are not relevant, but neither of these statements actually benefits those of us trying to resolve the issue.
cketti commentedon Mar 5, 2018
https://github.com/square/okhttp#proguard
AbandonedCart commentedon Mar 5, 2018
@cketti I directed my question @JakeWharton because of the comment that "you're better off turning off ProGuard than doing such an overly-keepy rule" that contradicts the documentation's own "overly-keepy" rules, such as
-dontwarn javax.annotation.**
I assume I can take that as just one contributor's personal opinion. Thanks.
JakeWharton commentedon Mar 5, 2018
AbandonedCart commentedon Mar 5, 2018
@JakeWharton Thanks for the input. I am sure you have good intentions, but your vague input on the matter has led me to favor the solutions others have posted.
kyawzinhtun commentedon Jul 26, 2018
I also face this problem. And I can fix by adding below rules in proguard
-dontwarn okio.**
-dontwarn okhttp3.**
JakeWharton commentedon Jul 26, 2018