Leveraging existing native shared lib

[cowkingxu]

Hi all,

I am a newbie of android ndk. And the question is a little bit tricky.

Say now I have a shared lib A.so.

I want to create a native wrapper B for A.so, and embed the wrapper
into the app package.

So it turns out to be:

C.java --(through JNI, System.loadLibrary(B))--> B.so --(refer to)--
> A.so

Is this OK? Say if I put A.so into /apps/<B>/project/libs/ manually.
Will A.so also be unpacked into /data/data/<app>/lib/ at installation
time by the package manager?
And if so, is B.so able to "find" A.so?

Thank you very much.

BR

[David Turner]

It won't work in Cupcake due to a bug in the dynamic linker.

More specifically, libB.so will not be loaded even if you loaded libA.so previously.

I believe this is fixed in Donut though.

Also, you need to put your libraries into $PROJECT_PATH/libs/armeabi/

to have them properly packaged in the .apk and automatically installed by the PackageManager

into /data/data/<appname>/lib at runtime.

[Shuhrat Dehkanov]

Hello David Turner

Here is a follow-up question:

In the situation of "JNI ---> libA.so ---> libB.so", what if libA.so
loads libB.so from "/data/data/<appname>/lib" (libA.so will be given
full path for loading libB.so, i.e. /data/data/<appname>lib/libB.so).

Would this also not work?
If this works both libraries can be put in $PROJECT_PATH/libs/armeabi/
and PackageManager will take care of the rest...

On Aug 28, 6:29 am, David Turner <di...@android.com> wrote:
> It won't work in Cupcake due to a bug in the dynamic linker.More
> specifically, libB.so will not be loaded even if you loaded libA.so
> previously.
>
> I believe this is fixed in Donut though.
>
> Also, you need to put your libraries into $PROJECT_PATH/libs/armeabi/
> to have them properly packaged in the .apk and automatically installed by
> the PackageManager
> into /data/data/<appname>/lib at runtime.
>

[David Turner]

The bug is really that the dynamic linker in 1.5 only looks for dependent libraries in /system/lib,

If libA.so does an explicit libB.so, this should work, but all references to libB.so functions must

be resolved through dlsym() though, which is probably more trouble than what you're asking for.

The 1.5-compatible solution is to build a single shared library (i.e. build libB as a static library,

and link libA.so to it, that's what the two-libs sample is about).