i am creating a chat application by using Alljoyn framework and am getting the following error can somebody please help me. The alljoyn jars are already set up!!!
FATAL EXCEPTION: main
Process: com.example.vikesh.chat_application, PID: 4326
java.lang.UnsatisfiedLinkError: Couldn't load alljoyn_java from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.example.vikesh.chat_application-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.example.vikesh.chat_application-1, /vendor/lib, /system/lib]]]: findLibrary returned null
at java.lang.Runtime.loadLibrary(Runtime.java:358)
at java.lang.System.loadLibrary(System.java:526)
at com.example.vikesh.chat_application.AlljoynService.<clinit>(AlljoynService.java:1252)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1208)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:2553)
at android.app.ActivityThread.access$1800(ActivityThread.java:135)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
at android.os.Handler.dispatchMessage(Handler.java:102)
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 dalvik.system.NativeStart.main(Native Method)
You need to put the AllJoyn liballjoyn_java.so file within your project.
For example, in Android Studio, the usual location for this file is:
[your_project_dir]/app/src/main/jniLibs/armeabi/
The armeabi portion of the above path is assuming that the AllJoyn .so file that you have previously built is targeted for the 'arm' CPU (the armeabi instruction set).
Note: When I deleted the .so file from my app, I got the same error that you are reporting. When I put the .so file back I still got the same error. I had to uninstall the app from my Android device, and in Android Studio I had to clean and rebuild the app, before I was able to get past this error.
Some other things to consider...
Make sure in your App that you are calling
static {
System.loadLibrary("alljoyn_java");
}
Make sure that the liballjoyn_java.so you previously built matches the cpu instruction set of your Android device. You can verify your Android's instruction set by using an app such as Droid Info, for example. Assuming that it is armeabi, then when you build the AllJoyn core project, you need to specify at a minimum the following switches in your scons build command....
scons BINDINGS="cpp,java,c" OS=android CPU=arm VARIANT=release
Finally, the following Stackoverflow link discusses general reasons the error you are seeing can occur:
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader
Related
I have a really simple android app. I want to load a shared library called 'libcamera.so' and then call methods via JNI.
I do not own this library and I do not have access to the source code. It was originally compiled for ARM.
An x86 version is not available.
The project can detect the library and correctly shows it in the jniLibs folder.
Within my main activity I am trying to load the 3rd party library like so:
static {
System.loadLibrary("camera");
}
When this line executes, logcat shows the following:
02-06 14:11:38.517 4455-4455/uk.co.test.myApp E/art: dlopen("/data/app/uk.co.test.myApp-2/lib/x86/libcamera.so", RTLD_LAZY) failed: dlopen failed: "/data/app/uk.co.test.myApp-2/lib/x86/libcamera.so" has unexpected e_machine: 40
02-06 14:11:38.519 4455-4455/uk.co.test.myApp E/AndroidRuntime: FATAL EXCEPTION: main
Process: uk.co.test.myApp, PID: 4455
java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app/uk.co.test.myApp-2/lib/x86/libcamera.so" has unexpected e_machine: 40
at java.lang.Runtime.loadLibrary(Runtime.java:371)
at java.lang.System.loadLibrary(System.java:988)
at uk.co.test.myApp.MainActivity.<clinit>(MainActivity.java:17)
at java.lang.reflect.Constructor.newInstance(Native Method)
at java.lang.Class.newInstance(Class.java:1603)
at android.app.Instrumentation.newActivity(Instrumentation.java:1066)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2226)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2387)
at android.app.ActivityThread.access$800(ActivityThread.java:151)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1303)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5258)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
Other 3rd party apps which use this library can run on my x86 device (Epson BT350) so I feel like this should be possible.
I have become aware of something called 'Houdini' which allows ARM apps to run on x86 - I have checked and my device has this library so im confused why its not doing its job. But its also quite likely I dont really understand how Houdini works!
I have tried running on an x86 emulator - same error.
Any ideas would be greatly appreciated.
I solved the problem by forcing my app to only build an armeabi version. I did this by using an abifilter within gradle. I added the following to my defaultConfig
ndk {
abiFilters "armeabi"
}
This will then run on my x86 device because Houdini will kick in and do the translation. Its not ideal because this translation affects performance - but its a start and gets me to the next stage.
I wanna implement sinch app to app instant messaging funcitionality to my existing app. I followed github and tutorials I added sdks to my library. I can run my app on emulator. I can login and sign up and send messaging to another account which I also created on emulator. But when I try to run my app on real phone, i've faced with problems. When I click the login and sign up button, my app has stopped. After I rerun my project on emulator, I realized that I was able to sign up on my phone. When I enter my app again, it has crushed. Briefly, my app works on emulator but not on real phone now. I need your help, please help me!!
Below is my logcat.
09-24 17:06:16.991 17061-17061/com.meliksah.cakir.buec E/art﹕ dlopen("/data/app/com.meliksah.cakir.buec-1/lib/arm/libsinch-android-rtc.so", RTLD_LAZY) failed: dlopen failed: "/data/app/com.meliksah.cakir.buec-1/lib/arm/libsinch-android-rtc.so" is too small to be an ELF executable: only found 0 bytes
09-24 17:06:16.991 17061-17061/com.meliksah.cakir.buec D/AndroidRuntime﹕ Shutting down VM
09-24 17:06:16.991 17061-17061/com.meliksah.cakir.buec E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.meliksah.cakir.buec, PID: 17061
java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app/com.meliksah.cakir.buec-1/lib/arm/libsinch-android-rtc.so" is too small to be an ELF executable: only found 0 bytes
at java.lang.Runtime.loadLibrary(Runtime.java:371)
at java.lang.System.loadLibrary(System.java:989)
at com.sinch.android.rtc.internal.client.DefaultSinchClient.<clinit>(DefaultSinchClient.java:72)
at com.sinch.android.rtc.internal.client.InternalSinchClientFactory.createSinchClient(InternalSinchClientFactory.java:17)
at com.sinch.android.rtc.DefaultSinchClientBuilder.build(DefaultSinchClientBuilder.java:95)
at com.meliksah.cakir.buec.MessageService.startSinchClient(MessageService.java:48)
at com.meliksah.cakir.buec.MessageService.onStartCommand(MessageService.java:39)
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3307)
at android.app.ActivityThread.access$2200(ActivityThread.java:177)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1546)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:5942)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1400)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1195)
This error:
dlopen failed: "/data/app/com.meliksah.cakir.buec-1/lib/arm/libsinch-android-rtc.so" \
is too small to be an ELF executable: only found 0 bytes
means that you have a zero-length file with above path.
Either you made a mistake while copying it to your phone, or something truncates it after it's copied. Fixing that problem is almost definitely the required first step in getting your application working.
In my Android Studio project I use a third-party library (which I cannot edit) which requires several native libraries. When I access this third-party library in my app, I get the following error:
java.lang.UnsatisfiedLinkError: Couldn't load avutil-52 from
loader dalvik.system.PathClassLoader
[dexPath=/data/app/com.myApp.debug.apk,
libraryPath=/data/app-lib/com.myApp.debug]:
findLibrary returned null
I use Android Studio 1.2.2, so Gradle supports using a jniLibs folder. My Gradle build file specifies the jniLibs folder, for safety:
android {
sourceSets {
main {
java {
srcDir 'src/main/src'
}
jniLibs {
srcDirs 'src/main/jniLibs'
}
}
}
}
And here I have my libraries:
src/main/jniLibs/armeabi/*.so
The folder includes some other libraries, which are working in the app, so I know the folder is being included.
When I inspect the generated APK, all the *.so files are included in the libs folder. However, when I check the installed app, I only find three of the expected six libraries:
adb shell ls /data/app-lib/com.myApp
first.so
second.so
third.so
I've also checked the /data/data/com/myApp.debug/app_lib/ folder, and none of the other three dependencies are there.
Not being a native Android developer, I find this very puzzling. What could be causing some dependencies to be included, and others to be excluded? Is there a way of forcing Android to recognise the three missing files, and making sure they're installed? Without having to edit the third party library which uses them, of course.
EDIT 1:
Could this code from the third-party library be causing a problem?
public StartFunction() {
String arch = System.getProperty("os.arch");
this.ARM = arch.toUpperCase().contains("ARM") || arch.toUpperCase().contains("AARCH64");
if(this.ARM) {
this.LoadLibraries();
}
}
private void LoadLibraries() {
System.loadLibrary("first");
System.loadLibrary("second");
System.loadLibrary("third");
System.loadLibrary("fourth");
System.loadLibrary("fifth");
System.loadLibrary("sixth");
}
EDIT 2:
This is the full exception from logcat. Package names slightly changed to protect the guilty.
06-30 09:19:08.505 15069-15069/com.myApp.debug E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.myApp.debug, PID: 15069
java.lang.UnsatisfiedLinkError: Couldn't load avutil-52 from loader dalvik.system.PathClassLoader[dexPath=/data/app/com.myApp.debug-1.apk,libraryPath=/data/app-lib/com.myApp.debug-1]: findLibrary returned null
at java.lang.Runtime.loadLibrary(Runtime.java:358)
at java.lang.System.loadLibrary(System.java:526)
at com.thirdPartyApp.embedded.Call.LoadLibraries(Call.java:289)
at com.thirdPartyApp.embedded.Call.<init>(Call.java:214)
at com.thirdPartyApp.embedded.thirdPartyCall$29.run(thirdParty.java:963)
at com.thirdPartyApp.embedded.DownloadFile.onPostExecute(DownloadFile.java:56)
at com.thirdPartyApp.embedded.DownloadFile.onPostExecute(DownloadFile.java:16)
at android.os.AsyncTask.finish(AsyncTask.java:632)
at android.os.AsyncTask.access$600(AsyncTask.java:177)
at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:645)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:146)
at android.app.ActivityThread.main(ActivityThread.java:5487)
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:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at dalvik.system.NativeStart.main(Native Method)
EDIT 3:
I've managed to get this working, but in a kind of dirty way. I don't know exactly why this happened, but I do know what happened:
I had all six the compiled libraries needed by the third party SDK I'm using placed in src/main/jniLibs/armeabi. Conventional wisdom dictates that this should work for all ARM devices. However, when installing the app on an ARM device only three of the six libraries were installed.
Dirty solution: place all six libraries in the src/main/jniLibs/armeabi-v7a folder as well. This scattershot approach meant that all six libraries are installed, and available.
I'll update this once we figure out why this happened.
I'm trying to use Tesseract with Android, everything is fine: I compiled the source and I have the .so files ready. Every .so file is in a folder for the different architecture and is correctly inserted in the APK file by Android Studio (If I open the .apk file i can see lib/ folder with all the directories inside + the .so files inside them)
They are named lept.so and tess.so and in the code it uses
System.loadLibrary("lept");
System.loadLibrary("tess");
But when I launch the application I get this exception
1-02 16:01:20.824 16384-16384/x.x.x.ocrapp E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: x.x.x.ocrapp, PID: 16384
java.lang.UnsatisfiedLinkError: Couldn't load lept from loader dalvik.system.PathClassLoader[dexPath=/data/app/x.x.x.ocrapp-2.apk,libraryPath=/data/app-lib/x.x.x.ocrapp-2]: findLibrary returned null
at java.lang.Runtime.loadLibrary(Runtime.java:358)
at java.lang.System.loadLibrary(System.java:526)
at com.googlecode.tesseract.android.TessBaseAPI.<clinit>(TessBaseAPI.java:44)
at x.x.x.ocrapp.MainActivity.onCreate(MainActivity.java:18)
at android.app.Activity.performCreate(Activity.java:5426)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2269)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2363)
at android.app.ActivityThread.access$900(ActivityThread.java:161)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1265)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:157)
at android.app.ActivityThread.main(ActivityThread.java:5356)
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:1265)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1081)
at dalvik.system.NativeStart.main(Native Method)
Which says that it's unable to load lept library.
It seems like it searchs the library inside libraryPath=/data/app-lib/x.x.x.ocrapp-2 app-lib folder, while mine is inside lib folder.
It doesn't work neither in emulator nor in real device. (Samsung Galaxy S4)
How can I fix this exception and let Android load the native library?
They are named lept.so and tess.so
Those are not standard names, as they lack the lib prefix.
System.loadLibrary("lept");
System.loadLibrary("tess");
This causes a search for liblept.so which is not the file you have.
Either give your library the standard name, or specify an actual file name including the path where it ends up installed on the device to System.load() rather than System.loadLibrary().
We have very weird java.lang.ClassNotFoundException on app startup that happens to very small amount of customers (< 1%). We never saw it in dev env and we cannot understand the source of this issue. Here is the stack trace from Google play crash reports.
java.lang.RuntimeException: Unable to instantiate application com.mycompany.myapplication.MyApplication: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at android.app.LoadedApk.makeApplication(LoadedApk.java:490)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3784)
at android.app.ActivityThread.access$2200(ActivityThread.java:132)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1082)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4268)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at android.app.Instrumentation.newApplication(Instrumentation.java:972)
at android.app.LoadedApk.makeApplication(LoadedApk.java:481)
... 11 more
If the issue only occurs on with signed APKs and you are using Eclipse to Export the Signed APK ...
Before you 'Export and sign an APK' in Eclipse turn off the following setting in the menu [Project > Build Automatically] (then can switch it back on later when you continue developing).
I recently deployed an update to my app, and a user reported a crash the very next day via the Google Play reporting facility. The stack dump was for LoadApk() and the error was in the loading of my Application class. Here is that dump:
java.lang.RuntimeException: Unable to instantiate application com.goalstate.WordGames.FullBoard.library.FullBoardApplication: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:516)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4703)
at android.app.ActivityThread.access$1600(ActivityThread.java:175)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1368)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:146)
at android.app.ActivityThread.main(ActivityThread.java:5602)
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:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:67)
at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
at android.app.Instrumentation.newApplication(Instrumentation.java:981)
at android.app.LoadedApk.makeApplication(LoadedApk.java:511)
... 11 more
I have a library and my Application class was defined in that library. The manifest for my app (which used the library) referred to the class in that library by its full path. It did not have an application class of its own.
All of my in-house testing had not reproduced this problem, and even when I tested (using the Samsung Remote Test Lab) on the same device (actually two different devices, one running 4.3 and one running 4.4.4) as reported the crash (a Galaxy Note II, running Android 4.4), there was no problem.
In searching for information on this I found mention of the fact that different devices may have slightly different approaches to resolving class references, and that is probably why most devices had no problem with my APK, but this particular device (which, unlike my test devices, was provided with its Android flavor by Sprint) did. And similarly, it may be why just one percent of your own customers had the problem, while most did not.
I decided that the best approach would be to make it as easy as possible for even an unsophisticated device to find the classes that were referenced from my manifest file. So, I defined a new application class within the package of the app itself (rather than the library) and I had that class inherit from the application class in my library. The new class was otherwise empty.
I then replaced the full path reference to the application class in the library with a relative reference to the new class I had created in the app itself. So, instead of having:
<application android:name="com.goalstate.WordGames.FullBoard.library.FullBoardApplication"
in my manifest, I had:
<application android:name=".FullBoardWordChumsApplication"
That (according to folklore on this topic) should make it easier for a less sophisticated resolution process to succeed.
I also took the full path that I had been using in the manifest to name my already-local activity class and made it relative (by simply lopping off everything preceding the final dot).
Additional folklore found online indicates that it may help to turn off "Build Automatically" for the project in Eclipse, then exit Eclipse, re-enter Eclipse, and then, after it rebuilds, go directly to Android Tools to export the signed APK (without ever turning on Build Automatically). So, throwing salt over my left shoulder, and saying a prayer to the gods of fragmentation paranoia, I accommodated this superstition in preparing my APK for release.
Does any of this really help? Time will tell, but so far my updated release has not generated any additional crashes.
This Error occurs when in your manifest file in application tag whatever class name you put it is not match with your coding java file .So make a current both in way.