So I have a legit keystore, I even used the Unity interface to create a new key in it, and it picks it up. So my passwords are correct. But when I try to sign my APK I get this error in an alert box:
Error building Player: UnityException: APK Signing Failed!
Failed to sign APK package. See the Console for details.
When I check the console, all it says is that. No information. Where can I find out why the APK signing process is failing?
Check to make sure debug is unchecked.
Double check that the keystore file is loaded correctly before you sign.(Sometimes I’ve noticed that even though I click on the keystore file
it doesn’t load)
Make sure you select the correct alias before puting in your password.
I assume you mean “Development Build” is unchecked? Yeah that’s unchecked.
The keystore is loaded as far as I can tell–when I browse, and then pick the alias there’s a pause and all the aliases show up. Still doesn’t work.
This problem was discused somewhere else here in the forum. It has somethig to do with the Path to the Java JDK and the JAVA_HOME Enviromentvariable wasn’t either set or points to a wrong directory.
Hit Win+Pause > Advanced/Extended Systemsettings (dunno the exact term, got german Windows here) > Extra > Enviromental variables > in “User Variables for ” list look for JAVA_HOME and change it to the path where your JDK is installed (the bin folder, i.e. C:\Program Files\Java\jdk1.6.0_20\bin\ )
As far as I can tell, both passwords are correct. I even created a new one and made sure I had the password correct to no avail. I at least know the keystore password is correct because it shows the aliases. But I’m pretty sure the alias password is correct too. Any ideas?
java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx2048m
java version “1.6.0_29”
Java™ SE Runtime Environment (build 1.6.0_29-b11-402-11D50b)
Java HotSpot™ 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Its 1.6 – which is the correct version. Should I downgrade to 32-bit? Seems ridiculous, but I guess that’s my only option at this point before I start looking at UDK or something.
Can I install the 32-bit version in a different folder and point JAVA_HOME at it? Or do I have to uninstall 64-bit java and install 32-bit to get Unity to pick it up properly?
Never tried it. Though, there is no real advantage of having 64 bit version of it anyways. 98% of the Applications don’t even profit form being 64 bit over 32 bit, unless you want to open files wihch are greater than 2 GB or you need more than 2 GB of memory
Ok–so here’s the deal. I talked to an Android guru friend of mine at GDC, he gave me the name of one of the super duper Android engineers at Unity. He suggested I hunt him down at the booth. I did, and we spent 15 minutes looking at my machine. He was mystified–but it seemed that Unity was picking up a bogus JAVA_TOOLS_OPTIONS setting from somewhere that was probably causing the command line compilation to fail.
The setting was: -Xmx2048m (as you see in the error)
We looked at my .bash_profile, but didn’t see it. He had to go to a meeting, but that was enough clues. He also said worst case, you can remove the manifest folder from the APK (it’s just a zip file) and just sign it on the command line…which works. But what a pain!
When I got home from GDC, I was checking out my system and found I had an environment.plist file in my hidden .MacOSX folder. I made this years and years ago to boost the memory for the JRE back in my Flash days and forgot about it. No wonder we didn’t see it in my .bash_profile file.
I deleted this plist, rebooted my Mac, and now it creates a signed APK!!!
Pretty obscure bug. I think it would help if Unity logged all of the shell command activity it does while building APKs etc. The editor.log doesn’t show really what’s going on under the hood sometimes.
I have that problem on windows with Unity 3.5.0f5, do you guys have any more pointers to fix that? What would be the PC equivalent to your solution? Ideas?
The problem is the JDK, you have to put in the preferences path, one that works with 32 bits, or in that case, one that is compatible with unity! example: there are cases in which the JDK for windows 10 = Java (jdk v.10) does not work yet in Unity, so for now work with a version before the JDK that you have which gives you by mistake.