Gluegen apk won't install on Android 6 (Marshmallow)

Hi,
I had the Jogl tests running very nicely on my Android phone (HTC M8) last year, the Jogl's Version app was a handy way to see the capabilities of my phone.

However after my phone upgraded to Android 6 Marshmallow none of the Jogamp apps ran anymore with the message  "Unfortunately Jogamps's Jogl Library has stopped"

So I tried to un-install and re-install the apk files using adb, which worked perfectly last time.

The jogl-all-android-armv6.apk and jogl-test-android.apk install without complaint and the icons appear.

However when installing gluegen using this command:
C:\Users\phil\AppData\Local\Android\sdk\platform-tools>adb install c:\temp\jogamp-all-platforms\apk\jogamp-android-launcher.apk

I get this output:
1035 KB/s (33146 bytes in 0.031s)
        pkg: /data/local/tmp/jogamp-android-launcher.apk
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]\

The jogamp files are the latest from here
https://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z

So obviously I manually sign the apk file and run zipalign as the internet tells me to
I even run:
"C:\Program Files\Java\jdk1.8.0_25\bin\jarsigner.exe" -verify -verbose -certs c:\temp\jogamp-all-platforms\apk\gluegen-rt-android-armv6.apk

And it says it can see certificates, and it looks very similar to the jogl-all-android-armv6.apk verified output.

However it still gives me the [INSTALL_PARSE_FAILED_NO_CERTIFICATES] error when I attempt to install.

Given that there is no mention of problems elsewhere on the internet I presume I've done something wrong.

Does anyone have any ideas about what my next steps might be?

Hi

Maybe we'll have to sign anew our packages, I assume that the root cause is this further:
http://stackoverflow.com/a/10083307
http://stackoverflow.com/a/9567153
https://bz.apache.org/bugzilla/show_bug.cgi?id=52344

Julien,
Thanks for the quick reply.
I did come across the 2 sites you referenced, and I just retried signing and installing with the -sigalg MD5withRSA as the latter site mentioned but it still refuses to install for me, so I'm not sure that's the problem.

here:
http://developer.android.com/tools/publishing/app-signing.html#signapp
It only mentions -sigalg SHA1withRSA

Ok :s Please fill a bug report, be very accurate, provide some logs (use LogCat for example).

In case anyone else strikes this certificates issue with gluegen-rt-android-armv6.apk not installing on Android 6 here is how I worked around it in order to get the Jogl Version Info to show up.

What I describe below is NOT how to get things done properly, it fixes nothing and sheds no light on the signing issue described above, it is just an option if you are stuck (like I was).

Here is how things are done properly, along with explanation
https://jogamp.org/wiki/index.php/Maven_And_Android

Below is just my ramblings...

Install Android Studio (this takes a while, update everything to the newest)
(Note Android Studio uses Gradle not Maven)

I decided to start from a base of the example jp4da project (here) under maven/jp4da, in theory if you know Android coding well a new project would be just as quick.

I put the jp4da project in a temp folder and in Android Studio used "New->Import Project" on it to get it in.

I changed gradle.build and androidManifest.xml to use minSdkVersion 23 and targetSdkVersion 23 (23 is Android 6)

I put the Example.Java file from core into this project next to MainActivity.Java (this is simpler than a two project solution)

For the life of me I could not get gluegen to load the *.so files, I couldn't even wrestle android studio to include the *.so files in the generated apk.

I found and followed these instructions:
http://stackoverflow.com/questions/16683775/include-so-library-in-apk-in-android-studio/17131418#17131418

Note that below I'm using the armv6 version of files you may need to use aarch64 depending on your target platform (if you do it will change the folder name to lib/arm64-v8a)

I extracted jogamp-all-platforms (here) into a temp folder.

I took libgluegen-rt.so from gluegen-rt-android-armv6.apk (found in the jogamp-all-platforms/apk folder)
and libjogl_mobile.so and libnewt.so from jogl-all-android-armv6.apk

I put these in a jar file with the correct structure (lib/armeabi), as described in the stackoverflow link above.

I put that jar with jogl-all-android.jar and gluegen-rt-android.jar all into libs folder and in Android Studio I right clicked "add library" on each

I updated gradle.build with "compile fileTree(include: '*.jar', dir: 'libs')"

Then I fixed up the use of System.err to Log.e and e.getPressure() > 2f to e.getPressure(true) >0.4f in MainActivity.java and Example.java

Then I ran it and got a lovely blue screen, which meant success.

Finally I commented away the onCreate method of MainActivity and made the class declaration this:
public class MainActivity extends NewtVersionActivity {//NewtBaseActivity {

Then I ran it and got the Jogl Version Info screen!

For reference my AndroidManaifest.xml looks like this

<?xml version="1.0" encoding="utf-8"?>
<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.io7m.examples.jp4da"
  android:versionCode="1"
  android:versionName="1.0">
    <uses-sdk android:targetSdkVersion="23" android:minSdkVersion="23"/>
  <application android:label="@string/app_name" android:icon="@drawable/ic_launcher">
    <activity android:name="MainActivity" android:label="@string/app_name">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
</manifest>

and my Gradle.build looks like this

apply plugin: 'com.android.application'
android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"

    defaultConfig {
        applicationId "com.io7m.examples.jp4da"
        minSdkVersion 23
        targetSdkVersion 23
        compileOptions {
            sourceCompatibility JavaVersion.VERSION_1_7
            targetCompatibility JavaVersion.VERSION_1_7
        }
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        }
    }
}

