OkHttp (Okio) conflicts with /system/framework/okhttp.jar on Android L Preview

[luciofm]

E  Process: com.weheartit, PID: 4437
E  java.lang.NoSuchMethodError: No static method source(Ljava/io/File;)Lokio/Source; in class Lokio/Okio; or its super classes (declaration of 'okio.Okio' appears in /system/framework/okhttp.jar)
E      at com.squareup.okhttp.internal.DiskLruCache.readJournal(DiskLruCache.java:243)
E      at com.squareup.okhttp.internal.DiskLruCache.open(DiskLruCache.java:224)
E      at com.squareup.okhttp.Cache.<init>(Cache.java:146)
E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:74)
E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:51)
E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:41)
E      at com.squareup.picasso.Utils$OkHttpLoaderCreator.create(Utils.java:407)
E      at com.squareup.picasso.Utils.createDefaultDownloader(Utils.java:255)
E      at com.squareup.picasso.Picasso$Builder.build(Picasso.java:596)
E      at com.squareup.picasso.Picasso.with(Picasso.java:473)

[JakeWharton]

Are there log messages higher up with a VerifyError?
On Jun 26, 2014 1:22 PM, "Lucio Maciel" notifications@github.com wrote:

                E  Process: com.weheartit, PID: 4437
                E  java.lang.NoSuchMethodError: No static method source(Ljava/io/File;)Lokio/Source; in class Lokio/Okio; or its super classes (declaration of 'okio.Okio' ap
                   pears in /system/framework/okhttp.jar)
                E      at com.squareup.okhttp.internal.DiskLruCache.readJournal(DiskLruCache.java:243)
                E      at com.squareup.okhttp.internal.DiskLruCache.open(DiskLruCache.java:224)
                E      at com.squareup.okhttp.Cache.<init>(Cache.java:146)
                E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:74)
                E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:51)
                E      at com.squareup.picasso.OkHttpDownloader.<init>(OkHttpDownloader.java:41)
                E      at com.squareup.picasso.Utils$OkHttpLoaderCreator.create(Utils.java:407)
                E      at com.squareup.picasso.Utils.createDefaultDownloader(Utils.java:255)
                E      at com.squareup.picasso.Picasso$Builder.build(Picasso.java:596)
                E      at com.squareup.picasso.Picasso.with(Picasso.java:473)

—
Reply to this email directly or view it on GitHub
#967.

[swankjesse]

@nfuller Can you configure external/okhttp to jarjar the okio package? Thanks!

[felipecsl]

I just see this before the crash:
06-26 20:02:55.974 29234-29234/com.weheartit D/Picasso﹕ CREATING PICASSO - cache size: 38347922

[parallelcross]

I get a similar error with the L preview. I don't understand what @swankjesse means by "configure external/okhttp to jarjar the okio package", but I'd try it.

I'm including OkHttp and Okio by:

compile 'com.squareup.okhttp:okhttp:2.0.0'
compile 'com.squareup.okio:okio:1.0.0'

I get this stack trace.

java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:300)
at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
at java.util.concurrent.FutureTask.run(FutureTask.java:242)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
Caused by: java.lang.NoSuchMethodError: No static method source(Ljava/net/Socket;)Lokio/Source; in class Lokio/Okio; or its super classes (declaration of 'okio.Okio' appears in /system/framework/okhttp.jar)
at com.squareup.okhttp.internal.http.HttpConnection.(HttpConnection.java:89)
at com.squareup.okhttp.Connection.connect(Connection.java:153)
at com.squareup.okhttp.OkHttpClient$1.connect(OkHttpClient.java:84)
at com.squareup.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:321)
at com.squareup.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:241)
at com.squareup.okhttp.Call.getResponse(Call.java:198)
at com.squareup.okhttp.Call.execute(Call.java:80)

[parallelcross]

@swankjesse, not sure if I'm using jarjar in the way you instructed. I created a rules file:

rule okio okuhoh
rule okhttp okuhohhttp

I ran jarjar on okhttp and okio:

matt_wear$ java -jar jarjar-1.4.jar process jarjarRules okio-1.0.0.jar okuhoh.jar
matt_wear$ java -jar jarjar-1.4.jar process jarjarRules okhttp-2.0.0.jar okuhohhttp.jar

I included the output jars in my project, but same result.

[swankjesse]

@parallelcross I was trying to signal to our downstream maintainer in AOSP to use jarjar. If you want to use OkHttp on The L Release then you can either jarjar or proguard. Or wait till it's fixed.

[nfuller]

