I'm having a problem with combining Tensorflow and AndroidScanner.
I use Tensorflow to display an overlay over the camera feed. I take a picture with the camera, and then send it to a server. It works.
Now I imported the AndroidScannerDemo, I want to use the taken picture and crop/transform it with the newly imported module. It crashes. When I open the ScanActivity (from the AndroidScannerDemo), it tries to load opencv, and never succeeds. The error message is as follows:
FATAL EXCEPTION: main
Process: fr.pacifica.insurancechat.debug, PID: 2139
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/fr.pacifica.insurancechat.debug-OI_d1EANbiczpZEwAHYdkw==/base.apk"],nativeLibraryDirectories=[/data/app/fr.pacifica.insurancechat.debug-OI_d1EANbiczpZEwAHYdkw==/lib/arm64, /data/app/fr.pacifica.insurancechat.debug-OI_d1EANbiczpZEwAHYdkw==/base.apk!/lib/arm64-v8a, /system/lib64, /system/vendor/lib64]]] couldn't find "libopencv_java3.so"
at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
at java.lang.System.loadLibrary(System.java:1657)
at com.scanlibrary.ScanActivity.(ScanActivity.java:125)
at java.lang.Class.newInstance(Native Method)
at android.app.Instrumentation.newActivity(Instrumentation.java:1190)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2837)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3046)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1688)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6809)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
When I delete TensorFlow references from gradle/code, the imported module works just fine.
The project you imported, only builds 32-bit versions of libScanner.so, and therefore only uses the 32-bit versions of libopencv_java3.so. In the short run, you can keep that, only set
android {
defaultConfig {
ndk {
abiFilters 'armeabi-v7a'
}
}
}
This will cause your APK run in 32-bit mode on arm64 devices.
In the long run, you should update the Scanner library to build in 64-bit, too. This may have a significant performance gain.
from August 2019, 64-bit support is required for all apps in Play Store
I had the same problem with some mobiles (64 bits processor)
Here is the libs you need for every single arquitecture. You can download it and import manually.
https://github.com/jhansireddy/AndroidScannerDemo/tree/2cd23d3d362d0a6248cf489a79ebc4ba2c425c60/ScanDemoExample/scanlibrary/src/main/libs
Related
My app has been working smoothly for the last few months. But since last week I have been getting the following error a lot,
Fatal Exception: java.lang.RuntimeException: Unable to create application com.foo.bar.MyApplication: com.getkeepsafe.relinker.MissingLibraryException: Could not find 'librealm-jni.so'. Looked for: [x86], but only found: [].
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5743)
at android.app.ActivityThread.-wrap1()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1656)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
This issue has 40 crash events affecting 7 users (My app only has less than 3000 installs).
These are the affected devices,
Nexus 5X
HUAWEI WDGF4587
QEMU Standard PC (Q35 + ICH9, 2009) <= Someone experimenting with my apk?
Motorola One Vision (rooted)
for a similar issue,
someone suggested to use android.bundle.enableUncompressedNativeLibs=false
This blog post says that Android won't be able to load 32- and 64-bit native libraries concurrently. In my app, I'm also using other libraries such as uCrop and my own native codes. The solution he suggested is to simply exclude all 64-bit binaries from your APK.
Does anyone know the implications of the above-mentioned fixes?
You specified the cpu architecture of the response in your project. I think it's a cpu architecture configuration issue.
Our app is currently running in TC56 and TC57 devices, and we are observing intermittent crashes in few devices.
[Events]
java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app/com.XXX.XXX-9biWE6eu2GZJuAqHQGqPpw==/lib/arm/libcrashmanager-ndk.so" has bad ELF magic
at java.lang.Runtime.loadLibrary0(Runtime.java:1016)
at java.lang.System.loadLibrary(System.java:1657)
at com.XXX.device.crashmanager.ndk.NDKCrashDetector.<init>(NDKCrashDetector.java:3)
at com.XXX.device.crashmanager.CrashDetectionHelper.enableNDKCrashDetection(CrashDetectionHelper.java:1)
at com.XXX.XXX.android.log.CustomCrashReporterImpl.initialise(CustomCrashReporterImpl.java:6)
at com.XXX.XXX.android.XXX.onCreate(XXX.java:5)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1120)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5765)
at android.app.ActivityThread.-wrap1(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1669)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6528)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
We came across this which is very similar to our crashes. I have validated we are using
osVersion: 8.1.0 which is greater than what is suggested in answer.
One of the main reason is this is intermittent failure
You're using a library libcrashmanager-ndk that is corrupted in some way. "Bad ELF magic" means that the first 4 bytes (I think 4, may be off on size) of the file are not the magic combo expected to recognize an ELF file. ELF files are linux executable files. The only fix for this is to get a good version of the library (or not to use it at all).
I am working on adding OTG fingerprint sensor implementation with webrtc-client project. Fingerprint sensor library has .so file which I need to add into jniLibs folder. And I have converted webrtc-client android project to library and trying to include that in the project where fingerprint sensor is already implemented, but as soon as I add this module in the project, app starts giving error for fingerprint sensor system.so file, here is the error details:
Process: com.fingerprint.rcapp, PID: 7793
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.fingerprint.rcapp--XpzGpbTo00QmDUMlC48fQ==/base.apk"],nativeLibraryDirectories=[/data/app/com.fingerprint.rcapp--XpzGpbTo00QmDUMlC48fQ==/lib/arm64, /data/app/com.fingerprint.rcapp--XpzGpbTo00QmDUMlC48fQ==/base.apk!/lib/arm64-v8a, /system/lib64, /product/lib64]]] couldn't find "libast2600.so"
at java.lang.Runtime.loadLibrary0(Runtime.java:1067)
at java.lang.Runtime.loadLibrary0(Runtime.java:1007)
at java.lang.System.loadLibrary(System.java:1667)
at com.fingerprint.rcapp.astdev.natives.PfsBioFpJNI.<clinit>(PfsBioFpJNI.java:95)
at com.fingerprint.rcapp.astdev.natives.PfsBioFpJNI.createInstance(PfsBioFpJNI.java:110)
at com.fingerprint.rcapp.astdev.natives.Ast2600.<init>(Ast2600.java:41)
at com.fingerprint.rcapp.LoginActivity.onCreate(LoginActivity.java:98)
at android.app.Activity.performCreate(Activity.java:7955)
at android.app.Activity.performCreate(Activity.java:7944)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1307)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3423)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3595)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2147)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:237)
at android.app.ActivityThread.main(ActivityThread.java:7814)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1068)
I tried searching for similar solutions but nothing worked in my favour, it would be really helpful if someone can help me on this. Thank you.
EDIT
One thing I found out is the socket.io-client library and io.pristine libraries are creating this issue. When I comment out these two libraries, it works just fine but then webrtc-client does not work.
implementation 'com.github.nkzawa:socket.io-client:0.4.2'
api 'io.pristine:libjingle:9127#aar'
EDIT 2
I have figured out the root cause of this issue, the OTG FingerPrint sensor library use 32-bit .so file but io.pristine:libjingle:9127#aar library use 64-bit .so file, so when I am adding this library, it is looking for the fingerprint sensor library in 64-bit libs only. To fix this issues, I am trying to an implementation to either support both 64-bit and 32-bit libraries or ask for 64-bit library from Fingerprint sensor provider.
Fixed this issue by adding an implementation to support both 32-bit and 64-bit libraries.
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'm developing an Android app which uses a native library called liballjoyn_java.so (available here in the Android Core SDK). I'm using Android Studio as IDE and Maven as build/dependency system (not Gradle). With Android KitKat everything worked like a charm and this is how I added the library to my project:
1) Added the library to my local Maven repo
mvn install:install-file -Dfile=./alljoyn/liballjoyn_java.so -DgroupId=org.alljoyn -DartifactId=liballjoyn_java -Dversion=14.06.00 -Dscope=runtime -Dpackaging=so
2) Defined a dependency in the POM file:
<dependency>
<groupId>org.alljoyn</groupId>
<artifactId>liballjoyn_java</artifactId>
<scope>runtime</scope>
<type>so</type>
<version>14.06.00</version>
</dependency>
3) Called it statically from my code:
static {
try {
System.loadLibrary("alljoyn_java");
Log.d("AllJoynManager", "static - Loaded AllJoyn native library");
} catch (Exception exception) {
Log.d("AllJoynManager", "static - Error loading AllJoyn native library");
exception.printStackTrace();
}
}
This was working perfectly under KitKat in my Nexus 4 phone but now I installed the official Android 5.0 OTA update and I get the following error on runtime:
11-28 17:57:39.988 30068-30068/com.avispalabs.kiihome E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.avispalabs.kiihome, PID: 30068
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.avispalabs.kiihome-2/base.apk"],nativeLibraryDirectories=[/data/app/com.avispalabs.kiihome-2/lib/arm, /vendor/lib, /system/lib]]] couldn't find "liballjoyn_java.so"
at java.lang.Runtime.loadLibrary(Runtime.java:366)
at java.lang.System.loadLibrary(System.java:989)
at com.avispalabs.kiihome.helpers.network.alljoyn.AlljoynManager.<clinit>(AlljoynManager.java:38)
at com.avispalabs.kiihome.ui.activities.MainActivity.<init>(MainActivity.java:38)
at java.lang.reflect.Constructor.newInstance(Native Method)
at java.lang.Class.newInstance(Class.java:1572)
at android.app.Instrumentation.newActivity(Instrumentation.java:1065)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2199)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
at android.app.ActivityThread.access$800(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5221)
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:899)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
11-28 17:57:55.432 30068-30068/com.avispalabs.kiihome I/Process﹕ Sending signal. PID: 30068 SIG: 9
I suspect the .so library might have been compiled in way which is somehow incompatible with the new Android 5.0 ART (?). The message that says it can't find the library is probably misleading (the exception is also seen when a library fails to load) but I'm not sure (another possibility is the .so is not correctly extracted or placed).
The library comes precompiled and is advertised to be compatible with JellyBean. I thought previous dynamic libraries would be compatible with new versions of Android, otherwise a lot of apps would break. If I install the same APK in a Nexus 4 with KitKat it just works.
Any advice is highly appreciated.
UPDATE: I have tested my project in a KitKat based device and switched the runtime to ART rather than Dalvik, and the project works fine. This problem seems to be tied to Android 5 rather than ART itself.
Answering my own question here. You can solve it by compiling liballjoyn_java as PIE as explained here:
https://jira.allseenalliance.org/browse/ASACORE-1208
This is a workaround until the AllJoyn guys publish a new Android build. Keep an eye here to get the updated release:
https://build.allseenalliance.org/ci/view/Core%20RB14.12%20SDK/job/branch-android-sdk/