dependencies {
    compile files('libs/jogl-all-android.jar')
    compile files('libs/gluegen-rt-android.jar')
    compile fileTree(include: '*.jar', dir: 'libs')
    compile files('libs/jogl-test-android.jar')
}

Thank you and sorry for the lack of documentation.

No problems, just thought it might save people some time.

I did have quite a lot of trouble getting things going on android 6 (API 23) because they've utterly changed the permission system, but hardly any forums talk about, so I'm wondering if that's involved somehow. If I get time to investigate I'll see if I can work out how to make it go properly.

Continuing from stackOverflow, which IDE do you use, Kevin?

Hey, it's Kevin from SO.  I use IDEA almost exclusively.  I have a bunch of questions, but I thought it would be good to start with a little background about how I became interested in JOGL.

I'm a professional Android developer whose day job mainly involves boring point-of-sale stuff.  I decided to learn about OGL and read a few books and tutorials about how it's done with the android.opengl.* APIs.  I quickly realized that Google made a big mistake by not using interfaces for their GLES2+ APIs.  They included the Khronos GLES1 interfaces in the standard Android API, but starting with GLES2, everything is done with static methods.  I found JOGL when I went looking for a library that uses interfaces.

Questions:

- What are the JOGL equivalents of GLSurfaceView and GLSurfaceView.Renderer?  (GLSurfaceView is the Android-managed view that holds the GL surface; Renderer is the callback that is called when the GL context is created and when each frame is rendered, among other things.)

- Can a JOGL surface be declared in layout XML?

- Is it possible to use JOGL without extending a particular Activity?  (Early versions of some Google APIs used required extending activities, like MapActivity and PreferenceActivity, but this proved to be a very restrictive anti-pattern, and newer versions have moved away from it.)

- What does a minimal JOGL "Hello, world!" look like?  I mean something like an empty black screen rendered with OGL.

- Why are there multiple native jars for each architecture?  What's in them, and are all of them always required?

- Why do some tutorials suggest that JOGL apps require other APKs to be installed alongside them?  Can this be avoided?

- Why does gluegen parse C headers instead of the Registry XML from which the C headers are derived?  Was the XML not available when gluegen was originally created?  Would gluegen benefit in any way from being converted to use the XML?

- I noticed from reading the code that JOGL relies on global state.  Global state is especially evil on Android because of the way the framework manages activities and other components.  I also noticed some comments hinting at problems caused by this.  Could this be avoided without breaking compatibility with other platforms that JOGL supports?

kjkrum wrote

- Why does gluegen parse C headers instead of the Registry XML from which the C headers are derived?  Was the XML not available when gluegen was originally created?  Would gluegen benefit in any way from being converted to use the XML?

- I noticed from reading the code that JOGL relies on global state.  Global state is especially evil on Android because of the way the framework manages activities and other components.  I also noticed some comments hinting at problems caused by this.  Could this be avoided without breaking compatibility with other platforms that JOGL supports?

I don't know much about the Android  stuffs but I think I can give a hint about these two.

Gluegen is a java<->C binding. OpenGL (and it's versions like GLES2) are published as a specification document and the platform driver (windows OSX et c) provides implementations of the specification with C-headers. JOGL is 'simply' a Java binding to the OpenGL C API.

OpenGL has global state, maybe it is this you are referring to? Nothing JOGL can do about it, this is the way OpenGL is specified and the state is maintained in the graphics driver.

kjkrum wrote

- What are the JOGL equivalents of GLSurfaceView and GLSurfaceView.Renderer?  (GLSurfaceView is the Android-managed view that holds the GL surface; Renderer is the callback that is called when the GL context is created and when each frame is rendered, among other things.)

com.jogamp.newt.opengl.GLWindow and com.jogamp.opengl.GLEventListener?

kjkrum wrote

- Is it possible to use JOGL without extending a particular Activity?  (Early versions of some Google APIs used required extending activities, like MapActivity and PreferenceActivity, but this proved to be a very restrictive anti-pattern, and newer versions have moved away from it.)

I don't think that it's possible, you have to use jogamp.newt.driver.android.NewtBaseActivity. Maybe Sven can confirm.

kjkrum wrote

- What does a minimal JOGL "Hello, world!" look like?  I mean something like an empty black screen rendered with OGL.

It's not that big:
https://github.com/sgothel/jogl/blob/master/src/test/com/jogamp/opengl/test/android/MovieCubeActivity0a.java

kjkrum wrote

- Why are there multiple native jars for each architecture?  What's in them, and are all of them always required?

We need different native libraries to support different architectures. They aren't all required, it depends on what you use. If you don't use AWT (typically unsupported under Android), you can drop some stuff.

kjkrum wrote

- Why do some tutorials suggest that JOGL apps require other APKs to be installed alongside them?  Can this be avoided?

Because it's the case but you can create a single APK containing JOGL, (JOAL, ) GlueGen and your own program.

kjkrum wrote

- Why does gluegen parse C headers instead of the Registry XML from which the C headers are derived?  Was the XML not available when gluegen was originally created?  Would gluegen benefit in any way from being converted to use the XML?

I'm not sure that those XML registers existed when GlueGen was created and anyway, JOGL is mostly a Java binding, it calls the native OpenGL / OpenGL ES methods.

kjkrum wrote

- I noticed from reading the code that JOGL relies on global state.  Global state is especially evil on Android because of the way the framework manages activities and other components.  I also noticed some comments hinting at problems caused by this.  Could this be avoided without breaking compatibility with other platforms that JOGL supports?

jmaasing is right, there is nothing that we can do. OpenGL itself relies on global states. We do our best.