The android fix for this went into AOSP on May 28th. https://android-review.googlesource.com/#/c/96260/

It just missed the cut. I'll see what needs to happen, if anything, to get it into the next release.

Update: Yes - it will be automatically picked up in the next L release. Sorry for the inconvenience until then.

[nfuller]

[Deleted Emanuele Ricci's question by mistake. Apologies.]

Is there something we can do or can we just wait for the release of the update?

The error is because L preview has the okio classes in their original package (okio.*). This means they conflict with the classes being shipped in your APK. Since the ones that ship with the device are used in preference to ones in the APK it fails because the version of the classes you have is newer. In the L release they will be repackaged into com.android.okio (using jarjar).

@swankjesse mentioned two options:

1. You can repackage your copy of the okio code using jarjar yourself to avoid the conflict.

2. Proguard could be used to achieve similar things by renaming (or repackaging?) the okio classes in the APK, again so there is no conflict.

[StErMi]

@nfuller is there a working example for jarjar or proguard repackaging?

@parallelcross seems to have difficulties

[JakeWharton]

Should just be mapping okio.** to com.whatever.@1 with jarjar.

[parallelcross]

@StErMi Sorry, I didn't mean to post that as what works, just as, this is what I have, I've never used jarjar before and would like some help. Got it working though. Thanks.

[crossle]

retrofit.RetrofitError: Illegal class access: 'okio.Buffer' attempting to access 'okio.SegmentPool' (declaration of 'okio.Buffer' appears in) on Android L preview.

[bbergler]

I created a gradel build file which uses jarjar to map okio to a new namespace.
https://gist.github.com/bbergler/5f1b2219e4edcd1a836b

[realdadfish]

I repackaged okio 1.0.0 to com.squareup.okio and also provided a patched version of okhttp (2.0.0) here: https://github.com/tommyd3mdi/mvn

Source repos:

• https://github.com/tommyd3mdi/okio
• https://github.com/tommyd3mdi/okhttp

[dlleixap]

@tommyd3mdi Thanks for the patch man! Finally got rid of that Illegal class access error :)

[danielesegato]

@JakeWharton @swankjesse can you provide an OFFICIAL maven release with a patched version of okio / okhttp? (like the one from @tommyd3mdi ... but official)

I'm currently using the solution from @bbergler which create a patched version of the library but it has some drawback:

• you either commit the patched .jar file in your repo or you force whoever clones it to run applyPatch task before being able to commit
• no sources attached so you have no javadoc in the IDE
• not an option for libraries projects

Thanks

[JakeWharton]

No. It's fixed on Google's side already and the problem only occurs on
pre-release software.
On Jul 11, 2014 8:37 AM, "Daniele Segato" notifications@github.com wrote:

@JakeWharton https://github.com/JakeWharton @swankjesse
https://github.com/swankjesse can you provide an OFFICIAL maven release
with a patched version of okio / okhttp? (like the one from @tommyd3mdi
https://github.com/tommyd3mdi ... but official)

I'm currently using the solution from @bbergler
https://github.com/bbergler which create a patched version of the
library but it has some drawback:

• you either commit the patched .jar file in your repo or you force
  whoever clones it to run applyPatch task before being able to commit
• no sources attached so you have no javadoc in the IDE
• not an option for libraries projects

Thanks

—
Reply to this email directly or view it on GitHub
#967 (comment).

[JakeWharton]

Here's my version of a workaround which focuses on being no-frills and very straightforward: https://gist.github.com/JakeWharton/017738659d4f38adedc2.

[blazmag]

Thanks for the workaround, i've uploaded the repackaged latest version Okio, okHttp and okHttpUrlConnection to https://gist.github.com/blazmag/c661b6e1ebeb210b4e79 (for someone who's lazy like me and just needs jars)

[mxia]

Even though it's fixed on Google L side, think the square package should still be updated to com.squareup.okio like in the repackaged version to avoid any potential future conflict with another okio jar.

[JakeWharton]

We will not be updating the library.

[BoD]

Please forgive me to kind of hijacking this issue to ask a question, but... Is it expected (normal? documented?) that the classes of a system library have priority over the ones bundled inside an apk?
I am very surprised to see this behavior.
For instance, I always thought it was possible (hacky, but possible) to redefine components (e.g. ListView) in the "android" package when regular subclassing is not possible.

[briancarlstrom]

BoD, yes it is expected and normal and documented that system classes (from the parent class loader of the application) take priority over those from the app APK:

