I've updated from okhttp + retrofit to okhttp3 + retrofit2 but my app doesn't start cause of this Exception
FATAL EXCEPTION: EventThread
Process: appli.speaky.com, PID: 14705
java.lang.NoSuchMethodError: No virtual method setCallWebSocket(Lokhttp3/Call;)V in class Lokhttp3/internal/Internal; or its super classes (declaration of 'okhttp3.internal.Internal' appears in /data/data/appli.example.com/files/instant-run/dex/slice-okhttp-3.6.0_29bb10e5f590229716bfa8daf196d09ea67f56a8-classes.dex)
at okhttp3.ws.WebSocketCall.enqueue(WebSocketCall.java:108)
at io.socket.engineio.client.transports.WebSocket.doOpen(WebSocket.java:84)
at io.socket.engineio.client.Transport$1.run(Transport.java:82)
at io.socket.thread.EventThread.exec(EventThread.java:55)
at io.socket.engineio.client.Transport.open(Transport.java:77)
at io.socket.engineio.client.Socket.probe(Socket.java:472)
at io.socket.engineio.client.Socket.onOpen(Socket.java:485)
at io.socket.engineio.client.Socket.onHandshake(Socket.java:526)
at io.socket.engineio.client.Socket.onPacket(Socket.java:499)
at io.socket.engineio.client.Socket.access$1000(Socket.java:31)
at io.socket.engineio.client.Socket$5.call(Socket.java:313)
at io.socket.emitter.Emitter.emit(Emitter.java:117)
at io.socket.engineio.client.Transport.onPacket(Transport.java:134)
at io.socket.engineio.client.transports.Polling.access$700(Polling.java:17)
at io.socket.engineio.client.transports.Polling$2.call(Polling.java:124)
at io.socket.engineio.parser.Parser.decodePayload(Parser.java:251)
at io.socket.engineio.client.transports.Polling._onData(Polling.java:134)
at io.socket.engineio.client.transports.Polling.onData(Polling.java:106)
at io.socket.engineio.client.transports.PollingXHR$5$1.run(PollingXHR.java:111)
at io.socket.thread.EventThread$2.run(EventThread.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
I also had the same issue. The issue was I am using socket 0.8.0 which I think has conflict with OKHTTP websocket implem.
Upon upgrading to the latest version of socket.io
compile('io.socket:socket.io-client:0.8.3') {
exclude group: 'org.json', module: 'json'
}
and also using the latest version of OKHTTP (no need to include okhttp-ws)
compile "com.squareup.okhttp3:okhttp:3.7.0"
compile "com.squareup.okhttp3:logging-interceptor:3.7.0"
my app is not crashing upon first load and it is connecting to sockets. Interceptor also has no conflict whatsoever and is logging as expected on logcat.
With this, there is no need to downgrade your version of okHTTP for which it has been the working solution in the past. :)
Hi there，I have the same issue just days ago(my app is a react-native) ,I just use the 3.4.1 version to replace the latest，and solved it！
compile "com.squareup.okhttp3:okhttp:3.4.1"
compile "com.squareup.okhttp3:logging-interceptor:3.4.1"
and I guess it is caused by the Retrofit2's okhttp lib
I had this issue after launching the Android Studio Profiler, even after closing the profiler. Had to restart Android Studio to fix it.
I had similar issue. Problem with my project was it was using okhttp-3.3.1 which do not have method setCallWebSocket.
Make sure you add correct version of okhttp in your gradle and the older version which does not have setCallWebSocket are not included elsewhere under your project libraries or dependencies.
Related
We are currently facing this NoSuchMethod Error when we want to create the unit test with Robolectric version 4.3.1 and Mockito version 2.18.3
Exceptions:
java.lang.NoSuchMethodError: 'void com.android.webview.chromium.WebViewChromium.<init>(com.android.webview.chromium.WebViewChromiumFactoryProvider, android.webkit.WebView, android.webkit.WebView$PrivateAccess, boolean)'
Here is the code we did:
mWebView = Mockito.spy(
new WebviewChromium(
mockWebViewChromiumProvider, webView, webView.new PrivateAccess(), false));
In BUILD.gn, we have included the "//android_webview/glue:glue_java" as dependency, we can successfully compile the code but it sounds like in the runtime, it refers to the another wrong jar, does someone know how to config the build file to use the correct jar or any ideas about how to solve this error?
did you check this followjng thread https://github.com/robolectric/robolectric/issues/5092 and this one I think you need open jdk 11 or 13 I recently had the same issue after adding open jdk 13 to android studio it solved my problem robolectric started working fine you can check following thread as well https://github.com/robolectric/robolectric/issues/5092
Recently I have upgraded the Guava library to 28.2-jre (implementation com.google.guava:guava:28.2-jre) after that I cannot use CacheBuilder to create database cache. Previously it was working fine with older library. Any idea?. Crash logs are below.
--------- beginning of crash
java.lang.NoClassDefFoundError: com.google.common.base.Suppliers$SupplierOfInstance
at com.google.common.base.Suppliers.ofInstance(Suppliers.java:268)
at com.google.common.cache.CacheBuilder.<clinit>(CacheBuilder.java:168)
at com.trimble.ag.amaethon.equipment.provider.pub.client.EquipmentClientImplementCache.<init>(EquipmentClientImplementCache.java:65)
at com.trimble.ag.amaethon.equipment.provider.pub.client.EquipmentClient.<init>(EquipmentClient.java:340)
at com.trimble.ag.amaethon.equipment.provider.pub.client.EquipmentClient.<init>(EquipmentClient.java:286)
at com.trimble.sns.equipment.provider.client.EquipmentClient.<init>(EquipmentClient.java:50)
at com.trimble.sns.equipment.provider.client.EquipmentClient.getInstance(EquipmentClient.java:60)
at com.trimble.sns.DurangoApplication.onCreate(DurangoApplication.java:45)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1013)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4712)
Based on your stacktrace you're on Android, so please use different artefact: guava-28.2-android.
More about using Guava on Android on this Wiki page.
I'm getting the following crashing during an instrumentation test ONLY on emulators running API v19. If I run on newer versions everything works fine.
03-01 20:26:18.781 2878-2878/? E/MonitoringInstrumentation: Exception
encountered by: Thread[main,5,main]. Dumping thread state to outputs
and pining for the fjords.
java.lang.NoClassDefFoundError: org.objenesis.ObjenesisStd
at org.mockito.internal.creation.jmock.ClassImposterizer.(ClassImposterizer.java:36)
at org.mockito.internal.creation.jmock.ClassImposterizer.(ClassImposterizer.java:29)
at org.mockito.internal.util.MockCreationValidator.isTypeMockable(MockCreationValidator.java:17)
at org.mockito.internal.util.MockCreationValidator.validateType(MockCreationValidator.java:21)
at org.mockito.internal.creation.MockSettingsImpl.validatedSettings(MockSettingsImpl.java:133)
at org.mockito.internal.creation.MockSettingsImpl.confirm(MockSettingsImpl.java:127)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:50)
at org.mockito.Mockito.mock(Mockito.java:1243)
at org.mockito.Mockito.mock(Mockito.java:1120)
The problem is this line:
java.lang.NoClassDefFoundError: org.objenesis.ObjenesisStd
My app is multi-dex, and I'm using dexmaker-mockito for androidTestCompile. I'm at a complete loss why this only breaks on an older API. It started happening when I added another module to my project, which is a pure java module with no dependency on mockito.
This exception (ClassNotFoundException) tells you about a unmet dependency at runtime: the JVM needs to load a class; which is not present in the class path.
Here it is Mockito that needs Objenesis. Normally that library should be pulled automatically when you a system like maven and give the correct dependency to Mockito.
Seeing the following stack on old versions of Android (4.3 and earlier):
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)
This seems to suggest an incompatibility between okhttp and Java 6, where java.net.Socket doesn't implement Closeable.
And the problem appears to occur primarily as a result of a failed stream. It was difficult to reproduce until we started calling this php page (borrowed from https://stackoverflow.com/a/141026/315702), which forces a stream failure on the client side:
<?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');
?>
This appears to be a bug with the current okhttp 3.6.0-SNAPSHOT build. I filed a bug report on the okhttp github site. The exception is thrown when the connection closes unexpectedly. [Update: the bug was quickly fixed by replacing Closeable with Socket for backward compatibility with Java 6 in this pull request.]
In our case, the real heart of the problem was that we didn't mean to use okhttp 3.6.0-SNAPSHOT in the first place. In our build.gradle, we specified 3.4.1. It turned out one of our third-party libraries had a dependency on okhttp:+, which we discovered via the following gradle command:
./gradlew -q :app:dependencyInsight --dependency okhttp --configuration compile
Because of this, we were pulling in whatever happens to be the latest version of okhttp. In our case, the culprit library was the okhttp extension to exoplayer. By excluding the unwanted module dependency on okhttp:+, we were able to avoid loading 3.6.0-SNAPSHOT:
compile('com.google.android.exoplayer:extension-okhttp:r2.0.4') {
exclude module: 'okhttp'
}
I'm using google's grpc library in my android app which relies on the google guava library. For some reason the guava embedded in grpc doesn't have 'directExecutor' method in the class MoreExecutors. But the method is present in the github version? What accounts for the discrepancy?
In a class called ClientCallImpl is where the call to directExecutor is made. On the import statement(import static com.google.common.util.concurrent.MoreExecutors.directExecutor;) AndroidStudio shows a can't resolve symbol message, but the build doesn't fail. The exception is raised when the call is made during execution.
Error Message
FATAL EXCEPTION: SyncAdapterThread-1
Process: com.asdf.asdf, PID: 4025
java.lang.NoSuchMethodError: No static method directExecutor()Ljava/util/concurrent/Executor; in class Lcom/google/common/util/concurrent/MoreExecutors; or its super classes (declaration of 'com.google.common.util.concurrent.MoreExecutors' appears in /data/data/com.fentale.dalol/files/instant-run/dex/slice-guava-jdk5-17.0_a8ada10dcaf113cb6e3b4d3e5b46975833f8ae8f-classes.dex)
at io.grpc.internal.ClientCallImpl.<init>(ClientCallImpl.java:100)
at io.grpc.internal.ManagedChannelImpl$RealChannel.newCall(ManagedChannelImpl.java:320)
at io.grpc.internal.ManagedChannelImpl.newCall(ManagedChannelImpl.java:299)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:130)
at com.fentale.dalol.nano.DalolGrpc$DalolBlockingStub.topPosts(DalolGrpc.java:365)
EDIT
It seems the problem is that my project has dependencies on both guava-18.0 and guava-jdk5-17.0. The method I want directExecutor is only defined in the MoreExecutors class of guava-18, not 17. But the code is looking for it in the latter version of the class. How can I resolve this.
My app had a dependency on the youtube library which inturn depended on guava. However youtube's guava dependency is from a different source than grpc's and using an older version. Two versions of the guava jar existed in the app and grpc was accessing youtube's older guava version rather than its own, which caused the problem.
compile('com.google.apis:google-api-services-youtube:v3-rev164-1.21.0') {
exclude module: 'guava-jdk5'
}