mapbox / mapbox-gl-native

Interactive, thoroughly customizable maps in native Android, iOS, macOS, Node.js, and Qt applications, powered by vector tiles and OpenGL
https://mapbox.com/mobile
Other
4.37k stars 1.33k forks source link

Missing arm64 lib #3128

Closed leofarage closed 8 years ago

leofarage commented 8 years ago

I'm trying to use MapBox's version 2. in my project but when I try to show the Map an UnsatisfiedLinkError is thrown.

java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.whittl.whittl.debug-1/base.apk"],nativeLibraryDirectories=[/data/app/com.whittl.whittl.debug-1/lib/arm64, /vendor/lib64, /system/lib64]]] couldn't find "libmapbox-gl.so"

I saw an open issue that was discussing something related to that -- in the discussion it seemed that Android should fallback to the 32bit lib if no 64bit was found, but clearly this is not happening in my case.

Both my project and the MapboxGLAndroidSDKTestApp included in this repository throw the same error, but https://github.com/mapbox/mapbox-android-demo runs.

I'm using the same gradle url for fetching MapBox as mapbox-android-demo.

I hope you guys can lend me a hand.

Thanks!

zugaldia commented 8 years ago

Thank you @leofarage for the report. Just to clarify, you're only seeing this message on 64bits devices, right?

I just tried a fresh build on a Nexus 6p which is a 64 bits device and I couldn't reproduce the issue (see screenshot below). Could you tell us the steps you follow to reproduce this crash? That'd help us troubleshoot the root cause of it. Also, are you seeing this crash with every run, or just during the first time you try to launch the app?

screenshot_20151201-093900

zugaldia commented 8 years ago

/cc: @bleege @tobrun

bleege commented 8 years ago

@leofarage Yep, the Mapbox Android SDK don't ship an arm64 .so as part of the Android Library based on information from Google. Could you tell us more about how your project is setup? Are there other native code bases / dependencies as part of it?

As some background, we regularly develop and test using 64 bit Android devices specifically the Samsung S6 and HTC M9. That's not to say there isn't an issue but I just wanted to let you know that we regularly run it on 64 bit devices (in addition to 32 bit devices).

leofarage commented 8 years ago

My project has a few other libraries that are being used -- possibly forcing the use of 64 bits .so?

I tested on the Samsung Galaxy S6 and S6 Edge and both crashed. I'm attaching in the end of the comment the libraries used in the project.

Both devices crashes on entering the project's MapActivity. The map Activity's layout is made of 2 fragments -- one fragment containing the MapView defined using xml and the other fragment has a recycler view using a Horizontal LinearLayoutManager. Both fragments are child of a RelativeLayout where the MapFragment takes the whole parent and the RecyclerViewFragment takes just 1/4 of the bottom part of the parent -- overlapping the map.

As I mentioned this repository's example app crashes the same way as my project does. I really don't know what I could be doing wrong.

Thanks for taking the time for trying to solve my issue.

Here are the libraries used in the project:

   // Google's support libraries
    compile 'com.android.support:appcompat-v7:23.0.0'
    compile 'com.android.support:design:23.0.0'
    compile 'com.android.support:cardview-v7:23.0.0'
    compile 'com.android.support:recyclerview-v7:23.0.0'

    // Google Play service library
    compile 'com.google.android.gms:play-services-location:7.8.0'

    // Network libraries
    compile 'com.squareup.retrofit:retrofit:1.9.0'
    compile 'com.google.code.gson:gson:2.3.1'
    compile 'com.squareup.picasso:picasso:2.5.2'

    // Facebook SDK
    compile 'com.facebook.android:facebook-android-sdk:4.5.0'

    // Crashlytics
    compile('com.crashlytics.sdk.android:crashlytics:2.5.2@aar') {
        transitive = true;
    }

    // Material dialogs
    compile 'com.afollestad:material-dialogs:0.7.9.1'

    // MapBox SDK
    compile ('com.mapbox.mapboxsdk:mapbox-android-sdk:2.2.0@aar'){
        transitive=true
    }

    // Card library
    compile 'com.github.gabrielemariotti.cards:cardslib-core:2.1.0'
    compile 'com.github.gabrielemariotti.cards:cardslib-cards:2.1.0'

    // Image slider
    compile 'com.nineoldandroids:library:2.4.0'
    compile 'com.daimajia.slider:library:1.1.5@aar'

    // Spannable string builder helper
    compile 'com.binaryfork:spanny:1.0.2'

    // Card.io library
    compile 'io.card:android-sdk:5.1.0'

    // Stripe library
    compile 'com.stripe:stripe-android:+'

    // Facebook Parse
    compile 'com.parse.bolts:bolts-android:1.+'
    compile 'com.parse:parse-android:1.+'

    // Caligraphy library (for using custom fonts)
    compile 'uk.co.chrisjenx:calligraphy:2.1.0'
