Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bridge.node separated into libbridge.so and bridge.node #6

Open
skabbes opened this issue Jan 12, 2012 · 2 comments
Open

bridge.node separated into libbridge.so and bridge.node #6

skabbes opened this issue Jan 12, 2012 · 2 comments

Comments

@skabbes
Copy link
Contributor

skabbes commented Jan 12, 2012

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.

@paddybyers
Copy link
Owner

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.

@skabbes
Copy link
Contributor Author

skabbes commented Jan 12, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants