UnsatisfiedLinkError on x86 when not only targeting x86

[ajchellew]

Using 8.5.2 (and 8.5.0) I am getting an UnsatisfiedLinkError seen a number of times before on different reports.

Caused by: java.lang.UnsatisfiedLinkError: No implementation found for void com.mapbox.mapboxsdk.net.NativeConnectivityListener.initialize() (tried Java_com_mapbox_mapboxsdk_net_NativeConnectivityListener_initialize and Java_com_mapbox_mapboxsdk_net_NativeConnectivityListener_initialize__) at com.mapbox.mapboxsdk.net.NativeConnectivityListener.initialize(Native Method)

This is only occurring on release builds where all the different types are built in the APK under 'libs'

If I push a release build directly via Android Studio to the emulator, it works, because it only includes the target type (x86). equally if I set the build to only build x86 via gradle ndk { abiFilters "x86" } the APK works fine.

I've downgraded to 8.4.0 and this does not occur. Complete builds with all architecture types work correctly on the emulator.

[tobrun]

@ajchellew you mention a couple of successful scenarios but were you able to trigger this exception yourself? this seems a duplicate of #38 and has been adressed in #58. Can you retest with 8.6.0?

[ajchellew]

No luck. Better exception though

Release build with 8.6.0 results in this on the emulator:

2020-01-07 13:19:04.839 7031-7031/? E/SoLoader: couldn't find DSO to load: libmapbox-gl.so caused by: dlopen failed: "/data/data/cs.application/lib-main/libmapbox-gl.so" has unexpected e_machine: 40 (EM_ARM)
2020-01-07 13:19:04.840 7031-7031/? E/Mbgl-LibraryLoader: Failed to load native shared library.
    com.facebook.soloader.l$b: APK was built for a different platform
        at com.facebook.soloader.l.a(SoLoader.java:645)
        at com.facebook.soloader.l.a(SoLoader.java:577)
        at com.facebook.soloader.l.a(SoLoader.java:525)
        at com.mapbox.mapboxsdk.e.b.a$a.a(LibraryLoaderProviderImpl.java:42)
        at com.mapbox.mapboxsdk.b.a(LibraryLoader.java:43)
        at com.mapbox.mapboxsdk.net.NativeConnectivityListener.<clinit>(NativeConnectivityListener.java:13)
        at com.mapbox.mapboxsdk.net.b.a(ConnectivityReceiver.java:43)
        at com.mapbox.mapboxsdk.Mapbox.getInstance(Mapbox.java:67)

My app has other SOs but nothing obviously wrong with them. tree of the lib folder in the APK:

├───arm64-v8a
│       libc++_shared.so
│       libgdal.so
│       libgdalalljni.so
│       libgdalwrap.so
│       libmapbox-gl.so
│       libproj.so
│       librealm-jni.so
│       libsqlcipher.so
│
├───armeabi-v7a
│       libc++_shared.so
│       libgdal.so
│       libgdalalljni.so
│       libgdalwrap.so
│       libmapbox-gl.so
│       libproj.so
│       librealm-jni.so
│       libsqlcipher.so
│
├───x86
│       libc++_shared.so
│       libgdal.so
│       libgdalalljni.so
│       libgdalwrap.so
│       libmapbox-gl.so
│       libproj.so
│       librealm-jni.so
│       libsqlcipher.so
│
└───x86_64
        libc++_shared.so
        libgdal.so
        libgdalalljni.so
        libgdalwrap.so
        libmapbox-gl.so
        libproj.so
        librealm-jni.so
        libsqlcipher.so

Windows based emulator in case that varies:

Again if I build restricting to ndk { abiFilters "x86" } it works. The \lib\x86 folder appears to have the same .so-s (at least by file size)

[jlo1]

Hi! I'm seeing a similar error, through the react-native library when upgrading from 7.0.8 to 7.0.9+: https://github.com/react-native-mapbox-gl/maps/releases/tag/7.0.9

The change introduced in 7.0.9 is upgrading the mapbox Android native SDK to 8.6.0.

Seeing this on emulator built on the Google Play x86 Atom System Image, using API level 28. Not seeing on emulators built on other images.

[tobrun]

Could you try doing a clean build? we changed build systems settings and potentially a left over folder was retained. A clean of your build setup should resolve this.

[jlo1]

Hi @tobrun , everything was cleaned locally when building the app.

[tobrun]

@Chaoba could you help look into this issue? I would suggest using 9.1.0 in a separate test project and trying out a couple of build configuration so we can validate the contents of the apk. Once we are able to reproduce the setup, it would be great if we can validate if SoLoader depdency is the source of the issue or a packaging/build configuration for our end.

More information also in #320

[Chaoba]

I can reproduce this issue. I guess it is caused by soLoader, there is already a similar issue in that repo.

[tobrun]

@Chaoba could you see if we can reproduce the issue with the same setup using another LibaryLoader? For example Relinker or System.loadLibrary(). We have runtime configuration that allows you to swap out the used native library loader. Could you also share apk when you are running into this issue? would love to see the structure/content of the jni folders.

[Chaoba]

@tobrun This could be reproduced in MapboxDemo repo on master branch. Your suggestion works, if add the following codes to set a new LibraryLoader, this issue could be fixed.

LibraryLoader.setLibraryLoader(new LibraryLoader() {
      @Override
      public void load(String name) {
        System.loadLibrary(name);
      }
    });
Mapbox.getInstance(...);

[AAverin]

@tobrun Any updates on this issue? 8.5.0 MapBox basically doesn't work on Android at the moment. Also, supposedly a new version of SoLoader with the fix is already released.

[Chaoba]

Thanks all for your help. 9.2.0 has fixed this issue. Please update sdk to this version.

[tobrun]

Following up on this in #416