Der Pre-Launch-Bericht ist ein automatischer Testlauf, den Google Play mit deinem Build vor dem Release macht. Er läuft ohne zusätzliche Einrichtung von deiner Seite, deshalb lohnt sich der Blick jedes Mal. Man überschätzt ihn aber leicht: Er ist ein Roboter, kein Nutzer.
Was er tut
Laut Play Console Hilfe sucht der Bericht nach Problemen bei Stabilität, Android-Kompatibilität, Leistung und Barrierefreiheit. Er läuft, wenn du ein App Bundle oder eine APK hochlädst und wenn du ein Release für die Produktion speicherst. Die App wird auf Geräten in Googles Testlabor gestartet. Ein Crawler tippt, schreibt und wischt einige Minuten lang. Danach wird der Bericht erstellt.
Weitere Angaben derselben Seite, die beeinflussen, wie du den Bericht liest:
- Ergebnisse kommen meist innerhalb einer Stunde nach dem Upload. Ist ein Bericht nach zwei Tagen nicht fertig, lade den Build erneut hoch.
- Die Testgeräte laufen mit Android 9 oder neuer: Handys, Tablets, Wear OS und Geräte wie Chromebooks. Android Automotive OS und Android TV lassen sich nicht testen.
- Die Geräte stehen in den USA und laufen standardmäßig im Hochformat.
- Du kannst bis zu drei Deep Links als zusätzliche Einstiege, Zugangsdaten für ein Testkonto, ein Robo-Skript oder eine Spielschleife angeben und bis zu fünf Sprachen wählen.
- Apps ohne Haupt-Start-Activity lassen sich nicht testen (Google nennt Launcher, Widgets, Tastaturen und Watchfaces).
Der Umfang ändert sich. Öffne die aktuelle Seite, bevor du dich auf etwas davon verlässt.
Was er nicht sieht
Der Crawler kennt dein Produkt nicht. Er beurteilt nicht, ob das Onboarding Sinn ergibt, ein Preis klar ist oder ein Text gut liest. Ohne Zugangsdaten kommt er womöglich nicht am Login vorbei. Alles hinter einer Zahlung, in seltenen Zuständen oder mit Aktionen in der echten Welt (Lieferung, Bluetooth-Gerät) bleibt außerhalb.
So sortierst du die Funde
Die Übersicht gruppiert Probleme in Fehler, Warnungen und kleinere Hinweise und gibt eine Empfehlung zum Launch. Nimm sie als Startpunkt, nicht als Urteil.
| Fund | Vorgehen |
|---|---|
| Absturz mit Stacktrace in deinem Code | Von Hand nachstellen, möglichst vor dem Release beheben. |
| Absturz in einer Fremdbibliothek | Prüfen, ob ein echter Ablauf betroffen ist; Bibliothek aktualisieren. |
| Absturz nur nach unnatürlicher Crawler-Eingabe | Geringere Priorität, aber prüfen, dass seltsame Eingaben keine Daten kosten. |
| Barrierefreiheit (Tippfläche, Kontrast, fehlendes Label) | Meist günstig zu beheben und wertvoll. Am eigenen Gerät prüfen. |
| Leistungswarnung | Erst mit einem echten Mittelklasse-Handy gegenprüfen. |
| Login-Sperre, nichts getestet | Testzugang hinterlegen und erneut laufen lassen. |
Faustregel: Behebe, was du nachstellen kannst, notiere, was nicht, und ignoriere nichts ohne schriftlichen Grund.
Neben echten Testern nutzen
Der Bericht findet Abstürze und offensichtliche Mängel auf festen Geräten, schnell. Menschen finden verwirrende Abläufe, falsche Formulierungen und Probleme auf ihren eigenen Handys. Nutze beides. Zur Feldseite siehe Android-Vitals-Grundlagen, zum Vergleich Cloud-Gerätetests oder echte Tester.
Teil des Android-Testing-Leitfadens.
Du brauchst echte Menschen für deinen Build? Hier starten und privates, strukturiertes Feedback bekommen.