bleege commented 8 years ago

As I mentioned this repository's example app crashes the same way as my project does. I really don't know what I could be doing wrong.

Ah... one thing to check is to make sure that a germane ABI .so is being generated for the device / emulator that it'll run on. They'll show up in the jniLibs directory of MapboxGLAndroidSDK (see screenshot).

screen shot 2015-12-02 at 10 04 56 am Possible ABI In Project

ABI are created using the make command in the root of the whole project (not in /android). Here's how those work:

// Produces armabi-v7a
make android

// Produce specific ABI
make android-lib-***

// Specific ABI Example for x86
make android-lib-x86

// Produces all ABI
make apackage

My project has a few other libraries that are being used -- possibly forcing the use of 64 bits .so?

Very possible. If one of those libraries ships an arm64 ABI .so then the device will only look there for them, which is a known issue. That said, looking at your dependencies list I didn't see one. We use many of the same libraries internally too and haven't seen issues with them.

leofarage commented 8 years ago

Hi, sorry for taking so long to answer -- I was out of the office.

Anyhow, I found out that the Card.IO library packs the 64 bits libs, consequently it creates a arm64-v8a folder inside the libs folder of the app.

After removing it from the app the UnsatisfiedLinkError disappeared, instead a new error appeared:

E/libEGL: validate_display:255 error 3008 (EGL_BAD_DISPLAY) E/mbgl: {Main}[OpenGL]: eglCreateWindowSurface() returned error 12296 A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 22079

This test was done using a Samsung Galaxy S6 Edge running Android 5.0.2 and a Samsung Galaxy S3 running Android 4.3

Thanks for all the help!

leofarage commented 8 years ago

Hi, I realized that the accessToken was missing from the Manifest file -- that solved the issue mentioned above.

I guess this issue is resolved. The best solution would be the lib packing a 64bits .so but since this is not planned for the near future I'll have to decided what to do about the Card.IO lib.

Thank you for all the help!

leofarage commented 8 years ago

So, I found out that gradle supports targeting platforms. I found it in this SO question.

Using that I forced my project to not attach the 64 bits .so. I guess this is a good solution while Mapbox doesn't support 64 bits.

mmuelder commented 8 years ago

I am getting the exact same libmapbox-gl.so error as soon as I add compile 'io.realm:realm-android:0.85.0' to my dependencies and jcenter() to the repositories. (HTC One M9, tested in MapBoxAndroidDemo)

bleege commented 8 years ago

Thanks for all the insight into arm64 question (and the Gradle filtering option on StackOverflow). For some context / history we looked into this issue in September 2015 and discovered that Google is still only recommending 32 bit .so files.

This doesn't mean that we are against shipping a 64 bit .so as other libraries can and do, but simply that this is the current state. If you're interesting in adding 64 bit .so support, the first step will be to add it to the Makefile and run make android-lib-arm64 from the Command Line. We :heart: Pull Requests so please feel free to submit a working arm64 PR.

bleege commented 8 years ago

Discussed this issue with @kkaefer this morning and he's going to look into it. The big stumbling block has traditionally been getting it to compile properly and not knowing / understanding the intricacies of C++ when it errors out to understand the overall scope.

The same C++ code base does already run on x86_64 for Android as well as the 64 bit chips that Apple uses in it's iOS devices.

bleege commented 8 years ago

Things are already looking promising thanks to 5 minutes of @kkaefer's time. Turns out that the project's Mason build file has a bit different naming conventions for ABI that Android and he was able to get the ARM 64 bit version to compile and produce a .so.

