“Package file was not signed correctly” error — detect whether or not it will happen with Google Play app apk

问题

I am having problems with the error described in the questions below:

Published Android apk gives error "Package file was not signed correctly"
Some (but not all) users receive "Package file was not signed correctly" when downloading my app from Google Play

Specifically, when some users try to download my Google Play app, they get the error, others don't.

My question is: how to detect before submission whether the problem is going to occur or not?

For what it's worth, when I run

jarsigner -verify -verbose -certs myapk.apk

I see something like the following:

86226 Sun Nov 09 10:34:54 EET 2014 META-INF/MANIFEST.MF X.509, //[personal stuff omitted] [certificate is valid from 8/20/14 8:04 AM to 1/5/42 7:04 AM] [CertPath not validated: Path does not chain with any of the trust anchors] // several hundred entries like the above, and then: jar verified.

Warning: This jar contains entries whose certificate chain is not validated. This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2042-01-05) or after any future revocation date.

回答1:

Actually this is a common problem and i guess you must be using Java 7 or later.

Solution

Run jarsigner:

jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOU_JAR_FILE}

have a look here

回答2:

Not actually a test to see if the apk is signed propably, but I feel this is usefull:

I got this problem a while ago, my solution: sign by hand.
Here is the script:

#!/bin/bash
storepass="your store pass"
keypass="your key pass"
alias="alias"
if [ $# -lt 1 ]; then
    echo "$0 <apk file>"
    exit 1;
fi

filename=$(basename "$1")
extension="${filename##*.}"
filename="${filename%.*}"


if [ $extension != "apk" ]; then
    echo "Inputfile is no apk!"
    exit 1;
fi

cp $filename.apk $filename-tmp.apk
zip -d $filename-tmp.apk "META-INF*"
rm -rf $filename-signed.apk
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore $keystore -storepass $storepass -keypass $keypass $filename-tmp.apk $alias
/Developer/android-sdk-macosx/build-tools/20.0.0/zipalign -f -v 4 $filename-tmp.apk $filename-signed.apk
rm -rf $filename-tmp.apk

You might need to update for your settings. I have tested it with Multiple devices (Galaxy Note 10.5, Samsung Galaxy S3, S5, Nexus 4, Lenovo Tab)
Seems to work so far.

(Signed on Mac OSX)

回答3:

cordova build android --release

Before make sure to configure it: Create an ant.properties file in platforms/android/ with a keystore path and alias name:

key.store=/path/to/keystore/release_key_name.keystore key.alias=alias_name

You will be prompt for the password.

The APK will be created at platforms/android/ant-build/app_name-release.apk.

Source http://ilee.co.uk/Sign-Releases-with-Cordova-Android/

回答4:

how to detect before submission whether the problem is going to occur or not

If you run jarsigner -verify -verbose -certs myapk.apk before you submit your build and you don't get any warnings like you are seeing, then the problem is not going to occur.

For what it is worth, on OSX I avoid this issue by temporarily switching to Java 6 just for the release build:

sudo cp -R /System/Library/Java/JavaVirtualMachines/1.6.0.jdk /Library/Java/JavaVirtualMachines/1.6.0.jdk
sudo mv /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk ~/Desktop/jdk1.8.0_31.jdk
java -version   // shows java version "1.6.0_65" yay!! 

Do my build without the certificate and timestamped errors. And revert back to Java 8:

sudo mv ~/Desktop/jdk1.8.0_31.jdk /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk

回答5:

please use eclipse proguard for that matter and replace your proguard.cfg content with that: (note that if you are using android studio you can import the project to eclipse using import)

-optimizationpasses 5
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-dontskipnonpubliclibraryclassmembers
-dontpreverify
-dontshrink
-verbose

-injars bin/classes
-injars libs
-outjars bin/classes-processed.jar

-dontwarn org.apache.**
-dontwarn org.slf4j.**
-dontwarn org.json.*
-dontwarn org.mortbay.**
-dontwarn org.apache.log4j.**
-dontwarn org.apache.commons.logging.**
-dontwarn org.apache.commons.logging.**
-dontwarn org.apache.commons.codec.binary.**
-dontwarn javax.xml.**
-dontwarn javax.management.**
-dontwarn java.lang.management.**
-dontwarn android.support.**
-dontwarn com.google.code.**
-dontwarn oauth.signpost.**
-dontwarn twitter4j.**

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*

-keep public class * extends android.app.Activity
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService
-keep public class com.google.code.linkedinapi.**

-keep class javax.**  { *; }
-keep class org.**  { *; }
-keep class java.lang.management.**  { *; }

# use the keep command in that format for your third party libraries

-keepclassmembers public class com.google.code.linkedinapi.client.impl.LinkedInApiXppClient {
     public <init>(java.lang.String, java.lang.String);
}

-keepclasseswithmembernames class * {
    native <methods>;
}

-keepclasseswithmembernames class * {
    public <init>(android.content.Context, android.util.AttributeSet);
}

-keepclasseswithmembernames class * {
    public <init>(android.content.Context, android.util.AttributeSet, int);
}

-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

-keep class * implements android.os.Parcelable {
  public static final android.os.Parcelable$Creator *;
}

回答6:

This is a JAVA tooling problem. This occurs frequently with mixing JDK and JRE tools on the system.You do not use the tools from Java 7. Only use the tools from JDK 6.

Optionally, we can stop wasting more time by pasting the output from the following so that we both feel having actually done something:

which jar signer

jarsigner -verify -verbose -certs yourJar.jar

Please go through this for more details

来源：https://stackoverflow.com/questions/27034663/package-file-was-not-signed-correctly-error-detect-whether-or-not-it-will-h