Tests bei Google Play
Jedes Mal, wenn du ein Bundle hochlädst, installiert Google es auf einer Reihe von Testgeräten, lässt einen Crawler ein paar Minuten lang hindurchtippen und schreibt auf, was schiefgegangen ist. Bei einer Web-Wrapper-App kommt viel vom Rauschen aus den Webinhalten und den SDKs. Die Kunst ist also zu wissen, auf welche Befunde auch ein Reviewer stoßen würde und welche du zur Kenntnis nehmen und abhaken kannst.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Wenn du ein App-Bundle in die Play Console hochlädst, installiert Google es automatisch auf einer Auswahl von Geräten in seinem Testlabor (Smartphones, Tablets und manchmal Chromebooks mit Android 9 oder neuer), lässt einen Crawler die App einige Minuten lang durch Tippen, Texteingaben und Wischen erkunden und deinstalliert sie dann wieder. Die Ergebnisse liegen meist nach etwa einer Stunde vor, manchmal erst nach mehreren Stunden. Ist ein Bericht nach zwei Tagen nicht fertig, startet ein neuer Upload einen frischen.
Der Bericht zählt Fehler, Warnungen und kleinere Probleme, gruppiert sie in Befunde zu Stabilität, Leistung, Barrierefreiheit und Sicherheit und ergänzt Screenshots und Videos pro Gerät. Er ist ein Diagnosewerkzeug, kein Review-Urteil: Eine Warnung hindert dich nicht am Rollout. Beim ersten Start sehen der Crawler und ein menschlicher Reviewer deine App aber gleich, also blockiert alles, was den Crawler blockiert, wahrscheinlich auch den Reviewer. Zu den Ursachen von Abstürzen und weißen Screens siehe den Guide zu fehlerhafter Funktionalität; auf dieser Seite geht es darum, den Bericht zu lesen.
Google gibt an, dass Zugangsdaten für Testkonten nicht verwendet werden können, wenn eine App Nutzer über einen webbasierten Ablauf in einer WebView anmeldet. Hinter einem Login-Screen sieht der Crawler auf jedem Gerät eine einzige Seite.
Barrierefreiheitsprüfungen lesen, was die WebView bereitstellt, also wird ein Icon-Button ohne Beschriftung in deinem React-Code zu einem Befund für deine App.
Warnungen zu Nicht-SDK-Schnittstellen oder Bibliotheksversionen stammen oft aus Werbe-, Push- oder Analytics-SDKs, nicht aus etwas, das du geschrieben hast.
Keine Cookies, keine gespeicherte Einwilligung, keine Sitzung. Ein Cookie-Banner oder ein Onboarding-Modal erscheint auf jedem Gerät und verdeckt, was der Crawler sehen sollte.
| Befund | Übliche Bedeutung in einer WebView-App | Priorität |
|---|---|---|
| Absturz oder ANR | Eine Funktion ist ohne ihre Konfiguration eingeschaltet, zum Beispiel Werbung ohne AdMob-App-ID oder Firebase-Push ohne google-services.json | Vor dem Release beheben. Der Stack-Trace nennt meist das SDK |
| Leere oder weiße Screenshots | Die URL war nicht erreichbar, der Bot-Schutz hat den Traffic aus dem Testlabor blockiert oder Mixed Content hat die Seite gestoppt | Vor dem Release beheben. Ein Reviewer würde dasselbe sehen |
| Screenshots zeigen nur die Login-Seite | Der Crawler konnte sich über den Web-Login nicht anmelden | Für die Review-Bereitschaft beheben: ein öffentlicher oder Demo-Bereich plus Deep Links, siehe unten |
| Cookie-Banner auf jedem Screenshot | Ein Consent-Overlay, das beim ersten Besuch erscheint | Mach es kompakt, damit der Inhalt sichtbar bleibt; behalte jede Einwilligungsabfrage, die du rechtlich zeigen musst |
| Sicherheitswarnung zur SSL-Behandlung | Die WebView darf bei Zertifikatsfehlern weitermachen | Beheben. Setze BLOCK_SELF_SIGNED_AND_FAULTY_SSL_CERTS auf true und repariere die Zertifikatskette bei deinem Hoster |
| Sicherheitswarnung zu einer Bibliotheksversion | Eine alte SDK-Version aus einem veralteten Template | Durch einen Build aus dem aktuellen WebViewGold-Template beheben |
| Barrierefreiheit: Größe der Touch-Ziele | Links und Icon-Buttons in deiner Web-App, die kleiner als etwa 48 x 48 dp sind | Hauptnavigation und primäre Buttons beheben; kleine Textlinks im Fließtext können warten |
| Barrierefreiheit: Inhaltsbeschriftungen | Reine Icon-Buttons und Bilder ohne zugänglichen Namen | In der Web-App mit aria-label und alt-Text beheben |
| Barrierefreiheit: geringer Kontrast | Hellgrauer Text, Platzhaltertext, blasse Buttons | Beheben, wo Fließtext und primäre Aktionen betroffen sind |
| Leistung: langsamer Start oder ruckelnde Frames | Ein schweres JavaScript-Bundle oder große Bilder auf der Startseite | Verbessern, wenn du kannst; kein Blocker |
| Nutzung von Nicht-SDK-Schnittstellen | Versteckte Android-APIs, die ein SDK aufruft | Meist nur informativ; halte das Template und seine SDKs aktuell |
Ich bin sehr glücklich, dass ich diese App gekauft habe! Extrem einfach und großartige Dokumentation. Ich stand in Kontakt mit dem Kundenservice, sie antworteten sehr schnell und sehr freundlich. Sie lösten meine Frage innerhalb eines Tages. 10/10 würde ich empfehlen.
Diese Änderungen helfen dem Crawler, dem Reviewer und deinen Store-Screenshots zugleich.
Wenn dein Produkt es erlaubt, öffne die App in einem öffentlichen Bereich: ein Demomodus, eine Produkttour oder durchsuchbare Inhalte ohne Konto. Der Crawler tippt sich durch, was er findet; ein einsames Login-Formular gibt ihm nichts zu tun.
In den Einstellungen des Pre-Launch-Berichts kannst du bis zu drei Deep Links angeben. Nach dem Haupt-Crawl öffnet der Crawler jeden davon und erkundet ihn etwa 30 Sekunden lang; jeder Link muss zu einem Intent-Filter deiner App passen. Aktiviere bei WebViewGold das eigene Scheme (IS_CUSTOM_SCHEME_ENABLED und CUSTOM_DEEPLINK_SCHEME) oder verifizierte App Links, wie in der Doku zu App Links beschrieben, und nutze dann Links wie yourscheme://https://www.example.com/demo, um den Crawler auf öffentliche Seiten zu schicken.
Das Feld für Zugangsdaten in den Berichtseinstellungen hilft bei einem Web-Login in einer WebView nicht. Hinterlege trotzdem einen funktionierenden Demo-Account unter Anmeldedaten (Sign-in details), denn menschliche Reviewer nutzen ihn.
Jedes Testgerät startet frisch. Halte die Einwilligungsabfrage so klein, dass die Seite dahinter sichtbar bleibt, und verzichte in der App auf mehrstufige Onboarding-Modals.
Lade mit neuem Version Code in den internen Test hoch. Öffne den Bericht, nutze bei jedem Befund die Detailansicht und schau dir die Gerätevideos an: Sie zeigen genau, wo der Crawler hängen geblieben ist.
Befunde zu Barrierefreiheit und Leistung behebst du größtenteils in deiner Web-App, und die Korrekturen gehen ohne neuen Build live. Native Befunde (Abstürze, SDK- und Sicherheitswarnungen) brauchen einen Rebuild und einen neuen Upload.
WebViewGold wendet die custom.css des Projekts auf jede Seite an, die in der App geladen wird. Damit ist sie ein schneller Ort für Fixes an Touch-Zielen, während du die Web-App richtig korrigierst. Beschriftungen gehören in die Web-App selbst, zum Beispiel aria-label="Menü öffnen" an einem Icon-Button.
/* custom.css im WebViewGold-Android-Projekt: Anpassungen nur für die App */
/* Mindestgröße der Touch-Ziele für Navigation und primäre Aktionen */
nav a,
button,
[role="button"],
.icon-button {
min-height: 48px;
min-width: 48px;
}
/* Consent-Banner kompakt halten, damit der Inhalt sichtbar bleibt */
.cookie-banner {
max-height: 30vh;
overflow: auto;
}Nein. Befunde dienen der Diagnose und stoppen keinen Rollout. Behebe Abstürze, leere Screens und Sicherheitsbefunde trotzdem, weil ein Reviewer auf dieselben Probleme stoßen kann.
Berichte hängen von der Kapazität des Testlabors ab und dauern meist bis zu einer Stunde, manchmal mehrere. Ist nach zwei Tagen nichts erschienen, lade das Bundle mit neuem Version Code erneut hoch, um einen neuen Bericht zu starten.
Nicht für einen Web-Login. Google gibt an, dass Zugangsdaten für Testkonten nicht verwendet werden können, wenn die App Nutzer über einen webbasierten Ablauf in einer WebView anmeldet, und das ist bei einer Wrapper-App der Normalfall. Biete stattdessen einen öffentlichen oder Demo-Bereich an und ergänze Deep Links.
Bei den wichtigen ja. Beschriftungen an Icon-Buttons, lesbarer Kontrast und ausreichend große Tippflächen helfen echten Nutzern und lassen die App nativ wirken. Du behebst sie in deinem Web-Code, und sie gehen ohne neuen Build live.
Meist nicht. Sie kommen überwiegend von SDKs, die versteckte Android-APIs nutzen, und sind informativ. Die richtige Reaktion ist, das WebViewGold-Template und seine SDKs aktuell zu halten; Bibliotheken musst du nicht selbst patchen.
Die Testgeräte decken andere Bildschirmgrößen und Android-Versionen ab und starten immer mit einem frischen Profil. Ein Layout, das im Bericht auf einem kleinen Smartphone oder einem Tablet zerbricht, ist ein echtes Problem; behebe es in deinem CSS.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.