Couldn't load (find) j2v8_android_x86 library

Question

I have a gradle project that uses j2v8_android 2.2.1 library (which provides Java bindings for V8 JS engine - android port). Unfortunately, after executing the project (build succeeds without issues), I get an exception related to missing j2v8_android_x86 library file. The issues occurs when trying to create V8 runtime:

V8 runtime = V8.createV8Runtime();

The exception itself is:

Caused by: java.lang.IllegalStateException: J2V8 native library not loaded.
        at com.eclipsesource.v8.V8.checkNativeLibraryLoaded(V8.java:86)
        at com.eclipsesource.v8.V8.createV8Runtime(V8.java:74)
        at com.eclipsesource.v8.V8.createV8Runtime(V8.java:63)
        (...)
Caused by: java.lang.UnsatisfiedLinkError: Could not load J2V8 library. Reasons:
Couldn't load j2v8_android_x86 from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.example.androidscripting.app-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.example.androidscripting.app-1, /vendor/lib, /system/lib, /system/lib/arm]]]: findLibrary returned null
        at com.eclipsesource.v8.LibraryLoader.loadLibrary(LibraryLoader.java:71)
        at com.eclipsesource.v8.V8.load(V8.java:49)
        at com.eclipsesource.v8.V8.createV8Runtime(V8.java:72)
        ... 17 more

When I investigate the apk I see two library files at the root of the apk (libj2v8_android_armv7l.so and libj2v8_android_x86.so). If I understand it correctly, the names and location of those files is correct and they should be resolved.

The application is compiled and packaged by Gradle 2.2.1 (on Oracle JVM 1.8.0_45) with Android SDK 19 compatibility (with language level support 1.7) and executed on Hudl2 running Android 4.4.2.

Answer 1

After speaking to my colleges we found a solution. The path class loader does not actually look under the root of the apk - instead it looks in libs/[ARCHITECTURE]. Moving the libj2v8_android_x86.so file to libs/x86 and repackaging did solve the problem.

I suppose the maven module may have been packaged for an older version and thus did not copy them into the correct directory on build - or may simply be misconfigured.