Put native .so file into .jar?

[Nicolas Gramlich]

Hi guys,

I'm wondering if it is somehow possible to pack a the native-code (.so-
File) into a jar file.

The reason for this is that I am making a game engine (that uses a
native physics-library) and I don't want the developers have to deal
with the native-stuff at all. Right now the developers would have to
add the "engine.jar" file AND the "libphysics.so" file manually.

So is it possible to put the ".so" into the ".jar" ?

Best Regards,
Nicolas

[allstars]

you could put your so in your apk
so when your apk is installed
the so will be copied in /data/data/your_pkg_name

On Mar 21, 8:11 pm, Nicolas Gramlich <nicolasgraml...@gmail.com>
wrote:

[Nicolas Gramlich]

What I want is that the developer doesn't see the .so file anymore,
he would simply include the engine.jar and no more dealing with ".so"-
files.
(That means the ".so"-file would kind of in the jar)

Is that possible?

Regards,
Nicolas

[Ethan Rublee]

It seems that having a nice readme and copy paste or symbolic link to
your .so is simple enough.

As long as libphysics.so is in the project directory in
libs/armeabi/libphysics.so android tools automatically compiles it into
their apk. So then the user of your library just has to make sure this
is "so" and doesn't have to deal with native stuff ever again.

However when you compile a new .so, you have to tell your clients to
update their projects with the new library...

If you find a way though to include it in the jar, and have android find
it properly let me know.

Sincerely,
Ethan Rublee

[Gregory Ray]

You can not package your .so in a JAR. Also I would be willing to guess that your users want native access since it would be challenging to create a game using only java or something like lua.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Gregory Ray
COO, Seek Mobile Interactive, Inc.

---

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

[Nicolas Gramlich]

Ok, so it seems like it is not possible.
Anyway there will be a proper example-game-project to be extended ^^.

@Gregory
I really try to narrow the common end-developers interference with
native stuff down to zero.
The physics stuff is sth like: createWorld/createBox/createCircle/
setGravity/setVelocity/...
So one would probably not be able to use 100% of the stuff of the
physics engine, but enough for like 95% of the games.
(While I still could provide the sources so the .so could be
recompiled for personal needs)

Best Regards,
Nicolas

On 21 Mrz., 23:35, Gregory Ray <gr...@seekmobileinteractive.com>
wrote:

> You can not package your .so in a JAR. Also I would be willing to guess that
> your users want native access since it would be challenging to create a game
> using only java or something like lua.
>

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Ravi]

Thanks!

On Mar 21, 5:35 pm, Gregory Ray <gr...@seekmobileinteractive.com>
wrote:

> You can not package your .so in a JAR. Also I would be willing to guess that
> your users want native access since it would be challenging to create a game
> using only java or something like lua.
>

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Xavier Ducrohet]

You should try to put the .so in your jar file under the following path
/lib/armeabi/libfoo.so

The reason is that during packaging all non .class files are added to
the apk (which is really just a jar file) using the same path.
That path I mentioned above is the path where the native libraries go
in the apk.

It should work. I think.

Xav

> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.

Please do not send me questions directly. Thanks!

[Nicolas Gramlich]

Hi Xavier,

I tried it with both: "lib" and "libs" and what I get is:

for "libs/...":
[2010-03-24 11:12:51 - AndEnginePlayGround] The library
'andenginephysicsbox2d.jar' contains native libraries that will not
run on the device.
[2010-03-24 11:12:51 - AndEnginePlayGround] The following libraries
were found:
[2010-03-24 11:12:51 - AndEnginePlayGround] - armeabi/
libandenginephysicsbox2d.so

for "lib/...":
[2010-03-24 11:16:49 - AndEnginePlayGround] The library
'andenginephysicsbox2d.jar' contains native libraries that will not
run on the device.
[2010-03-24 11:16:49 - AndEnginePlayGround] Additionally some of those
libraries will interfer with the installation of the application
because of their location in lib/
[2010-03-24 11:16:49 - AndEnginePlayGround] lib/ is reserved for NDK
libraries.
[2010-03-24 11:16:49 - AndEnginePlayGround] The following libraries
were found:
[2010-03-24 11:16:49 - AndEnginePlayGround] - lib/armeabi/
libandenginephysicsbox2d.so

