Native activity and "inability to load the native library"
I am trying to create a native Android-10 NDK activity based on a "native-activity" sample project from the Android NDK folder. However, when I open Eclipse my work activity crashes with the following exception: select "Run As -> Android Application" for my project:
02-09 03: 02: 12.599: E / AndroidRuntime (881): java.lang.RuntimeException: Cannot start Activity ComponentInfo {com.example.native_activity / android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/app-lib/com.example.native_activity-1/ [library name] .so
However, I have confirmed that the file "lib [library name] .so" already exists in the paths "libs / armeabi" (etc.). My own activity should end up loading three ".so" files, but this error persists whether I try to load one ".so" file or all three ".so" files. My "AndroidManifest.xml" file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<!-- BEGIN_INCLUDE(manifest) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.native_activity"
android:versionCode="1"
android:versionName="1.0">
<!-- This is the platform API where NativeActivity was introduced. -->
<uses-sdk android:minSdkVersion="9" />
<!-- This .apk has no Java code itself, so set hasCode to false. -->
<application android:label="@string/app_name" android:hasCode="false">
<!-- Our activity is the built-in NativeActivity framework class.
This will take care of integrating with our NDK code. -->
<activity android:name="android.app.NativeActivity"
android:label="@string/app_name"
android:configChanges="orientation|keyboardHidden">
<!-- Tell NativeActivity the name of or .so -->
<meta-data android:name="android.app.lib_name"
android:value="[library name]" />
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
<!-- END_INCLUDE(manifest) -->
What should be done to fix this exception at runtime?
The problem is that the system is looking for a library with -1 appended to its name
(from your error message) /data/app-lib/com.example.native_activity-1
I've seen andoird do this when the library already exists and then adds -1, -2, etc. Not sure why, but sure if this is a version that you can solve with an uninstall or fresh install.
source to share
A useful way to find more information about loading failure is to create a basic Android app and use it System.loadLibrary
to load native libraries into a method onCreate
, in general bypassing NativeActivity.
eg.
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
System.loadLibrary("foo");
System.loadLibrary("bar");
System.loadLibrary("depends-on-foo-and-bar");
}
Then instead of getting the not-so-useful message "Unable to load native library" that NativeActivity provides, you get a more useful message like
java.lang.UnsatisfiedLinkError: dlopen failed: Could not load library "lib42.so" required by "libdepends-on-foo-and-bar.so"; called by library "lib42.so" not found
source to share
Not sure what the problem is, but this solution was the solution for me! https://mega.nz/#!p4lFlCZR!TFsb8dMqNdAJjKoCDPDDvNtcQdEB0-KkVlTgQVwG20s
source to share
This is due to the lack of dependencies (or even implementations). You may be getting "unable to load library: libFoo.so", but the missing real dependency could be libBar.so, which libFoo.so depends on. Or, you can just declare functions and call them, but have no implementation for them.
The problem has to do with how such a file works. When you create a shared object using gcc, the link step is not really done. For example, in libFoo.so, you can declare the prototype myFunc () and call it. And you can skip the myFunc () {} implementation. Gcc will happily create a .so file for you. And it will happily end in the pharmacy. However, when the library load time, it will break with the message "unable to load library".
There are two ways to handle this: you either do what AndrewJC tells you in his answer. Or you start commenting out the code until you can download it again. So no implementation of the function could be found.
IMPORTANT: The -1 -2 suffixes that are added to such files are NOT a problem. This comment misled me after spending a few days only to find that these numeric suffixes are actually the expected behavior of the Android Package Manager.
source to share