Haben Sie versehentlich mit dem Debug-Schlüssel unterschrieben?
Mit Google Play können Sie keine App veröffentlichen, die mit Ihrem Debug-Keystore signiert ist. Wenn Sie versuchen, eine solche APK hochzuladen, schlägt Google Play mit der Meldung "Sie haben eine APK hochgeladen, die im Debug-Modus signiert wurde. Sie müssen Ihre APK im Release-Modus signieren" fehl.
Wenn Sie jedoch versuchen, ein Update hochzuladen, das mit dem Debug-Keystore signiert ist, wird diese Meldung nicht angezeigt. Google Play zeigt die in der Frage angezeigte Nachricht an, die sich auf SHA1-Fingerabdrücke bezieht.
Überprüfen Sie zunächst, ob Sie die App versehentlich mit Ihrem Debug-Schlüssel signiert haben.
Wie überprüfe ich, welche Signaturschlüssel verwendet wurden?
Sammeln Sie die Informationen aus der APK
Mit den folgenden Befehlen können Sie mithilfe von Java überprüfen, mit welchen Zertifikaten das ursprüngliche APK und das Update-APK signiert wurden keytool
:
keytool -list -printcert -jarfile original.apk
keytool -list -printcert -jarfile update.apk
Hier sehen Sie detaillierte Informationen darüber, wie eine APK signiert wurde, zum Beispiel:
Owner: CN=My App, O=My Company, L=Somewhere, C=DE
Issuer: CN=My App, O=My Company, L=Somewhere, C=DE
Serial number: 4790b086
Valid from: Mon Nov 11 15:01:28 GMT 2013 until: Fri Mar 29 16:01:28 BST 2041
Certificate fingerprints:
MD5: A3:2E:67:AF:74:3A:BD:DD:A2:A9:0D:CA:6C:D4:AF:20
SHA1: A6:E7:CE:64:17:45:0F:B4:C7:FC:76:43:90:04:DC:A7:84:EF:33:E9
SHA256: FB:6C:59:9E:B4:58:E3:62:AD:81:42:...:09:FC:BC:FE:E7:40:53:C3:D8:14:4F
Signature algorithm name: SHA256withRSA
Version: 3
Die wichtigen Teile, die hier zu beachten sind - für jede APK - sind der SHA1- Fingerabdruckwert, der Eigentümeridentitätswert und das Gültigkeitsdatum von / bis .
Wenn dieser keytool
Befehl nicht funktioniert (für die -jarfile
Option ist Java 7 erforderlich), können Sie über den folgenden jarsigner
Befehl weitere grundlegende Informationen abrufen:
jarsigner -verify -verbose:summary -certs original.apk
jarsigner -verify -verbose:summary -certs update.apk
Dies zeigt leider nicht den SHA1-Fingerabdruck, sondern die X.509-Eigentümeridentität sowie die Ablaufdaten des Zertifikats. Beispielsweise:
sm 4642892 Thu Apr 17 10:57:44 CEST 2014 classes.dex (and 412 more)
X.509, CN=My App, O=My Company, L=Somewhere, C=DE
[certificate is valid from 11/11/13 12:12 to 29/03/41 12:12]
[CertPath not validated: Path does not chain with any of the trust anchors]
Sie können jede Meldung "CertPath nicht validiert" sowie Warnungen zu Zertifikatketten oder Zeitstempeln ignorieren. Sie sind in diesem Fall nicht relevant.
Vergleichen Sie die Werte für Eigentümer, SHA1 und Ablauf zwischen den APKs
Wenn der Identitätswert Owner / X.509 lautet CN=Android Debug, O=Android, C=US
, haben Sie die APK mit Ihrem Debug-Schlüssel und nicht mit dem ursprünglichen Release-Schlüssel signiert
Wenn sich der SHA1- Fingerabdruckwert zwischen den ursprünglichen und den aktualisierten APKs unterscheidet, haben Sie nicht für beide APKs denselben Signaturschlüssel verwendet
Wenn die Identitätswerte für Eigentümer / X.509 unterschiedlich sind oder die Ablaufdaten des Zertifikats zwischen den beiden APKs unterschiedlich sind, haben Sie nicht für beide APKs denselben Signaturschlüssel verwendet
Beachten Sie, dass selbst wenn die Owner / X.509-Werte zwischen den beiden Zertifikaten identisch sind, dies nicht bedeutet, dass die Zertifikate identisch sind - wenn etwas anderes nicht übereinstimmt - wie die Fingerabdruckwerte -, dann unterscheiden sich die Zertifikate.
Suchen Sie nach dem ursprünglichen Schlüsselspeicher und überprüfen Sie die Sicherungen
Wenn die beiden APKs unterschiedliche Zertifikatinformationen haben, müssen Sie den ursprünglichen Schlüsselspeicher finden, dh die Datei mit dem ersten SHA1-Fingerabdruckwert, den Google Play (oder keytool
) Ihnen mitgeteilt hat.
Durchsuchen Sie alle Keystore-Dateien, die Sie auf Ihrem Computer und in allen vorhandenen Backups finden, bis Sie die mit dem richtigen SHA1-Fingerabdruck haben:
keytool -list -keystore my-release.keystore
Drücken EnterSie einfach, wenn Sie zur Eingabe des Passworts aufgefordert werden. Sie müssen es nicht unbedingt eingeben, wenn Sie nur schnell den SHA1-Wert überprüfen möchten.
Ich kann den ursprünglichen Schlüsselspeicher nirgendwo finden
Wenn Sie den ursprünglichen Schlüsselspeicher nicht finden können, können Sie niemals Updates für diese bestimmte App veröffentlichen.
Android erwähnt dies ausdrücklich auf der Seite Signieren Ihrer Anwendung :
Warnung: Bewahren Sie Ihren Schlüsselspeicher und Ihren privaten Schlüssel an einem sicheren Ort auf und stellen Sie sicher, dass Sie über sichere Sicherungen verfügen. Wenn Sie eine App bei Google Play veröffentlichen und dann den Schlüssel verlieren, mit dem Sie Ihre App signiert haben, können Sie keine Updates für Ihre App veröffentlichen, da Sie immer alle Versionen Ihrer App mit demselben Schlüssel signieren müssen.
Nach der ersten Veröffentlichung einer APK müssen alle nachfolgenden Versionen mit genau demselben Schlüssel signiert werden.
Kann ich den ursprünglichen Signaturschlüssel aus der ursprünglichen APK extrahieren?
Nein das ist nicht möglich. Die APK enthält nur öffentliche Informationen und nicht Ihre privaten Schlüsselinformationen.
Kann ich auf einen neuen Signaturschlüssel migrieren?
Nein. Selbst wenn Sie das Original finden, können Sie keine APK mit Schlüssel A signieren, dann das nächste Update mit beiden Schlüsseln A und B signieren und das nächste Update danach nur mit Schlüssel B signieren.
Das Signieren einer APK (oder einer beliebigen JAR-Datei) mit mehreren Schlüsseln ist technisch möglich, Google Play akzeptiert jedoch keine APKs mit mehreren Signaturen mehr.
Wenn Sie dies versuchen, wird die Meldung "Ihre APK wurde mit mehreren Zertifikaten signiert. Bitte signieren Sie sie nur mit einem Zertifikat und laden Sie sie erneut hoch." Angezeigt.
Was kann ich tun?
Sie müssen Ihre App mit einer neuen Anwendungs-ID erstellen (z. B. von "com.example.myapp" in "com.example.myapp2" ändern) und einen brandneuen Eintrag bei Google Play erstellen.
Möglicherweise müssen Sie auch Ihren Code ändern, damit Benutzer die neue App installieren können, auch wenn sie die alte App installiert haben. Sie müssen beispielsweise sicherstellen, dass Sie keine widersprüchlichen Inhaltsanbieter haben.
Sie verlieren Ihre vorhandene Installationsbasis, Überprüfungen usw. und müssen einen Weg finden, Ihre bestehenden Kunden dazu zu bringen, die alte App zu deinstallieren und die neue Version zu installieren.
Stellen Sie erneut sicher, dass Sie über sichere Sicherungen des für diese Version verwendeten Schlüsselspeichers und Kennworts verfügen.