Okhttp: KotlinNullPointerException on any network request on old Android 5 phone with new okhttp-logging-interceptor 4.0.0+

Created on 11 Jul 2019  路  1Comment  路  Source: square/okhttp

After upgrading from com.squareup.okhttp3:logging-interceptor 3.14.1 to 4.0.0 (or 4.0.1), with no other code changes, I am getting a KotlinNullPointerException on any network request, when our app installed on HTC One with Android 5.0.2. I am unsure of which other devices also have this issue. It also crashes even if I remove all calls to addInterceptor.

It crashes because cipherSuites is null in the ConnectionSpec. cipherSuites is null in the connection spec because the code I was using to enable TLS 1.2 on API 21 was calling .allEnabledCipherSuites() on the ConnectionSpec.Builder. As far as I can tell, all that allEnabledCipherSuites does is set the cipherSuites to null.

Is this the expected behavior? Do should I be calling allEnabledCipherSuites() or not?

E/AndroidRuntime_2_crash: crash in the same process: OkHttp Dispatcher
    kotlin.KotlinNullPointerException
        at okhttp3.ConnectionSpec.hashCode(ConnectionSpec.kt:186)
        at java.util.ArrayList.hashCode(ArrayList.java:603)
        at java.util.Collections$UnmodifiableList.hashCode(Collections.java:1054)
        at okhttp3.Address.hashCode(Address.kt:178)
        at okhttp3.Route.hashCode(Route.kt:84)
        at java.util.Collections.secondaryHash(Collections.java:3405)
        at java.util.HashMap.containsKey(HashMap.java:325)
        at java.util.HashSet.contains(HashSet.java:138)
        at okhttp3.internal.connection.RouteDatabase.shouldPostpone(RouteDatabase.kt:40)
        at okhttp3.internal.connection.RouteSelector.next(RouteSelector.kt:74)
        at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:199)
        at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:109)
        at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:77)
        at okhttp3.internal.connection.Transmitter.newExchange$okhttp(Transmitter.kt:162)
        at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:35)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
        at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:82)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
        at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:84)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
        at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:71)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
        at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
        at okhttp3.RealCall$AsyncCall.run(RealCall.kt:136)
        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)
bug

Most helpful comment

Looks like a bug in OkHttp 4.0.1, we shouldn鈥檛 be asserting non-null.

Can fix!

>All comments

Looks like a bug in OkHttp 4.0.1, we shouldn鈥檛 be asserting non-null.

Can fix!

Was this page helpful?
0 / 5 - 0 ratings