This question already has answers here:
Java.lang.verifyerror how do I fix or even find out the root cause?
(4 answers)
Closed 9 years ago.
Hello I get this error every time I'm trying to open an activity
java.lang.VerifyError: com.karriapps.smartsiddur.Saharit
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1429)
at android.app.Instrumentation.newActivity(Instrumentation.java:1021)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2577)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2679)
at android.app.ActivityThread.access$2300(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2033)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
at dalvik.system.NativeStart.main(Native Method)
Can someone direct me to a solution or a way to check where the problem is coming from
thanks
A VerifyError means your compiled bytecode is referring to something that Android cannot find. In this case, it would appear that you have a reference to a com.karriapps.smartsiddur.Saharit class that Android cannot find.
As CommonsWare mentioned, a VerifyError means that you're trying to reference a class that Dalvik isn't able to load.
It's possible that this class is missing.
It's also possible that you're trying to use framework methods for an API level greater than what's present on the device, and therefore the class is being rejected as invalid.
Try setting your compiler's build level to API Level 7, which corresponds to Android 2.1. (Don't forget to set your AndroidManfest.xml's targetSdkVersion to "7" as well.) This will cause any framework calls that don't exist to raise a compiler error.
You also might want to look at the lines above/below the stack trace you received to see if there's any additional information from the verifier indicating why verification failed.
I found an interesting case that has evidence in runtime. I use:
<uses-sdk
android:minSdkVersion="9"
android:targetSdkVersion="18" />
So some of new Android 4 capabilities are not implenented in Android 2.3 like this one:
imageView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Ok I can manage it so runtime will not execute it, simply:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}
This works well but what about Exception handling?
} catch (NetworkOnMainThreadException nomte) {
// log this exception
} catch (SocketTimeoutException socketTimeoutException) {
// log this exception
}
NetworkOnMainThreadException is not implemented in Android 2.3 so when the class is loaded the exception java.lang.VerifyError occurs.
I ran across this problem today and as CommonsWare mentioned, the issue is that my compiled bytecode was referring to something that no longer existed. But what should you do about it?
Since I'm using Eclipse SDK the simple solution for me was to perform an Eclipse's Project → Clean to remove the pre-compiled byte code in my project that was causing the problem. The Project clean put simply allowed eclipse to perform a full fresh rebuild of my project after the clean.
Related
Guys I am getting the below error in RunTime, what is the root cause of this error?
java.lang.VerifyError: appPackageName at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1130)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:2698)
at android.app.ActivityThread.access$1900(ActivityThread.java:148)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1413)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5457)
at java.lang.reflect.Method.invokeNative(Native Method)
You are probably using or accessing something which is simply supported in higher android SDK, as the error shows here java.lang.Class.newInstanceImpl(Native Method).
I happened to have the same kind of VerifyError while I was using String.isEmplty();. It seems you have same kind of problem as the message showing error in java.lang.Class
Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.
Here is official docs
Possible causes:
You might have imported something which is using different support v4/v7 library version.
You are targeting something from a higher SDK version. In that case, update your support repository and SDK build version.
Thanks everyone for your support and answers, may be your answers are right but in my case I used extra variables in one method while I was testing, so this exception appeared. Now I get rid of redundant things in my code and it start working. It may help others.
I am actually working on an Android VOIP application that let user create conference with other users. My constraints are to avoid any use of a server like SIP servers to realise it and if I have to use a external library, it should be under LGPL license. I have succesfully done it in a peer-to-peer fashion using the AudioGroup and AudioStream classes of the android RTP stack.
My problem occurs in a 3-peers conference. Using AudioGroup, I have enabled the MODE_ECHO_SUPPRESSION but the results are very poor and I can hear my echo after 3 seconds. I came to conclusion that the Android RTP stack was not a good solution to my problem beacause using AudioGroup make impossible to tweek the sound and echo suppression seems to function badly.
By testing VOIP applications, I discovered a lot that were working pretty weel and more precisely Jitsi (homepage) which use a java library based on native code for the RTP stuff under the LGPL licence. I tried to follow this tutorial to use libjitsi but unfortunatly it gives me an error... At this time, I'm not sure that it is possible to use Libjitsi on an android project as it is normally used in Java projects.
Steps I went trough to get the error (using Android Studio)
I have compiled libjitsi from the build.xml contained in the sources and putted the resulting jar directly in the lib/ folder of my project.
I have added a dependency to libjitsi.jar in my build.gradle file
Called the static method Libjitsi.start() in the onCreate method of an activity
Error log
01-02 17:06:48.304 1523-1523/com.test.example I/LibJitsi﹕
Failed to initialize LibJitsi backend
org.jitsi.impl.libjitsi.LibJitsiOSGiImpl. (Exception stack trace
follows.) Will try an alternative.
java.lang.NoClassDefFoundError: org.osgi.framework.FrameworkUtil
at org.jitsi.impl.libjitsi.LibJitsiOSGiImpl.(LibJitsiOSGiImpl.java:34)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1319)
at org.jitsi.service.libjitsi.LibJitsi.start(LibJitsi.java:227)
at org.jitsi.service.libjitsi.LibJitsi.start(LibJitsi.java:171)
at com.test.example.ui.createconf.CreateConfActivity.onCreate(CreateConfActivity.java:76)
at android.app.Activity.performCreate(Activity.java:4465)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1049)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1931)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1992)
at android.app.ActivityThread.access$600(ActivityThread.java:127)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1158)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4441)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native
Now if anyone already tried to use libjitsi on an AndroidProject or if you know it's not feasible, I would really be gratefull if you share your experience with me.
Thanks
Yes libjitsi dependency can be added to android, you can try jitsi-android which is an Android port of the Jitsi project . I have tried to run their sample app and it compiled fine.
However , I have shared 5 different libraries for VOIP calling on android in another answer you can have a look and try them.
Njoy!
Background
Recently I've updated my app, and for some reason Proguard seem to ruin the code I've made, causing crashes on a very specific case, even though I didn't add any additional libraries.
The reason I'm so sure it's Proguard's fault is that when I tested it without exporting it, it ran fine.
The problem
After seeing the crash reports' stack traces (and seeing that it does occur, by myself), I've ran the "proguardgui" tool and chose to retrace using the mapping file.
Sadly, instead of showing the real places that the code failed, it showed the exact same stack. I've tried to export the project again and use a new mapping file that was created by it, but I still get the same obfuscated stack trace.
Not only that, but the exception itself is very problematic: java.lang.NoClassDefFoundError .
Here's the stack trace, though I don't think it's readable:
java.lang.NoClassDefFoundError: com.lb.app_manager.utils.r
at com.lb.app_manager.utils.e.c(Unknown Source)
at com.lb.app_manager.activities.app_list_activity.AppListActivity.onContextItemSelected(Unknown Source)
at android.app.Activity.onMenuItemSelected(Activity.java:2620)
at android.support.v4.app.FragmentActivity.onMenuItemSelected(Unknown Source)
at com.actionbarsherlock.app.SherlockFragmentActivity.onMenuItemSelected(Unknown Source)
at com.android.internal.policy.impl.PhoneWindow$DialogMenuCallback.onMenuItemSelected(PhoneWindow.java:3864)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:735)
at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:152)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:874)
at com.android.internal.view.menu.MenuDialogHelper.onClick(MenuDialogHelper.java:167)
at com.android.internal.app.AlertController$AlertParams$3.onItemClick(AlertController.java:941)
at android.widget.AdapterView.performItemClick(AdapterView.java:299)
at android.widget.AbsListView.performItemClick(AbsListView.java:1113)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:2904)
at android.widget.AbsListView$3.run(AbsListView.java:3638)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5017)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:133)
at dalvik.system.NativeStart.main(Native Method)
This occurs when I choose to share an app, which, for a very short time should show a progress dialog while running an AsyncTask, and then show a dialog of how you wish to share (just like on the screenshot of the play store link, available here in case you can't see it ).
What I've tried
I've tried to add logs in multiple places, and found out that the AsyncTask runs fine, but it doesn't reach "onPostExecute". I know this since I've put log at the end of "doInBackground" and at the beginning of "onPostExecute" .
This got even weirder, when I removed most of the code of "onPostExecute" and now I have only this:
protected void onPostExecute(final Void result)
{
Log.d("Applog","onPostExecute 0");
super.onPostExecute(result);
Log.d("Applog","onPostExecute 1");
progressDialog.dismiss();
}
It doesn't even reach the first line this way.
In the end, I've decided to merge 2 projects (that I made several versions ago), so that there won't be any Android library project that I made. Only a single one.
I've also removed a library that appears not being used (of Apache commons), but I can't believe this is the cause to the problem (because I didn't use it).
The question
Why do such problems occur?
How can I avoid such a problem in the future?
A NoClassDefFoundError generally points to a problem in the build process: some class that is required doesn't end up in your application.
ProGuard prints out information in the build log about the input jars that it reads and the output jars that it writes. You can also specify
-printconfiguration configuration.txt
to get the complete configuration that ProGuard uses, including input and output. This should help you to find out if all expected input jars are present.
If you are using Eclipse to build your application, you may have run into a synchronization problem that seems to run ProGuard when not all compiled files have been written to disk yet. This mysterious problem has been reported a few times, but it is still unsolved. You should then try Ant or Gradle instead.
We recently introduced OAuth login in our app. This means using a WebView to authenticate the user, and an AsyncTask to do necessary REST calls afterwards.
Unfortunately, after introducing this login method, we're getting reports of the app force closing. This seems to be related to other AsyncTasks that are executed after the login, but the stack traces does unfortunately not tell us much:
java.lang.IllegalStateException: Could not execute method of the activity
at android.view.View$1.onClick(View.java:3100)
at android.view.View.performClick(View.java:3627)
at android.view.View$PerformClick.run(View.java:14329)
at android.os.Handler.handleCallback(Handler.java:605)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4511)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:980)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:747)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at android.view.View$1.onClick(View.java:3095)
... 11 more
Caused by: java.lang.NoClassDefFoundError: android/os/AsyncTask
at com.foo.bar.TransmissionActivity.transmit(TransmissionActivity.java:44)
... 14 more
We managed to fix the error above by using RoboAsyncTask (from RoboGuice), instead of AsyncTask from the Android SDK, but we have other activities that use WebViews. WebView apparently uses AsyncTask somewhere in its call stack, and errors similar the one shown above (Caused by: java.lang.NoClassDefFoundError: android/os/AsyncTask) have started to show in our error logs.
The error happens on different devices, and different Android versions, with no apparent pattern. We have tried to reproduce the error ourselves, without any luck.
Any ideas?
It might be an issue with the build setup. (Build order of src/gen has been known to cause some issues, the libs folder for the compat library being called lib has caused some issues for me on new sdk versions).
To see if it is create a new project (in eclipse, since that's 100% android official). Add a webview and an asynctask and then do a diff on the project with your project. Ignoring src/gen/res. Hopefully you'll find that the src/gen are built in the wrong order or something like that.
~ Anders
Upgrading to ndk 8b I receiving some crash report (most of them are Galaxy SII with Android 4.03)
java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1286]: 1836 cannot locate '__gnu_thumb1_case_uqi'...
at java.lang.Runtime.loadLibrary(Runtime.java:370)
at java.lang.System.loadLibrary(System.java:535)
at com.iuculano.fplayer.SDLActivity.void onCreate(android.os.Bundle)(SourceFile:324)
at android.app.Activity.performCreate(Activity.java:4465)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1052)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1932)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1993)
at android.app.ActivityThread.access$600(ActivityThread.java:127)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1159)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4507)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:557)
at dalvik.system.NativeStart.main(Native Method)
The exception is caused by a simple System.loadLibrary("main");
What does it mean? cannot locate '__gnu_thumb1_case_uqi'
The __gnu_thumb1_case_uqi is a helper which does an indexed jump on a densely packed switch table; quickly implements the switch. You have two options: avoid it or link with it.
If you increase an optimization level (by using -O3) you might not need this symbol. Also, changing the CPU may help as well as using thumb2 instructions. Compiling with the -ffreestanding option may also avoid this symbol. If you have control over the switch statement, you can replace it with an array of function pointers.
This routine is inside libgcc. You can statically link libgcc. Somewhere in the Android SDK/compiler, there must be a libgcc.a. Link with libgcc.a, using -L and -l or use -static-libgcc linker option to get the code (see http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html).
Edit: If you aren't compiling anything, then you can find libgcc.so on your system. It might be in /lib or /usr/lib or perhaps some place weird for Android devices. Adding the directory where the libgcc.so is located to the environment variable LD_LIBRARY_PATH could also fix the problem. It maybe unfortunate that Samsung released incompatible binaries and you have no way to fix the issue if you aren't compiling your own code. The correct libgcc.so maybe inside something like /usr/lib/thumb for multi-lib distributions. I don't know much about the Davlik stuff, but the Android JVM might not pointing to the right set of libraries when it runs.
Are you compiling for armv7? If you're not, try compiling for armv7.
Producing optimised NDK code for multiple architectures?
read about 'arm' vs 'thumb' in the accepted answer in the above link.
then, remove your config instructions to build for thumb and verify that you are building for arm...
OR...
ill make a wild guess ... its the library order you have in the linker statement in your 'Android.mk'
try the google forum for ndk ... searching for 'cannot locate symbol'...
Really desperate?
see 'Runtime errors' section here