In diesem Ratgeber
Releases scheitern an langweiligen Dingen: ein vergessenes Debug-Flag, ein falscher Versionscode, ein Eintrag, der nicht zur App passt. Diese Liste deckt den Produktionsschritt ab. Steckst du noch im geschlossenen Test, nimm zuerst die Checkliste für den geschlossenen Test.
Jeder Punkt hat einen Grund und eine Prüfung.
Build
- Release-Build, nicht Debug. Debug-Builds sind langsamer und größer und können Logs oder Testserver offenlegen. So prüfst du: Release-Variante bauen, Debug-Menüs, Test-Endpunkte und ausführliches Logging müssen weg sein.
- Versionscode höher als beim letzten Upload, Versionsname korrekt. Google Play lehnt einen Upload mit einem bereits verwendeten Versionscode ab, und jedes Release sollte einen höheren Wert nutzen. So prüfst du: mit dem letzten Release in der Play Console vergleichen.
- Abhängigkeiten und Schlüssel sind Produktionswerte. API-Keys, Analytics-IDs und Server-URLs unterscheiden sich oft zwischen Test und Produktion. So prüfst du: die Release-Konfiguration lesen, nicht die Debug-Variante.
- Ziel-API-Level erfüllt die aktuelle Vorgabe. Google erhöht es regelmäßig, mit Fristen für neue Apps und Updates; lies vor dem Einreichen die aktuelle Tabelle auf Googles Seite zum Ziel-API-Level. So prüfst du: dein Target-SDK mit dieser Seite vergleichen.
Signatur
- Der Upload-Schlüssel ist sicher und gesichert. Ein Verlust macht Updates mühsam. So prüfst du: wissen, wo Keystore und Passwörter liegen und wer Zugriff hat.
- Das Artefakt ist wie erwartet signiert. Ein falscher Schlüssel führt bei Testern oder Nutzern zu Installationskonflikten. So prüfst du: genau die Release-Datei auf einem sauberen Handy installieren.
Das echte Artefakt testen
- Release-Build auf sauberem Gerät installieren, Hauptablauf durchspielen. Der Release-Build verhält sich anders als Debug (Minifizierung, Ressourcen-Schrumpfung). So prüfst du: erster Start, Registrierung, Hauptaktion, ggf. Kauf, Abmelden.
- Update von der Vorversion. Hier brechen Datenmigrationen. So prüfst du: alte Version installieren, Daten anlegen, aktualisieren, Daten prüfen.
- Pre-Launch-Bericht lesen. Google erstellt ihn beim Hochladen und wenn du ein Release für die Produktion speicherst. Er umfasst Stabilität, Kompatibilität, Leistung und Barrierefreiheit. So prüfst du: Funde sortieren; siehe So liest du ihn.
- Offline und Netzwechsel durchspielen. Siehe Netzwechsel testen.
- App-Größe und ein Einsteiger-Handy prüfen, wenn deine Zielgruppe eines nutzt. Siehe App-Größe.
Store-Eintrag
- Beschreibung, Screenshots und „Neuigkeiten“ passen zu dieser Version. Abweichungen führen zu schlechten Bewertungen. So prüfst du: den Entwurf des Eintrags neben der laufenden App öffnen.
- Angaben zu Datensicherheit und Datenschutz passen zum Verhalten der App. Laut Google bist du allein für korrekte Angaben verantwortlich, und sie müssen aktuell bleiben; falsche Angaben können zu Maßnahmen führen. So prüfst du: mit deinen SDKs und Berechtigungen abgleichen; keine Rechtsberatung, prüfe Googles aktuelle Formulare.
- Kontakt-E-Mail und Datenschutz-URL funktionieren. So prüfst du: beides anklicken.
Rollout
- Nutze für Updates einen gestaffelten Rollout. Laut Googles Hilfeseite gilt er für App-Updates, nicht für die Erstveröffentlichung. Du wählst einen Prozentsatz; er wächst nicht von selbst, du erhöhst ihn unter „Rollout verwalten“. Nutzer werden zufällig ausgewählt.
- Wisse, wie du anhältst. Anhalten stoppt die Verteilung an weitere Nutzer; wer die Version schon hat, behält sie. Zur Korrektur veröffentlichst du einen neuen, reparierten Build.
- Beobachte Abstürze und Feedback während des Rollouts. Schau in die Android Vitals und in deinen Tester-Kanal, bevor du den Prozentsatz erhöhst.
- Passe den Store-Eintrag nach 100 % an, wenn die Änderungen vom Release abhängen (so schlägt es die Hilfeseite vor).
Teil des Android-Testing-Leitfadens.
Noch eine letzte Runde echter Augen vor dem Rollout? So funktioniert AppReviewX: privates, strukturiertes Feedback.