In diesem Ratgeber
"Bei mir installiert es, beim Tester nicht." "Das Update scheitert mit einem Signaturfehler." Vieles davon hat eine Ursache: Dieselbe App kann je nach Weg aufs Gerät mit unterschiedlichen Schlüsseln signiert sein.
Die drei Arten von Build
Lokaler Build. Du baust und installierst vom Rechner, meist mit Debug-Schlüssel oder eigenem Schlüssel signiert. Niemand sonst kann ihn aktualisieren, der nicht dieselbe Signatur hat.
Mit dem Upload-Schlüssel signiertes Bundle. Du signierst dein App-Bundle mit dem Upload-Schlüssel und lädst es bei Google Play hoch. Laut Google-Hilfe zu Play App Signing hältst du den Upload-Schlüssel selbst, und Google prüft damit deine Identität.
Über Play gelieferter Build. Mit Play App Signing hält Google den App-Signaturschlüssel und signiert damit die APKs, die an Nutzer gehen. Der Build, den ein Tester aus Google Play bekommt, ist also mit einem anderen Schlüssel signiert als die Datei, die du hochgeladen hast. (Quelle: Play Console Hilfe, abgerufen 2026-10-23.)
Was dabei bricht, nach Symptom
- "App nicht installiert" oder Signaturkonflikt beim Update. Die installierte Kopie ist mit einem Schlüssel signiert, die neue mit einem anderen. Typischer Fall: Ein Tester hat dein lokales APK installiert und probiert dann die Play-Testversion, oder umgekehrt. Android aktualisiert nicht über verschiedene Signaturen hinweg.
- Lösung: Vorhandene Kopie deinstallieren und nur aus einer Quelle neu installieren. Sag Testern, welche Quelle gilt, und warne, dass App-Daten beim Deinstallieren verloren gehen.
- Ein Anmeldedienst oder eine API lehnt die App ab. Dienste, die den Fingerabdruck des Signaturzertifikats prüfen, kennen vielleicht nur den lokalen oder den Upload-Schlüssel. Von Play gelieferte Builds tragen das Zertifikat des App-Signaturschlüssels, also hinterlege auch dieses. Wo du Fingerabdrücke findest und einträgst, steht in der aktuellen Dokumentation des jeweiligen Anbieters.
- Anderes Verhalten zwischen deinem Debug-Build und dem des Testers. Debug-Builds unterscheiden sich oft in mehr als dem Schlüssel, etwa bei Verkleinerung und Logging. Teste den Release-Build, den Play liefert.
- Sorge um verlorene Schlüssel. Laut derselben Hilfeseite bist du bei Verlust oder Verdacht auf Kompromittierung des Upload-Schlüssels nicht ausgesperrt: Du erstellst einen neuen und beantragst in der Play Console einen Reset. Bewahre ihn trotzdem sicher auf.
Eine praktische Regel für Test-Builds
- Wähle pro Testgruppe einen Verteilweg: entweder Play-Testkanal oder direktes APK, nicht beides.
- Bitte Tester vor einer Testrunde, anders installierte ältere Kopien zu entfernen.
- Prüfe den Fingerabdruck, den deine Dienste erwarten, und vergleiche ihn mit dem Build, den Tester tatsächlich bekommen.
- Teste den über Play gelieferten Build mindestens einmal vor dem Release, nicht nur deinen lokalen.
Was du Testern sagst
Eine kurze Notiz reicht: "Installiere nur über den Einladungslink. Wenn du früher eine Version anderswoher installiert hast, deinstalliere sie zuerst."
Zurück zum Android-Testing-Leitfaden. Dazu: Sprache und Region testen und Kamera und Medien testen.
AppReviewX bietet privates, strukturiertes Feedback und Testgruppen für Google Play (12 Tester, 14 Tage am Stück, für Android-Apps). 1 Feedback = 1 Credit. Kostenlos starten.
Prüfe die verlinkte Google-Seite, bevor du dich auf Details verlässt; der Umgang mit Schlüsseln kann sich ändern.