I'm not sure if this is possible, but can we separate the current bridge.node into 2 libraries libbridge.so (for Java loading) and bridge.node (for nodejs loading).
Doing so will allow us to load libbridge with the "regular" Java method System.loadLibrary so that we're not tied to the filesystem layout of /data/data which is widely supported, but technically not a requirement of an android system.
If you can make the c and c++ section work, I'll add in the Java support.
Yes, in fact this is the structure that I had originally. But in general I think there will be multiple native addons that need to be packaged with the apk, and bridge.node isn't a special case, and there will need to be a step to deploy addons from somewhere in the package to some place on the filesystem that they can execute.
So I would prefer first to find a way to avoid hard-coding the path.
Ah... agreed. We ran across the same thing. What you can do is Context.openFileOutput to write a file out, and then use Context.getFilesDir to determine what the base path for writing was.
This isn't exactly /data/data/com.company.android/your_file, I think on my phone its /data/data/com.company.android/files/your_file. I'll have to check tomorrow that this supports nested folders (which will be important for non-native addons), but the fix should be a pretty simple change to RuntimeNative.extractLib