Hi,
I’m trying to run app on my nexus 5
in adb logcat noticed errors like (in few places):
10-30 21:36:58.042 11191 11191 W System.err: dlopen failed: library "/home/joshua/Development/Android/android-ndk-r8b/platforms/android-9/arch-arm/usr/lib/libc.so" not found
and screenshot from android:
➜ ~ haxelib list
actuate: [1.8.6]
box2d: [1.2.3]
hxcpp: [3.2.180]
layout: [1.2.1]
lime-samples: [2.6.0]
lime: [2.7.0]
openfl-samples: [3.3.1]
openfl: [3.4.0]
swf: [2.1.2]That’s bizarre. Has anyone else ever had an error like this one?
There might be something wrong with Android template.
In my fork, I got merge conflict when I merged 2.7.0 as I updated template by myself, so I just selected mine. As a result I didn’t see error like that.
It shouldn’t be the template – that includes the Lime binary, and other additional binaries used by the project (HXCPP standard or extension binaries) but we don’t include libc on any builds, this should be on the system
I just ran into this myself.
I have a Nexus 7 running Android Marshmallow. Previously I was targeting SDK 17 with Java 6, which was fine. Our publisher required an upgrade to sdk 23. So I targeted SDK 23 with Java 7 (the output heavily suggested I upgrade the compiler)
After fixing a few build errors I was able to push to my device, but it crashes on startup with the following error:
FATAL EXCEPTION: main
11-05 13:28:18.915 3097 3097 E AndroidRuntime: Process: com.armorgames.sodadungeon, PID: 3097
11-05 13:28:18.915 3097 3097 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: library “/home/joshua/Development/Android/android-ndk-r8b/platforms/android-9/arch-arm/usr/lib/libc.so” not found
It would seem a similar issue was detailed here?
https://code.google.com/p/android-developer-preview/issues/detail?id=2150
Please also note that I’m using an older version of openFL [2.2.5] but considering OP is using [3.4.0] I assume that isn’t the issue.
An update: I am able to build to SDK 22 just fine. I’m thinking that maybe a change in the permissions system for SDK 23 is to blame, but I can’t really say for sure at this point.
Ah, so its reproducible. I’ll put it on the TODO list to look into, I haven’t tried the newer SDK, probably explains why this hasn’t come up 
I may have found some clues as to why SDK 23 breaks things:
This release updates the behavior of the dynamic linker. The dynamic linker now understands the difference between a library’s soname and its path ( public bug 6670), and search by soname is now implemented. Apps which previously worked that have bad DT_NEEDED entries (usually absolute paths on the build machine’s file system) may fail when loaded.
The dlopen(3) RTLD_LOCAL flag is now correctly implemented. Note that RTLD_LOCAL is the default, so calls to dlopen(3) that didn’t explicitly use RTLD_LOCAL will be affected (unless your app explicitly used RTLD_GLOBAL). With RTLD_LOCAL, symbols will not be made available to libraries loaded by later calls to dlopen(3) (as opposed to being referenced by DT_NEEDED entries).
On previous versions of Android, if your app requested the system to load a shared library with text relocations, the system displayed a warning but still allowed the library to be loaded. Beginning in this release, the system rejects this library if your app’s target SDK version is 23 or higher. To help you detect if a library failed to load, your app should log the dlopen(3) failure, and include the problem description text that the dlerror(3) call returns. To learn more about handling text relocations, see this guide.
http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime
Of these clues, the “no text relocations” seems the most likely. I remember seeing warnings about text relocations before? Though odd that it fails on libc – that’s really outside of our control.
According to Twitter, a new Android NDK resolves this problem:
Can anyone confirm?
Some more information:
OS X Yosemite 10.10.5
XCode 7.1.1
OpenFL 3.3.9
Lime 2.6.9 (from git), compiled with lime rebuild android -Dlegacy
android-sdk 24.4.1 (from homebrew)
android-ndk r10e (from homebrew)
Thanks! New versions are now live, using r10e as the NDK on our build server, hopefully this should be set
I’m on NDK r11 and I’m getting this error 
<android target-sdk-version="23"/>
<android build-sdk-version="23"/>
java.lang.UnsatisfiedLinkError: dlopen failed: library "/home/joshua/Development/Android/android-ndk-r8b/platforms/android-9/arch-arm/usr/lib/libc.so" not foundedit: Should I rebuild lime?
I’ve updated lime to 2.9 and I think the error is gone.
I’m running into the exact same error, unfortunately.
Updated everything to the latest (except JDK, still using 6u45), but it did not solve the issue…
Android NDK r11c
Android SDK Tools 25.1.7
Android Platform Tools 23.1
Android Build Tools 23.0.3
Android SDK Platform 23 r3
Apache Ant 1.9.7
Haxe 3.3.0
Lime 2.9.1
OpenFL 3.6.1
Looks like the SimpleOpenGLView sample runs okay in the emulator.
My project also includes nape, extension-admob, and ganalytics. Not sure if one of those has anything to do with it…
Okay, I think I finally solved the issue I was having…
Through process of elimination, I figured out that ganalytics was the culprit. Turns out it just needed to be recompiled (makes sense), though using lime rebuild ganalytics android like it said to do in its readme didn’t do the trick – I had to haxelib run hxcpp Build.xml -Dandroid -DHXCPP_ARMV7 instead.
I also updated JDK to the latest (8u92) and everything built fine (including release signing). The builds are also much faster! Used to take 2.5-3 mins to build/deploy changes to my phone, and now it only takes 45 seconds!! (The total build time JDK reports right before deploying went from 1.5-2 mins, down to just 15 seconds!)
Maybe it’s time to update the Android setup instructions to finally stop using 6u45 and instead switch to the latest as one other user has also reported that JDK 8 works fine for building/signing.
Hello… I have an android apk running fine compiled with the following version:
openfl: 4.4.0
Lime: 3.4.1
hxcpp: 3.4.43
However when the client tried the apk on a Hawei mate9 it throwns an error DEtected problems with app native libraries. libApplicationMain.so Invalid DT_NEEDED entry d:\androidSDK\android-ndk-r8b …
I tried the following:
openfl setup android, and set the directory to d:\androidSDK\android-ndk-r13b
openfl clear android
openfl test android
(nothing changes, still compiles using d:\androidSDK\android-ndk-r8b)
Manually edit Users\myUser.lime\config.xml and set the ndk directory to d:\androidSDK\android-ndk-r13b
Same result… still compiles using d:\androidSDK\android-ndk-r8b
then I tried,
haxelib update
it downloads and installs
openfl: 4.9.1
Lime: 4.0.1
hxcpp: 3.4.64
openfl clear android
openfl test android
(compiles using d:\androidSDK\android-ndk-r8b) and application stops working.
If someone can give me a clue on how to proceed I would really appreciate. I come from flash world, so all this version and compiler options are a complete mess for me.
We have seen issues using newer Android devices, with the older Android NDK. In order for it to work properly, all binaries (Lime, HXCPP and your application) must be compiled with a newer NDK.
Perhaps this version of Lime is older than when we updated our toolchain to use a newer NDK for the official builds?
do you recomend to make a clean install of everything from scratch?
How can I create all binaries using new ndk?
as I said:
I tried the following:
openfl setup android, and set the directory to d:\androidSDK\android-ndk-r13b
openfl clear android
openfl test android
(nothing changes, still compiles using d:\androidSDK\android-ndk-r8b)
Manually edit Users\myUser.lime\config.xml and set the ndk directory to d:\androidSDK\android-ndk-r13b
Same result… still compiles using d:\androidSDK\android-ndk-r8b
Lime configures settings in “C:\Users<your user name>.lime\config.xml”, but it’s possible that HXCPP has a setting that is overriding your choice in Android NDK.
Check “C:\Users<your user name.hxcpp-config.xml” as well. You may be able to delete or update the Android NDK path set there
That might be enough, but if it is not, you will need to either update, or clone Lime from the source (at your same version) and rebuild it yourself.