http://developer.android.com/reference/java/lang/ClassLoader.html
"Typically, class loaders are grouped into a tree where child class loaders delegate all requests to parent class loaders. Only if the parent class loader cannot satisfy the request, the child class loader itself tries to handle it."

[danielesegato]

@JakeWharton will okhttp be automatically picked up by Picasso using the "jarjar" solution?

and with the "fork" solution?
(which I think obtain the exact same effect of changing the classes package)

[JakeWharton]

Picasso looks for com.squareup.okhttp.OkHttpClient. If you have any doubts, just explicitly set the client and Downloader on Picasso to ensure OkHttp's use.

[danielesegato]

Thank you @JakeWharton I could have looked at the code, sorry for asking

[IanGClifton]

Looks like Google fixed it in the latest L images.

[JakeWharton]

Yes it was fixed long, long, long ago. We were just waiting for updated images or release which has now happened.

[JakeWharton]

Thanks for putting up with this and sorry for the inconvenience!

[petrLorenc]

I have the same issue again

 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime: FATAL EXCEPTION: main
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime: Process: cz.united121.rxandroid, PID: 9472
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime: java.lang.NoSuchMethodError: No static method createNetworkService(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object; in class Lcz/united121/rxandroid/model/network/NetworkService; or its super classes (declaration of 'cz.united121.rxandroid.model.network.NetworkService' appears in /data/app/cz.united121.rxandroid-1/base.apk)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at cz.united121.rxandroid.model.recyclerModel.RecyclerModel.updateDataToDatabase(RecyclerModel.java:35)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at cz.united121.rxandroid.presenter.recyclerPresenter.RecyclerPresenter.updateRecyclerViewClick(RecyclerPresenter.java:64)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at cz.united121.rxandroid.view.recyclerView.RecyclerFragment.onClickupdateRecyclerView(RecyclerFragment.java:74)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at cz.united121.rxandroid.view.recyclerView.RecyclerFragment$$ViewBinder$1.doClick(RecyclerFragment$$ViewBinder.java:22)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at butterknife.internal.DebouncingOnClickListener.onClick(DebouncingOnClickListener.java:22)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.view.View.performClick(View.java:4785)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.view.View$PerformClick.run(View.java:19884)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.os.Handler.handleCallback(Handler.java:739)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.os.Handler.dispatchMessage(Handler.java:95)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.os.Looper.loop(Looper.java:135)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at android.app.ActivityThread.main(ActivityThread.java:5343)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at java.lang.reflect.Method.invoke(Native Method)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at java.lang.reflect.Method.invoke(Method.java:372)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:905)
 10-25 23:27:26.610 9472-9472/cz.united121.rxandroid E/AndroidRuntime:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:700)

the line where a call createNetworkService

    NetworkService networkService = NetworkService.createNetworkService(NetworkService.class, NetworkService.TEST_ENDPOINT);

and function looks like this

public interface NetworkService {
static <T> T createNetworkService(final Class<T> tClass, final String endPoint) {
    Retrofit retrofit = new Retrofit.Builder()
            .addCallAdapterFactory(RxJavaCallAdapterFactory.create())
            .addConverterFactory(GsonConverterFactory.create())
            .baseUrl(endPoint)
            .build();
    T service = retrofit.create(tClass);
    return service;
}
....

It looks like the error from head page.

[swankjesse]

@petrLorenc: unrelated issue. Chances are you have a different version of a dependency at build time vs. runtime.

[saifamer2030]

Caused by: java.lang.ClassNotFoundException: Didn't find class "com.squareup.picasso.OkHttpDownloader" on path: DexPathList[[zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/base.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_dependencies_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_slice_0_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_slice_1_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_slice_2_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_slice_3_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1/split_lib_slice_4_apk.apk", zip file "/data/app/com.developersaifamer2030.friendsstatuspro-1

[GankLun]

[Deleted Emanuele Ricci's question by mistake. Apologies.]

Is there something we can do or can we just wait for the release of the update?

The error is because L preview has the okio classes in their original package (okio.*). This means they conflict with the classes being shipped in your APK. Since the ones that ship with the device are used in preference to ones in the APK it fails because the version of the classes you have is newer. In the L release they will be repackaged into com.android.okio (using jarjar).

@swankjesse mentioned two options:

1. You can repackage your copy of the okio code using jarjar yourself to avoid the conflict.
2. Proguard could be used to achieve similar things by renaming (or repackaging?) the okio classes in the APK, again so there is no conflict.

I can't agree any more about you because parent classloader is preference to classloader in apk ,but as you said, it fails because the version of the classes you have is newer. but how program knows which version is newer