He ran: make android-lib-arm-v8 -j8 which produced:

platform/android/MapboxGLAndroidSDK/src/main/jniLibs/arm64-v8a/libmapbox-gl.so

I'll test this on a 64 bit Android device as @kkaefer doesn't have access to one. Assuming that it works as expected, I'll add this ABI to the build list.

For clarity and posterity, here's the Mason mapping to ABI

arm-v8 => arm64-v8a
arm-v7 => armeabi-v7a
arm-v5 => armeabi
x86 => x86
x86-64 => x86_64
mips => mips
mips-64 => mips64
bleege commented 8 years ago

I did an initial test of things running on a Nexus 5x, which has a 1.8 GHz hexa core 64-bit ARMv8-A and ran into the error below:

Steps

  1. make android-lib-arm-v8 -j8
  2. Run TestApp from Android Studio
02-25 10:43:02.596 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err: java.io.FileNotFoundException: /jacoco.exec: open failed: EROFS (Read-only file system)
02-25 10:43:02.596 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at libcore.io.IoBridge.open(IoBridge.java:452)
02-25 10:43:02.596 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at java.io.FileOutputStream.<init>(FileOutputStream.java:87)
02-25 10:43:02.596 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at org.jacoco.agent.rt.internal_773e439.output.FileOutput.openFile(FileOutput.java:67)
02-25 10:43:02.596 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at org.jacoco.agent.rt.internal_773e439.output.FileOutput.startup(FileOutput.java:49)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at org.jacoco.agent.rt.internal_773e439.Agent.startup(Agent.java:122)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at org.jacoco.agent.rt.internal_773e439.Agent.getInstance(Agent.java:50)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at org.jacoco.agent.rt.internal_773e439.Offline.<clinit>(Offline.java:31)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at com.mapbox.mapboxsdk.testapp.MapboxApplication.$jacocoInit(MapboxApplication.java)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at com.mapbox.mapboxsdk.testapp.MapboxApplication.<init>(MapboxApplication.java)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at java.lang.Class.newInstance(Native Method)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.Instrumentation.newApplication(Instrumentation.java:996)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.Instrumentation.newApplication(Instrumentation.java:981)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.LoadedApk.makeApplication(LoadedApk.java:573)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4680)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.ActivityThread.-wrap1(ActivityThread.java)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1405)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.os.Handler.dispatchMessage(Handler.java:102)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.os.Looper.loop(Looper.java:148)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at android.app.ActivityThread.main(ActivityThread.java:5417)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at java.lang.reflect.Method.invoke(Native Method)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
02-25 10:43:02.597 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err: Caused by: android.system.ErrnoException: open failed: EROFS (Read-only file system)
02-25 10:43:02.598 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at libcore.io.Posix.open(Native Method)
02-25 10:43:02.598 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at libcore.io.BlockGuardOs.open(BlockGuardOs.java:186)
02-25 10:43:02.598 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:     at libcore.io.IoBridge.open(IoBridge.java:438)
02-25 10:43:02.598 10221-10221/com.mapbox.mapboxsdk.testapp W/System.err:   ... 21 more
02-25 10:43:02.609 10221-10236/com.mapbox.mapboxsdk.testapp D/LeakCanary: Could not attempt cleanup, leak storage not writable.
02-25 10:43:02.666 10221-10221/com.mapbox.mapboxsdk.testapp W/LocationServices: Location Permissions Not Granted Yet.  Try again after requesting.
02-25 10:43:02.690 10221-10238/com.mapbox.mapboxsdk.testapp A/libc: Fatal signal 4 (SIGILL), code 1, fault addr 0x7f8b36c650 in tid 10238 (pboxsdk.testapp)
02-25 10:43:02.741 484-484/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-25 10:43:02.742 484-484/? A/DEBUG: Build fingerprint: 'google/bullhead/bullhead:6.0.1/MMB29Q/2480792:user/release-keys'
02-25 10:43:02.742 484-484/? A/DEBUG: Revision: 'rev_1.0'
02-25 10:43:02.742 484-484/? A/DEBUG: ABI: 'arm64'
02-25 10:43:02.742 484-484/? A/DEBUG: pid: 10221, tid: 10238, name: pboxsdk.testapp  >>> com.mapbox.mapboxsdk.testapp <<<
02-25 10:43:02.742 484-484/? A/DEBUG: signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x7f8b36c650
02-25 10:43:02.751 484-484/? A/DEBUG:     x0   0000007f9e489130  x1   0000007f999a6310  x2   0000000000000003  x3   0000000000000002
02-25 10:43:02.751 484-484/? A/DEBUG:     x4   0000007fa2ee3000  x5   00000000ffffffff  x6   0000000000000001  x7   0000007f9e4894f0
02-25 10:43:02.752 484-484/? A/DEBUG:     x8   0000007f8b36c650  x9   0000007f9e4894f0  x10  0000000000000001  x11  0000007f95125900
02-25 10:43:02.752 484-484/? A/DEBUG:     x12  0000007fa2ea3b40  x13  0000000000000001  x14  0000000000000002  x15  0000000000000008
02-25 10:43:02.752 484-484/? A/DEBUG:     x16  0000000000000009  x17  0000007fa2ea3000  x18  0000007f95125900  x19  0000007f999a6300
02-25 10:43:02.753 484-484/? A/DEBUG:     x20  0000007f999a6310  x21  0000007f9e489130  x22  0000007f9e702140  x23  0000007f9e489310
02-25 10:43:02.753 484-484/? A/DEBUG:     x24  92742faffdb3cfce  x25  0000007f9e489130  x26  0000007ff0d0cd88  x27  0000007ff0d0cce8
02-25 10:43:02.753 484-484/? A/DEBUG:     x28  0000000000001000  x29  0000007f9e4890f0  x30  0000007f8b16b4d0
02-25 10:43:02.753 484-484/? A/DEBUG:     sp   0000007f9e4890d0  pc   0000007f8b36c650  pstate 0000000060000000
02-25 10:43:02.760 484-484/? A/DEBUG:     #00 pc 00000000003fd650  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so
02-25 10:43:02.760 484-484/? A/DEBUG:     #01 pc 00000000001fc4cc  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (mbgl::util::AsyncTask::Impl::Impl(std::__1::function<void ()>&&)+96)
02-25 10:43:02.760 484-484/? A/DEBUG:     #02 pc 00000000001fc308  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (mbgl::util::AsyncTask::AsyncTask(std::__1::function<void ()>&&)+40)
02-25 10:43:02.760 484-484/? A/DEBUG:     #03 pc 00000000001fc888  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (mbgl::util::RunLoop::RunLoop(mbgl::util::RunLoop::Type)+680)
02-25 10:43:02.761 484-484/? A/DEBUG:     #04 pc 000000000020a4c8  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (void mbgl::util::Thread<mbgl::DefaultFileSource::Impl>::run<std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long&>, 0ul, 1ul>(mbgl::util::ThreadContext, std::__1::tuple<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long&>&&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>)+68)
02-25 10:43:02.761 484-484/? A/DEBUG:     #05 pc 000000000020a420  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (mbgl::util::Thread<mbgl::DefaultFileSource::Impl>::Thread<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long&>(mbgl::util::ThreadContext const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&&&, unsigned long&&&)::'lambda'()::operator()() const+252)
02-25 10:43:02.761 484-484/? A/DEBUG:     #06 pc 000000000020a2cc  /data/app/com.mapbox.mapboxsdk.testapp-1/lib/arm64/libmapbox-gl.so (std::__1::__thread_proxy<std::__1::tuple<mbgl::util::Thread<mbgl::DefaultFileSource::Impl>::Thread<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long&>(mbgl::util::ThreadContext const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&&&, unsigned long&&&)::'lambda'()> >(void*, void*)+100)
02-25 10:43:02.761 484-484/? A/DEBUG:     #07 pc 0000000000066d24  /system/lib64/libc.so (__pthread_start(void*)+52)
02-25 10:43:02.761 484-484/? A/DEBUG:     #08 pc 000000000001eb84  /system/lib64/libc.so (__start_thread+16)
02-25 10:43:02.919 877-10239/? W/ActivityManager:   Force finishing activity com.mapbox.mapboxsdk.testapp/.MainActivity
02-25 10:43:02.919 484-484/? E/DEBUG: AM write failed: Broken pipe
bleege commented 8 years ago

