2017-01-20 3 views
2

のAndroid(4.3以前)の旧バージョンで、次のスタックを見て:okhttp3.internal.Util.closeQuietlyからでIncompatibleClassChangeError()

Caused by: java.lang.IncompatibleClassChangeError: interface not implemented 
at okhttp3.internal.Util.closeQuietly(Util.java:100) 
at okhttp3.internal.connection.StreamAllocation.streamFailed(StreamAllocation.java:332) 
at okhttp3.internal.http.RetryAndFollowUpInterceptor.recover(RetryAndFollowUpInterceptor.java:209) 
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:132) 
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92) 
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67) 
at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:212) 
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92) 
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67) 
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:179) 
at okhttp3.RealCall.execute(RealCall.java:63) 

これはどこjava.net.Socket、okhttpとJava 6の間の非互換性を示唆しているようですCloseableを実装していません。

この問題は、主にストリームが失敗したために発生しているようです。私たちは、クライアント側での流れの障害を強制的に(https://stackoverflow.com/a/141026/315702から借りた)このPHPページを呼び出し開始までは再現が困難であった:

<?php 
ob_end_clean(); 
header("Connection: close"); 
ignore_user_abort(true); // just to be safe 
ob_start(); 
echo('Text the user will see'); 
$size = ob_get_length(); 
header("Content-Length: $size"); 
ob_end_flush(); // Strange behaviour, will not work 
flush(); // Unless both are called ! 
sleep(30); 
echo('Text user will never see'); 
?> 

答えて

2

これは、現在のokhttp 3.6.0-SNAPSHOTとバグのように見えますビルド。私はokhttp githubサイトにbug reportを提出しました。接続が予期せず終了すると、例外がスローされます。 [アップデート:CloseableをSocketに置き換えてバグを修正しました。これはJava 6との下位互換性のためにこのpull requestにあります。

ここでは、okhttp 3.6を使用するという意味ではありませんでした。 0-SNAPSHOTを最初に置きます。 build.gradleでは、3.4.1を指定しました。私たちは、最新であることを起こるものは何でもで引っ張った、このため

./gradlew -q :app:dependencyInsight --dependency okhttp --configuration compile

:+、我々は次のGradleのコマンドを経由して発見された:それは私たちのサードパーティのライブラリのいずれかがokhttpに依存していたが判明しましたokhttpのバージョン私たちの場合、犯人ライブラリーはexoplayerへのokhttp拡張でした。 okhttp上の不要なモジュールの依存関係を除外することによって:彼らは `+` `r2.1.1`の時間によって使用停止のように見える、

compile('com.google.android.exoplayer:extension-okhttp:r2.0.4') { 
    exclude module: 'okhttp' 
} 
+2

FWIW:+、我々はロードに3.6.0-SNAPSHOTを避けることができました。ところで、良い分析! – CommonsWare

+0

いくつかの開発者の集合IQがこの1つの底に到達するまでにかかりました。そして、ありがとう - 私は '+'依存関係が修正されたかどうかをチェックしようとしていました! – markproxy

+2

ここに固定:https://github.com/square/okhttp/pull/3125 –

関連する問題