Runtime error with UltraliteJ64

[former_SQLA_member1695026]

We updated our so files and jar file, according to the description in "UltraliteJ 64bit" forum topic (https://sqlanywhere-forum.sap.com/questions/33960/ultralitej-64bit) The build is ok, the apk includes the files, but the app crashes immediately after install with the following error message:

ACRA caught a UnsatisfiedLinkError for java.lang.UnsatisfiedLinkError: No implementation found for void com.sap.ultralitejni17.implementation.JniDbMgr.setLibraryLocation(java.lang.String) (tried Java_com_sap_ultralitejni17_implementation_JniDbMgr_setLibraryLocation and Java_com_sap_ultralitejni17_implementation_JniDbMgr_setLibraryLocation__Ljava_lang_String_2) at com.sap.ultralitejni17.implementation.JniDbMgr.setLibraryLocation(Native Method) at com.sap.ultralitejni17.implementation.JniDbMgr.Connect(Unknown Source:76) at com.sap.ultralitejni17.DatabaseManager.connect(Unknown Source:0)

Got the same error message on
- Android 9, 10 and 11 as well - With different Ultralite 17 builds (5855, 6230, 6315)

With the previous versions, without support for Android arm64 and x86_64, the app did not and does not crash.

How can we solve this runtime error?

Thank You in advance!

[chris_keating]

This is unlikely to be specifically the result of changes to add support for arm64 and and x64. Can you confirm the target devices (Device model, android version, and chipset) in which this issue is seen? I know of other implementation using these patches without error. Perhaps the wrong shared library is being loaded.

[former_SQLA_member1695026]

With universal apks we tested it on the following devices (also tested with split):

Device model: Samsung Galaxy Tab Active2 android version: 9 chipset: arm-v7

Device model: Samsung Galaxy Tab Active3 android version: 10 chipset: arm-v7

Device model: Samsung Galaxy Tab Active3 android version: 11 chipset: arm-v7

The last patch without x64 support (5820) does not crash.

[chris_keating]

I cannot reproduce this behavior. If you are able, can you open a support incident on this topic. If not, can you package up a simple repro (one that is simply creates/connects to a database) that shows the problem and send to firstname.lastname@sap.com and I will take a look. It is very odd since this method has existed well before any of the changes that you cite and other environments are not reporting this behaviour. Please include the specific SQLAny 17 version that you are testing so that I can check the deployment files.

[former_SQLA_member1695026]

Thank you for the suggestion. I sent the email to you.

[chris_keating]

The native libraries are, by default, located in the projects app/src/main/jniLibs with the directories

   arm64-v8a
   armeabi-v7a
   x86
   x86_64

This was the cause for this issue. There may be configuration changes that can be made to redirect where the shared objects can be located in the Android Studio project. For example, the app/build.gradle android{...} may use the following

sourceSets { main { jni.srcDirs = ['src/main/jni', 'src/main/jniLibs/'] } }

to define the location of the libraries.