/cc @jfirebaugh

jfirebaugh commented 8 years ago

I'm blocked on further progress here due to lack of understanding of the Android build process and toolchain and how it works with mason. I will need to arrange a time when @kkaefer is available to walk me through this.

bleege commented 8 years ago

I discussed this issue with @tmpsantos this morning and he's been working more on Android / Core GL work recently. He said he has the time to work on this, but just needs an arm64 phone to work with. I'll get a Nexus 5x ordered for him.

bleege commented 8 years ago

/cc @brunoabinader

tmpsantos commented 8 years ago

Got the device and I was able to reproduce the crash.

bleege commented 8 years ago

@tmpsantos Awesome! This is going to be great to get this working. Thanks!

bleege commented 8 years ago

Mason updates to gold documented here --> https://github.com/mapbox/mason/pull/135

bleege commented 8 years ago

Uni-branch update for Mason that impacts this is documented here --> https://github.com/mapbox/mason/pull/133

bleege commented 8 years ago

The development branch is 3128-arch64_android.

bleege commented 8 years ago

I just successfully tested the arm-64 ABI by doing the following on my Nexus 5x, which runs at 64 bit processor.

  1. Checkout 3128-arch64_android
  2. make clean
  3. make android-lib-arm-v8 -j8
  4. Run TestApp and cycle through entire Test activities in it.

