Loading native libraries under Android

414 views
Skip to first unread message

Gili

unread,
Jul 11, 2012, 10:44:32 AM7/11/12
to jna-...@googlegroups.com
Hi Timothy,

We need to discuss native libraries under Android in more detail because I believe we're going to have to handle it totally different than under other platforms.

First of all, I'd like to recommend you roll back https://github.com/twall/jna/commit/57ded8d80316563f336a6ed7ccdc141e0c15734e

Here's the deal: Android points "java.io.tmpdir" somewhere on the SDCard. It flushes this directory every time the phone is rebooted so it is ideal for temporary files. However, Android will also refuse to load native libraries from this path hence the "temporary files directory" cannot be equal to "native library directory" under Android (whereas this is the case on other platforms). The aforementioned commit won't work because it forces users to use one path for both.

Next, I don't believe we'll be unpacking native libraries under Android at all (whereas this is still the case in other platforms). To understand why, please download the NDK from http://developer.android.com/tools/sdk/ndk/index.html and read CPU-ARCH-ABIS.html.

Users will need package JNA's native libraries under lib/<api>/lib<name>.so and Android will unpack the correct API at installation time (*not* runtime). JNA will then invoke System.loadLibrary() and everything should work as expected. Please let me know what you think.

PS: See https://groups.google.com/forum/?fromgroups#!topic/android-ndk/WKxuYwU5moQ for a related discussion on the Android-NDK discussion group.

Thanks,
Gili

Timothy Wall

unread,
Jul 11, 2012, 6:20:04 PM7/11/12
to jna-...@googlegroups.com

On Jul 11, 2012, at 10:44 AM, Gili wrote:

> Hi Timothy,
>
> We need to discuss native libraries under Android in more detail because I believe we're going to have to handle it totally different than under other platforms.
>
> First of all, I'd like to recommend you roll back https://github.com/twall/jna/commit/57ded8d80316563f336a6ed7ccdc141e0c15734e
>
> Here's the deal: Android points "java.io.tmpdir" somewhere on the SDCard. It flushes this directory every time the phone is rebooted so it is ideal for temporary files. However, Android will also refuse to load native libraries from this path hence the "temporary files directory" cannot be equal to "native library directory" under Android (whereas this is the case on other platforms). The aforementioned commit won't work because it forces users to use one path for both.

JNA only uses its temporary directory for unpacking the native library, so there isn't a conflict. However, given your comments below, I believe the point is moot.

>
> Next, I don't believe we'll be unpacking native libraries under Android at all (whereas this is still the case in other platforms). To understand why, please download the NDK from http://developer.android.com/tools/sdk/ndk/index.html and read CPU-ARCH-ABIS.html.
>
> Users will need package JNA's native libraries under lib/<api>/lib<name>.so and Android will unpack the correct API at installation time (*not* runtime). JNA will then invoke System.loadLibrary() and everything should work as expected. Please let me know what you think.
>
> PS: See https://groups.google.com/forum/?fromgroups#!topic/android-ndk/WKxuYwU5moQ for a related discussion on the Android-NDK discussion group.

So the loadNativeLibraryFromJar() function should simply fail, right? since apparently it's not an option.

cowwoc

unread,
Jul 11, 2012, 8:33:02 PM7/11/12
to jna-...@googlegroups.com
Hi Timothy,

On 11/07/2012 6:20 PM, Timothy Wall wrote:
> JNA only uses its temporary directory for unpacking the native library, so there isn't a conflict. However, given your comments below, I believe the point is moot.
I believe it attempts to load the library from the same directory
it unpacks it to but yes the point is moot on Android because we should
be using the APK mechanism for native libraries (if possible).

> So the loadNativeLibraryFromJar() function should simply fail, right?
> since apparently it's not an option.

Yes. That is correct.

Gili
Reply all
Reply to author
Forward
0 new messages