Posted by Sven Gothel on Feb 12, 2012; 9:20pm
URL: https://forum.jogamp.org/Migrate-a-Java-application-using-Jogl-to-Android-tablet-tp3732586p3738415.html

On 02/12/2012 09:40 PM, mimou [via jogamp] wrote:
>
>
> I'm using GL2 in my application.

You will need to utilize GL2ES2 only in your application
to be able to use GLES2 on your mobile device.

GLES2 (see the UML diagram, classes, specs) excludes the fixed function
pipeline of GL2 and the other compatibility profiles
(it's a subset so to speak).

> I tried to build your demo but it's a bit tricky. I had to download gluegen
> from the repository because ant tasks depends from gluegen build tasks.
> Is -it possible to deploy your demo's apks using eclipse as any android
> project ?

Even though I use Eclipse as an editor and refactoring tool,
I haven't yet tried it with Eclipse as a deployment tool, sorry.
For sure .. this is something we should do - ie. test it etc.
For now, we just use ant and deploy the 'apk's manually.

Rami started using the Eclipse / Android tool chain
before Siggraph last year .. but other work hindered him to finish it.

>
> I tried also to create a single apk using your jars but it is impossible to
> deploy such a big apk.  Can you give some details about how the apks share
> data ?

Right, we don't use a single APK - since we love reusing our stuff.
We managed to daisy chain the APK's (JARs and native libraries)
via our jogl.android-launcher.apk.

When looking into our demos, ie. 'NEWTLauncherGearsES2Activity',
you learn that we provide a common subclass
'com.jogamp.android.launcher.NEWTLauncherActivity' which handles
all required task: loading APKs (gluegen, jogl, 'user apk') and
kicking off the activity derived from 'jogamp.newt.driver.android.NewtBaseActivity'.

[1] NEWTLauncherActivity loads the APKs while creating a new ClassLoader via
  cl = ClassLoaderUtil.createJogampClassLoaderSingleton(this, getUserPackageName())

[2] getUserPackageName() is simply overridden by the demo's activity, ie
'NEWTLauncherGearsES2Activity' returns 'com.jogamp.opengl.test',
our jogl.test.apk's package name.

[3] NEWTLauncherActivity then uses the new ClassLoader to instantiate your
NewtBaseActivity's subclass and delegates all Activity calls to it!

+++

Current sub optimal situation:

By now you might have seen that you would need to
provide 2 APKs:

[u1] Your demo launcher APK, which needs to include code of our
     NEWTLauncherActivity and it's dependencies,
     so you will be able to actually daisy chain the components.
     Here you will also place your NEWTLauncherActivity's subclass
     which names your actual demo Activity (NewtBaseActivity subclass)
     and it's demo APK.
     You also need to drop all the XML resource files here.
     Classes within this package don't have direct access
     to JOGL/NEWT.

[u2] Your demo APK, which is a subclass of NewtBaseActivity.
     The demo APK is almost Android agnostic and you have full
     access to the JOGL/NEWT API, meaning your normal GLEventListener
     code shall work w/o changes when using NEWT.

Ours 2 APKs in this regard are:
     jogl.android-launcher.apk
     jogl.test.apk

This complication is due to the described daisy chaining
and using API compatible code. There is a version of class loading
around which replaces the system classloader .. however it uses
some peek & poke heavily and is not compatible.

http://forum.jogamp.org/Android-Test-APKs-201110080141utc-td3404613.html

I will look into this process this week, maybe we can simplify it a bit.
Maybe we can make the launcher a bit more generic, so one can just repack it
with a custom XML file (to name the NewtBaseActivity subclass and it's APK).

Hope this elaboration helps a bit.

~Sven

>
> Regards,
> Mimou
>