This confirms to me that the arm-64 ABI works in isolation as expected. :fireworks:

The next thing to do is confirm that the other supported ABI continue to work by running it through AWS Device Farm.

screen shot 2016-03-16 at 7 09 29 pm

arm-64 ABI in local SDK

screen shot 2016-03-16 at 7 10 45 pm

arm-64 ABI in local TestApp

bleege commented 8 years ago

I re ran last night's arm64 test this morning for the arm7 ABI using the stock make android command. Everything worked as expected on the Nexus 5x. Based on these results I'm confident that @tmpsantos solution will work as needed for the arm ABIs.

The remaining thing to do is to verify that the remaining ABIs (x86, x86-64, mips) work as expected also. To do this @tobrun has produced sample TestApp .apk that include all ABIs (via make apackage) and is working with @zugaldia to upload them to AWS Device Farm for testing across the different ABIs. This should take a few hours, so by the end of the day we should be officially good to go.

The only remaining thing to do once we get sign off is to add android-lib-arm-v8 back into the make apackage build stack via the Makefile.

screen shot 2016-03-17 at 11 20 50 am

arm 32 bit ABI in local SDK

screen shot 2016-03-17 at 11 21 02 am

arm 32 bit ABI in local TestApp

tobrun commented 8 years ago

The results are in, we are now supporting the same amount as before thus the introduction of the 64 bit was succesfull!

bleege commented 8 years ago

Excellent @tobrun @zugaldia ! I'll merge update the Makefile to add arm64 build to it and then merge it into the release branch so it makes it to 4.0.0-final.

bleege commented 8 years ago

It looks like @tmpsantos merged this into master already which didn't show up until after I refreshed this page on GitHub. D'oh! Based on how GitHub automatically closed this issue via 51a3907d525967741a44f4ff02146bee4d52cbed it looks like that's the only commit I'll need to cherry pick to the release-ios-3.2.0-android-4.0.0 branch to get the arm64 support added. I'll also cherry pick 08f92ff19989552149fd4c1a369ce999da57afe5 as it formally adds arm64 to the Android Library .aar build process.

bleege commented 8 years ago

As usual @tmpsantos is one step of ahead of me and has added the arm64 inclusion in PR #4366. So the new plan is to merge that PR into master. Once that's done, I'll cherry pick both files over to the release branch and then close this ticket.

bleege commented 8 years ago

I just cherry picked the two commits as discussed with @tmpsantos from master to release-ios-3.2.0-android-4.0.0. I'm going to fire off a new SNAPSHOT from release-ios-3.2.0-android-4.0.0 so that we can make this available ASAP.

Big thanks to @tmpsantos for solving this problem! :boom:

screen shot 2016-03-17 at 2 33 42 pm

arm64 Fix Commits Cherry Picked Onto Release Branch

leofarage commented 8 years ago

Awesome! Congratulations!