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`. 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
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
and
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
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
