This my environment:
Mac iOS: 10.10.5 Corona: Build: 2015.2785 Java 6 (default) -java version "1.6.0\_65" -Java(TM) SE Runtime Environment (build 1.6.0\_65-b14-468-11M4828a) -Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode) Java 7 -Using java version "1.7.0\_72" -Java(TM) SE Runtime Environment (build 1.7.0\_72-b14) -Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)I worked for help you to investigate the problem. In the below link (drop box) there are keystore and all apks.
I’ve created a new certificate (for_corona.keystore) with this command:
keytool -genkey -v -keystore for\_corona.keystore -alias for\_corona -keyalg RSA -keysize 2048 -validity 80000
Key Store Password is: adka_sd8jda
Key Password for <for_corona>: skd8sksad_
Build game (Horse Animation from Samples) with Corona. The app is NOT installed on 4.1.1 with this error:
java.lang.SecurityException: META-INF/TRINACRI.SF has invalid digest for assets/projects/steve\_punk/audio/project/pawn/12.mp3 in /data/app/vmdl-635292339.tmp
I’ve put this file into corona sample project because is one of the file that launch exception: but there are others files like many xml or android library files that i can’t delete or change (holo layout, holo png, …)
Build game manualy with this comad from debug apk:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore for\_corona.keystore debug.apk for\_corona
Well! In this case I can istall apk on 4.1.1 device!
Java 6 has different signature algorithm from Java 7:
in Java 6 is SHA1withRSA while in Java 7 is SHA256withRSA. So if certifcate is created with Java 6, signing with Java 7 (or with different algorithm) maybe create this problem over same Android version (4.1.1 and 2.3.3 tested).
Thank you
Examples files link:
https://www.dropbox.com/sh/e5p7qk09e85se30/AACvAUwjvlhL0lM8TpGQ4Yj0a?dl=0
I suspect that the Mac version of the Corona Simulator is failing to find the “jarsigner” on your PATH. If you install Apple’s version of the JDK, then it *will* be on your PATH and the Corona build system will be able to specify the correct encryption algorithm support by Android as a command line argument.
However, if jarsigner is *not* on your PATH, then Corona’s build system fallsback to signing your APK via “ant”, which does not support selecting the encryption algorithm. If “ant” on your system is using JDK 7 or newer, then yes, it’ll fail.
So, right, I suspect this is the issue. To verify, please do the following:
1) Open the “Terminal” app. (aka: Mac’s command line window.)
2) Type “jarsigner” at the command line and hit enter.
If the Terminal is unable to find the “jarsigner” command line tool, then that’s the issue. There are 2 ways to solve this:
Update your PATH environment variable to reference your JDK’s “bin” directory containing the “jarsigner” command line tool. Note that Corona *does* support JDK 7’s jarsigner and will correctly sign with it.
Install Apple’s version of the JDK 6. This is what most developers do, but note that your system will use that JDK version by default and not Oracle’s.
The jarsigner is just in the path.
If I run “java -version” the output is
java version "1.6.0\_65" Java(TM) SE Runtime Environment (build 1.6.0\_65-b14-468-11M4828a) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
While if I type “/usr/libexec/java_home”
/Library/Java/JavaVirtualMachines/jdk1.7.0\_72.jdk/Contents/Home
How to Corona get Java version?
Dec 17 10:38:12.614 WARNING: display.setStatusBarMode() not supported in the simulator for Custom device Dec 17 10:38:17.266 Using java version "1.7.0\_72" Java(TM) SE Runtime Environment (build 1.7.0\_72-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode) Dec 17 10:38:17.348 Picked up JAVA\_TOOL\_OPTIONS: -Duser.language=en Dec 17 10:38:17.701 Picked up JAVA\_TOOL\_OPTIONS: -Duser.language=en Dec 17 10:38:18.570 jar signed.“ant” will use the Java version that your “JAVA_HOME” environment variable references. Changing that to your JDK 6 root directory will definitely force Corona to use it and resolve the issue. Although that might have an impact on other Java dev tools that you’re using. If you do decide to change “JAVA_HOME”, then make sure to *Quit* the Corona Simulator and restart it so that it’s using your updated environment variables.
You shouldn’t theoretically have to change “JAVA_HOME” though. Having the jarsigner tool in your PATH should be enough. But I’m more of a Windows guy here at Corona Labs and not as familiar with the OS X side. (Windows actually makes this a lot easier. No environment variables required and multiple Java version installations are supported.)
But my JAVA_HOME (environment variables) is linked to Java 6, in fact certificate was created with Java 6 (keytool) from comand line.
While Corona seem to use Java 7 (linked from /usr/libexec/java_home) to sign certificate.
How to solve? Can you help me?
Corona doesn’t should use JAVA_HOME?
You just told me that your JAVA_HOME environment variable is referencing a JDK 7 directory (the “1.7” directory you posted above). I’m pretty sure that’s the problem.
Other than that, we’re running out of ideas on how to help you. We know that multiple JDK installations do work on OS X. I have a MacBook that has both JDK 6 (Apple’s version) and JDK 7 (from Oracle) installed and it builds/signs just fine. I know it does the same for others too. I’m sure you’ve found and edge of some kind, but we don’t know what it is. If it’s not your JAVA_HOME path, then you might have need to consider re-installing the JKD on your system because something about your dev environment is not set up right since it is working for others.
Ok, I’ve resolved my problem.
On Mac OX, there are two way to know Java. With JAVA_HOME variable and with /usr/libexec/java_home command.
In my environment was linked two different java versione: 6 (JAVA_HOME) and 7 (/usr/libexec/java_home).
My terminal use JAVA_HOME, so when I using keytool my system use Java 6, while Corona uses /usr/libexec/java_home to detected java version (that could be the same as JAVA_HOME) for signing apk.
Since Java 6 and Java 7 uses different signature algorithm, on some Android version (4.1.1 and 2.3.3) an apk could be not installed also the same apk is uploaded with success on Google Play Store.
Glad you figured it out. And thanks for sharing your findings. I’m sure it’ll prove useful to others.