[TIMOB-15817] CLI: Java 1.7 on Mavericks will cause packaged app to fail on install to Android device
GitHub Issue | n/a |
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Cannot Reproduce |
Resolution Date | 2013-12-03T01:49:02.000+0000 |
Affected Version/s | Release 3.2.0 |
Fix Version/s | n/a |
Components | Android, CLI |
Labels | qe-3.2.0 |
Reporter | Samuel Dowse |
Assignee | Chris Barber |
Created | 2013-11-25T22:25:53.000+0000 |
Updated | 2017-03-21T21:51:14.000+0000 |
Description
Description
Creating and packaging an application works perfectly through Studio and CLI.
However installing the application to device will throw the error "INSTALL_PARSE_FAILED_NO_CERTIFICATES"
Strangely enough however, the application installed successfully on Android 4.4 devices. Anything lower than 4.4 caused the error to be thrown.
Steps To Reproduce
1. Install the latest Java version
2. Create an Android project
3. Package the project
4. Install the project to Android device
Expected Result
App installs successfully on device
Actual Result
INSTALL_PARSE_FAILED_NO_CERTIFICATES error is thrown
+Extra Information+
Screenshot added shows the first attempt fail on a 4.3 device followed by a successful 4.4 attempt. Every attempt after that is a 4.3 or lower device
Attachments
Mavericks will install Java 1.6.0_65 by default, so this does not appear to be the default Java version.
Bug exists on: Windows 8.1 Titanium Studio, build: 3.2.0.201311221859 Titanium SDK, build: 3.2.0.v20131125232254 CLI: 3.2.0-alpha3 Alloy: 1.3.0-alpha6 Java: 1.7.0_45 Packaging Android application failed with the error:
Seems to be due to http://code.google.com/p/android/issues/detail?id=19567. Need to specify the parameters "-digestalg SHA1 -sigalg MD5withRSA" for jarsign as the default digest algorithm for Java 7 is SHA-256.
The Android build already passes "-digestalg SHA1 -sigalg MD5withRSA" into jarsigner.
Okay, what else might be the issue?
I've tested this on OS X 10.8.5 (Mountain Lion), OS X 10.9 (Mavericks), and Windows 8 (64-bit) with Java 1.6, 1.7, and 1.7 (respectively) with a keystore containing a mixed-case alias and was not able to reproduce this. I suspect your keystore was bad and that you should recreate it.
Closing ticket as the issue cannot be reproduced and due to the above comments.