[osg-users] Android osgPlugins

[Jan Ciger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/27/2015 11:15 PM, Christian Kehl wrote:
> Hi Jan,
> 
> Your last post suggests we are talking about different
> repositories. What I did is compile osg 3.3.8 for Android using the
> cmake command line. Then, I use Rafa's osgAndroid from github. This
> package includes 4 projects: osgAndroid, osgjni, osgSimple and
> osgcamera. osgAndroid (at least for me) needs to be build with the
> NDK from the commandline (within Eclipse it doesn't work for me)
> using ndk-build. It shall compile a java library (.jar) using the
> static c++ libraries from osg 3.3.8. The osgSimple has osgAndroid
> as a dependency and shall hence include the jar in its apk.

Aha, ok, that clarifies things then. I was getting confused, because
osgSimple isn't included with stock OSG as Android example, there was
an example like that only for the desktop.

> Until there, it works for me. Thing is: the apk of osgSimple does
> not include the static osg 3.3.8 c++ libraries, which is why my
> logcat tells me on execution that it cannot find the libraries ...

That's wrong - apk has no reason to include *static* (.a) libraries,
those can not be loaded at runtime. Static libraries are only used for
compilation/linking, never for execution. The apk could contain only
dynamic libraries (.so) if it is an application with native code.

> 
> What I hassle to achieve for now 2 months is just to get a working 
> osg Android render application (preferably from source) that can
> load an osg/ive file and which I can modify for rendering,
> interaction and data modification ...

Yeah, I feel your pain. Native Android development can be enormous
pain the backside, unfortunately.

> 
> With respect to my environment, I have some shell scripts that 
> initialize my environment (PATH- and LD_LIBRARY_PATH variable) so 
> that any linking command takes the right libraries for a
> particular architecture (web, desktop, android, etc.). Only thing
> is that eclipse seems to gently ignore these paths when building
> the apk for osgSimple - or there is a problem with the make files
> in general.

Those paths are for HOST binaries (PATH) and HOST shared libraries
(LD_LIBRARY_PATH - Linux doesn't use PATH to look for DLLs, unlike
Windows), not for Android. It wouldn't make sense for Eclipse/ADT to
look there, because those libraries wouldn't work on Android anyway
(different OS/CPU architecture). So that is normal that they are ignored
.

> Fact stays: the osgSimple application does not include the static
> osg c++ libraries it needs in order to load files, create a render 
> context or anything. The apk includes the osgAndroid jar file from 
> the relative path written in the Android.mk file. That is why 
> building the apk works fine, because the java functions can be 
> referred. The jar-file of osgAndroid compiles and links to the
> static c++ libraries on the computer. For one reason or another, it
> does not "package" them, so the static c++ libraries are missing
> when the jar is transmitted to the phone ...

That jar file is actually an archive (it is basically a zip file, you
can unzip it) and it likely contains the shared libraries that
implement the JNI "shim" code + any dependencies they may have.

Unless you are not writing an entire Activity/app in native code then
the native Android apps are always a mixture of Java and C/C++. They
work in such way that you declare some methods in the Java class as
"native" and then you must provide a "shim" that implements them in
C/C++ using the JNI interface. That is then compiled into a shared
library and loaded from your Java class, you will find something like
this in the code:

static {
    System.loadLibrary("mylib");
}

The Java Virtual Machine (or rather Dalvik/ART) loads the shared
library when this class is instantiated and makes the implementation
of the class "complete", so that the native methods can be actually
called.

The shim code can then call external C/C++ libraries when called from
Java, such as OSG.

The deal with the OSG static libraries and plugins is that they need
to be *linked* to the shim code (which becomes a shared/dynamic
library itself), so that there is no need to dynamically load them in
runtime. Only the shim will be preloaded by the virtual machine. This
is why you won't find the static .a files in the jar/apk file - they
are never deployed to the device, only inside of the shared library.

The reason for this solution was that there were problems to deploy
the plugins in the correct path so that they are actually found at
runtime, it was a consequence of how Android deploys applications. It
is/was basically a workaround for Android behaviour, nothing more. I
am not sure whether it is still necessary or not, but linking the OSG
bits statically to the JNI shim is a safe way to avoid runtime issues.

Regards,

jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVZkfrn11XseNj94gRAkrXAJ471ufs6o1/C1LVwCn3HHIKnH1+YgCcDLar
s1X+r2ygBtn9xhv4MxXDjKE=
=cQ73
-----END PGP SIGNATURE-----