Both were built with ant:
#######################
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project basedir="." default="createjar" name="AndEngine">
<property environment="env" />
<property name="ECLIPSE_HOME" value="E:/eclipse/galileo-android" />
<property name="debuglevel" value="source,lines,vars" />
<property name="target" value="1.6" />
<property name="source" value="1.6" />
<property name="bin" value="bin" />
<property name="src" value="src" />
<property name="libs" value="libs" />

<property name="binfile" value="bin/andenginephysicsbox2d.jar" />
<property name="targetfile_1" value="../AndEnginePlayground/lib/
andenginephysicsbox2d.jar" />

<target name="createjar" >
<jar destfile="${binfile}">
<zipfileset prefix="libs" dir="${libs}">
<include name="**/*.so" />
</zipfileset>
<zipfileset dir="${src}">
<include name="**/*.*" />
<exclude name="**/R.java" />
</zipfileset>
<zipfileset dir="${bin}">
<include name="**/*.class" />
<exclude name="**/R.class" />
<exclude name="**/R$*.class" />
</zipfileset>
</jar>

<copy file="${binfile}" tofile="${targetfile_1}"/>
</target>
</project>
#######################
Resulting directories are (correct):
xyz.jar
+-->lib(s)
+-->armeabi
+-->xyz.so
+-->org
+-->anddev
+--> ...
+->META-INF
#######################

Any secret setting to enable or so ;) ?

Best Regards,
Nicolas

> > For more options, visit this group athttp://groups.google.com/group/android-ndk?hl=en.

[Xavier Ducrohet]

ah that's right, there's that check now.
We added that because we've seen people include jar that contains
native code compiled for windows/mac/linux.
We should at least check that it looks like a proper Android native
library and just output a warning.

I'm afraid there's no work around, you'll need to manually add the
library to the project that includes the jar file.

Xav

> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[mic _]

Doesn't Android include the APIs for reading resources from a JAR
file? If an app has permission to write to its own lib directory
(/data/data/<appname>/lib) it might be possible to extract an .so from
a JAR and write it to the app's lib directory, and then call
System.loadLibrary as normal. Just an idea.. I haven't tested it
myself.

/Michael

[Nate Pendleton]

Has there been a resolution to this? It seems stupid to disable a perfectly good feature because a couple of jackasses accidentally left Windows code in their JAR files. Does it really matter if there are extra, unreferenced bits in it anyway? It would be terribly convenient to distribute our libraries as a single JAR.

[Tom Fairfield]

Something like this: (https://bugzilla.mozilla.org/show_bug.cgi?id=588607) might work for you. 

On Wed, Dec 21, 2011 at 2:18 PM, Nate Pendleton <n8n8...@gmail.com> wrote:

Has there been a resolution to this? It seems stupid to disable a perfectly good feature because a couple of jackasses accidentally left Windows code in their JAR files. Does it really matter if there are extra, unreferenced bits in it anyway? It would be terribly convenient to distribute our libraries as a single JAR.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/inLU5f4q-HMJ.

[Alex Cohn]

On Wednesday, March 24, 2010 9:57:05 PM UTC+2, mic wrote:

Doesn't Android include the APIs for reading resources from a JAR
file? If an app has permission to write to its own lib directory
(/data/data/<appname>/lib) it might be possible to extract an .so from
a JAR and write it to the app's lib directory, and then call
System.loadLibrary as normal. Just an idea.. I haven't tested it
myself.

/Michael

This will not work, because apps don't have permission to write to /data/data/<appname>/lib... But you can write to any place that is permitted, e.g. /data/data/<appname>/files, and you can use System.load() instead of System.loadLibarry().

Enjoy,
Alex

[Doug]

You could create an android library project and have the developers add that library project to their main project.  Any native libraries in that project will be included into the main project if they have already been built into its lib directory.  It's not a neat as one jar, but it's the same way we do it for regular android library projects that export java code and resources.

Doug