On Mon, Aug 26, 2013 at 9:19 AM, Nick Alexander <[email protected]>wrote:
> On 13-08-25 10:58 PM, Caleb wrote: > >> Hi Nick, >> >> Thanks for the quick response! I edited the files as recommended--I also >> had to put the .so file in objdir-droid/dist/bin and re-run `./mach >> package`, but once that was done, I had a shiny .apk with the additional >> library in the assets folder. Thanks! >> > > Huzzah! > > > Still getting library load failures, though, so the journey continues. >> My current guess is that the auth extensions are looking at the contents >> of the `lib/armeabi-v7a/` folder instead of `assets` folder of the >> Android package file. Do you happen to be able to confirm/deny that guess? >> > > There are a few reasons this could happen, but I'll need to know how > you're loading the library in order to help diagnose. If you can post your > patches and a link to your APK, that would help. > > You are correct that loading a native library via System.loadLibrary() > will expect the library in the `lib/$ABI`. So far I've managed to avoid modifying the code base at all, except for the previously mentioned packaging edits. Here's the library loading code: http://mxr.mozilla.org/mozilla-central/source/extensions/auth/nsAuthGSSAPI.cpp#130 This code calls PR_LoadLibrary, which eventually ends up here: http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/linking/prlink.c#642 So it seems the system call in question is dlopen(). Hopefully the same expectations about file locations apply--I haven't been able to find much information about how dlopen handles relative paths in Android. I'll know more once I've tried packaging the .so file in `lib/$ABI` instead of `assets` > But if you're loading via Gecko, everything should be relative to > libxul.so. You could add some test code around > > http://mxr.mozilla.org/**mozilla-central/source/** > mozglue/android/APKOpen.cpp#**167<http://mxr.mozilla.org/mozilla-central/source/mozglue/android/APKOpen.cpp#167> > > to manually load your library. If it still doesn't load, we might have a > zip formatting issue; the loader expects libraries to be szipped and > zip-stored (not zip-compressed). But I think the packager should arrange > this all for you. > > You could also test loading via ctypes and JNI; see, for example > > http://mxr.mozilla.org/**mozilla-central/source/mobile/** > android/modules/JNI.jsm<http://mxr.mozilla.org/mozilla-central/source/mobile/android/modules/JNI.jsm> > > and > > http://mxr.mozilla.org/**mozilla-central/source/mobile/** > android/base/tests/testJNI.js<http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/tests/testJNI.js> > . > > I will be only intermittently checking email for the next week, so delays > might be replied. > > Best of luck, > Nick > Thanks for the info! -Caleb
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
