Compiling for Android - Crashes on Android 6.0

[GoKidGames]

I have an app that works on Android versions < 6.0 but crashes on 6.0.

Crash Report: java.lang.UnsatisfiedLinkError: dlopen failed: library "C:\Development\Android NDK/platforms/android-9/arch-arm/usr/lib/libc.so" not found at java.lang.Runtime.loadLibrary(Runtime.java:372) at java.lang.System.loadLibrary(System.java:1076) at org.haxe.HXCPP.run(HXCPP.java:18) at org.haxe.lime.GameActivity.onCreate(GameActivity.java:120) at android.app.Activity.performCreate(Activity.java:6876) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1135) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3207) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3350) at android.app.ActivityThread.access$1100(ActivityThread.java:222) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1795) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:158) at android.app.ActivityThread.main(ActivityThread.java:7229) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120)

I searched the apk for the string that caused the error, libApplicationMain-v7.so is the only result.

The problem string matches this line

I tested on DisplayinigABitmap created with openfl create project DisplayingABitmap without adding any code, and find the same string in libApplicationMain-v7.so that causes the error.

I'm using the latest version of hxcpp 3.3.49

[hughsando]

Strange that this is only coming up now. You could try replacing those two lines with:

<lib name="-lm"/>
<lib name="-lc"/>

And see if that helps.

[player-03]

That changed the error, but didn't fix it. The new error looks like this:

java.lang.UnsatisfiedLinkError: dlopen failed: /data/app/com.gokidgames.gokidmemory-2/lib/arm/libApplicationMain.so: has text relocations at java.lang.Runtime.loadLibrary(Runtime.java:372) at java.lang.System.loadLibrary(System.java:1076) at org.haxe.HXCPP.run(HXCPP.java:18) at org.haxe.lime.GameActivity.onCreate(GameActivity.java:120) at android.app.Activity.performCreate(Activity.java:6251) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1108) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2403) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2510) at android.app.ActivityThread.-wrap11(ActivityThread.java) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1363) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.app.ActivityThread.main(ActivityThread.java:5461) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

I found a bunch of suggestions on Google, the most common being not to target Android 23. That isn't very satisfying, given that multiple OpenFL developers (including me) can target Android 23 without issues.

Eventually, I came to this post, which actually tries to explain the issue. By running the command that post suggests, I found that my test copy of libApplicationMain.so has no TEXTREL entries, while @GoKidGames's has one:

$ readelf -a libApplicationMain.so | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0

Since You Kim seems to know what he's talking about, I suggest following his advice to update your NDK.

Don't use lime setup android for this, because that downloads version r8b, which is four years out of date. Frustratingly, it seems that the very next version (version r8c) fixed the error. Fortunately, in the future, Lime will download version r11c.

[hughsando]

HXCPP should be using the latest NDK by default. Maybe openfl is setting it explicitly? You can set HXCPP_VERBOSE, which should print some info about which version it decides to use.

[player-03]

I wouldn't be surprised to find out that OpenFL sets it explicitly, but on the other hand, r8b might be the only installed version. HXCPP wouldn't download a new NDK in the middle of a build, right? I assume it'd just use what was available.

[hughsando]

No, it completely relies on the developer to install their own versions, and chooses the best of these.

On Tue, Jun 28, 2016 at 12:30 PM, player-03 notifications@github.com wrote:

I wouldn't be surprised to find out that OpenFL sets it explicitly, but on the other hand, r8b might be the only installed version. HXCPP wouldn't download a new NDK in the middle of a build, right? I assume it'd just use what was available.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/hxcpp/issues/478#issuecomment-228945487, or mute the thread https://github.com/notifications/unsubscribe/ABlp1qyqO8PME3z7Cc6_rAw569oRPZJJks5qQKNhgaJpZM4I_Vt5 .

[player-03]

OpenFL's setup process installs only r8b, so I think that explains it.

[GoKidGames]

Thanks. I'm downloading r12 now.

[GoKidGames]

r12 didn't work but r9d did, so that was the problem.

[hughsando]

Android does some strange stuff with the NDK "android-platform", (which is different from the java target version.) Ndk platform-21 introduced some problems when "atoi" and some others were no longer inlined. When you compile with 21 and run on older phone you get unresolveds. You may be able to use android-19 with r12 and get it to work, like:

<set name="PLATFORM" value="android-19" />

maybe in your hxcpp-config. I can look for a better solution if this works.

[player-03]

For the record, he tested r12 with Android 22, and r9d with Android 23. When the latter worked, he left it as-is. (He explained this to me in a PM, but I think it's worth noting for posterity.) It may be that r12+Android 23 works too.

In any case, the app now works on my Android 6.0 device, so I think you can close this.

[GoKidGames]

I should have been more clear.

I first tried NDK r12 and build failed. I then updated SDK Build Tools to 24, still failed. I then tried NDK r11c and build failed (but it could have been due to Build Tools 24) I then tried NDK r9d and build failed. I put back Build Tools to 23.0.3 and it was successful.

For all of these attempts I targeted sdk 23 <android target-sdk-version="23" if="android" /> as it was required for an extension I was using.

So, NDK r9d, Build Tools 23.0.3 and targeting SDK 23 worked.

It was a lot of downloading and extracting and I pulled an all-nighter. Sorry I didn't note the errors.

[player-03]

Ok, thanks for the clarification!

[GoKidGames]

Thanks for all your help!

[jarbot]

We're using the android-support-v7-appcompat.jar in one of our extensions. We are targeting Android 23. I've tried the following combinations so far and still getting this error:

NDK r12 & Build Tools 24 NDK r9d & Build Tools 24 NDK r9d & Build Tools 23

[jarbot]

This is the only combo thats works for me: NDK r9d and Target Android SDK 22

[alexcohn]

FWIW, Android NDK may be very unhappy if it is installed in a directory with spaces in the path name. C:\Development\Android NDK/platforms/android-9/arch-arm/usr/lib/libc.so is an indication that the TS installed NDK in C:\Development\Android NDK. I believe that many weird consequences can be avoided if simply moving it to C:\Development\Android\NDK. Note that since recently, the 'official' location for NDK is C:\Development\Android\sdk\ndk-bundle.

[Ohmnivore]

I'm trying to compile with target-sdk 26 in view of the new draconian app store policies.

It's not going very well. I tried with NDKs r8b and r9d. I tried NDK SDK targets v9, v19, and v26 (moved a few header files around for this one). Still getting the dlopen ... libc.so error.

platform-tools are v20 and build-tools are v19.1. I'll try some other tools versions.

Does anyone have a working target-sdk 26 setup?

[Ohmnivore]

I managed to get it working. Here are the exact steps I took: https://gist.github.com/Ohmnivore/39b9a6e095f804859409ed51ca5c3c1d

The issue in my case was that I was using very old Lime ndlls. I re-compiled them with a newer NDK.