Kurze Antwort
Eine Ablehnung wegen Broken Functionality bedeutet, dass der Prüfer von Google festgestellt hat, dass der eingereichte Release abgestürzt ist, zwangsweise beendet wurde, eingefroren ist oder auf andere Weise nicht normal funktioniert hat. Googles eigene Beispiele sind Apps, die sich nicht installieren lassen, die sich installieren lassen, aber nicht laden, oder die laden, aber nicht reagieren. Es ist eine Richtlinienentscheidung über einen Release, keine Verweigerung des Produktionszugriffs, und laut Google wirkt sich eine Ablehnung allein nicht auf den Status Ihres Entwicklerkontos aus. Reproduzieren Sie das Problem auf dem Build, den Google Play verteilt, stellen Sie sicher, dass sich Prüfer über Sign-in details (früher App access) anmelden können, beheben Sie den Fehler auf jedem betroffenen Track und senden Sie dann den korrigierten Release zur Überprüfung. Legen Sie nur dann Einspruch ein, wenn Sie belegen können, dass die Feststellung falsch war.
Stand: 16. Oktober 2026. Jede Regel auf dieser Seite wurde an diesem Tag mit den Richtlinienseiten von Google Play und der Play Console-Hilfe abgeglichen und ist dort verlinkt, wo sie verwendet wird. Die unten zitierten Entwicklerberichte belegen, was Entwickler 2026 gesehen haben. Sie sind keine Diagnose ihrer Apps durch Google. Eine Rangliste der Ursachen gibt es hier nicht, weil keine öffentlichen Daten eine solche stützen.
Dieser Beitrag behandelt Ablehnungen von Releases nach der Richtlinie Broken Functionality. Wenn Google nach Ihrem geschlossenen Test den Produktionszugriff abgelehnt oder Ihnen mitgeteilt hat, dass mehr Tests erforderlich sind, ist das eine andere Entscheidung mit einer anderen Lösung. Lesen Sie dann stattdessen was zu tun ist, wenn Google Play mehr Tests verlangt und warum Anträge nach dem geschlossenen Test abgelehnt werden.
Was dieser Beitrag behandelt
Was bedeutet Broken Functionality bei Google Play?
Es ist einer von zwei Abschnitten der Google-Richtlinie Functionality, Content, and User Experience (Funktionalität, Inhalte und Nutzererfahrung). Der andere Abschnitt, Limited Functionality and Content, betrifft Apps mit zu wenig Zweck. Broken Functionality betrifft eine App, die in der eingereichten Form nicht funktioniert.
Wir erlauben keine Apps, die abstürzen, zwangsweise beendet werden, einfrieren oder auf andere Weise nicht normal funktionieren.
Unter diesem Satz nennt Google drei Beispiele für häufige Verstöße: Apps, die sich nicht installieren lassen, Apps, die sich installieren lassen, aber nicht laden, und Apps, die laden, aber nicht reagieren. Lesen Sie das als drei Stellen, an denen Sie suchen sollten. Ein Prüfer, der den Build nicht installieren kann, der einen leeren oder endlosen Ladebildschirm sieht oder der auf ein Bedienelement tippt und nichts passiert, kann jedes Mal dieselbe Meldung auslösen.
In älteren Hilfe-Links und Forenthreads begegnet Ihnen eventuell noch der Name Minimum Functionality. Der aktuelle Richtlinienabschnitt heißt Limited Functionality and Content und umfasst reine Text- oder PDF-Apps, Apps mit sehr wenig Inhalt und Apps, die darauf ausgelegt sind, nichts zu tun. Eine Meldung kann sich auf jeden der beiden Abschnitte beziehen, und die Lösungen unterscheiden sich. Lesen Sie also, welchen Abschnitt Ihre Meldung nennt, bevor Sie etwas ändern.
Vier Entscheidungen, die miteinander verwechselt werden
| Entscheidung | Worum es geht | Wo Sie anfangen |
|---|---|---|
| Broken Functionality | Worum es gehtDer eingereichte Release ist beim Prüfer abgestürzt, eingefroren, hat nicht geladen oder nicht reagiert. | Wo Sie anfangenAuf dem Build reproduzieren, den Google Play verteilt, auf jedem betroffenen Track beheben, erneut einreichen. |
| Limited Functionality and Content | Worum es gehtDie App läuft, bietet aber zu wenig app-spezifischen Zweck oder Inhalt. | Wo Sie anfangenEchte Funktionen ergänzen. Eine reine Fehlerbehebung beantwortet diese Feststellung nicht. |
| Sign-in details fehlen oder funktionieren nicht | Worum es gehtPrüfer kamen nicht an einem Login, einer Mitgliedschaft, einer Paywall, einem Einmalcode oder einer Regionsprüfung vorbei. | Wo Sie anfangenSign-in details unter App content aktualisieren und die Änderung dann zur Überprüfung senden. |
| Produktionszugriff nicht gewährt | Worum es gehtNach dem geschlossenen Test hat Google entschieden, dass die App mehr Tests braucht oder nicht bereit für die Produktion ist. | Wo Sie anfangenEin separater Vorgang ohne Meldung auf Code-Ebene. Siehe Mehr Tests erforderlich. |
Wo zeigt Google, was fehlerhaft war?
Beginnen Sie mit der E-Mail zur Durchsetzungsmaßnahme und der Seite Policy status (Richtlinienstatus) in der Play Console. Zusammen nennen sie die Richtlinie und den betroffenen Release, und laut Google zeigt Policy status außerdem alle zusätzlichen Informationen, die verfügbar sind. Screenshots, Gerätedaten und Stacktraces werden nicht zugesagt. Warten Sie also nicht darauf.
Öffnen Sie die Play Console, wählen Sie die App aus und öffnen Sie ihre Seite Policy status. Notieren Sie vier Dinge, bevor Sie den Code anfassen: den genannten Richtlinienabschnitt, den Versionscode und den Track, die überprüft wurden, das Datum und alle beigefügten Belege. Prüfen Sie auch die E-Mail und Ihre Benachrichtigungen in der Play Console, denn dort gibt Google an, gegen welche Richtlinie der Release verstoßen hat.
Wie Meldungen im Jahr 2026 tatsächlich aussehen
Es gibt nicht die eine Broken Functionality-E-Mail, die alle erhalten, und jede Seite, die eine solche als exakte Vorlage abdruckt, rät. Entwickler, die ihre Meldungen 2026 öffentlich gepostet haben, beschreiben sehr unterschiedliche Detailtiefen:
- Eine Meldung mit der Bezeichnung "Broken Functionality: Unresponsive UI elements" (nicht reagierende UI-Elemente), gepostet am 2. September 2026 von einem Entwickler, dessen App während der ersten Datensynchronisierung einen Offline-Bildschirm mit Wiederholen-Option zeigte (Play Console-Hilfe-Community).
- Ein Beispiel des Prüfers mit dem Wortlaut "For example, your app does not open or load." (zum Beispiel öffnet oder lädt Ihre App nicht), zitiert im Juni 2026 von einem Spieleentwickler, dessen Titelbildschirm sehr wohl geladen hat. Der Autor berichtete später, dass das Spiel veröffentlicht wurde, nachdem er geändert hatte, wie die Android-Zurück-Taste es beendet.
- Eine Meldung, die ein Entwickler im August 2026 als nur zwei Wörter beschrieb, "Broken functionality", sonst nichts.
Es handelt sich um Auszüge, die Entwickler wiedergegeben haben, nicht um verifizierte E-Mails von Google, und jeder ist ein Einzelfall. Sie zeigen die Bandbreite an Details, die Sie bekommen könnten, nicht, was in Ihrer Meldung stehen wird oder warum Ihre App durchgefallen ist.
Wenn Ihre Meldung vage ist
Behandeln Sie die genannte Richtlinie als Symptom, das Sie reproduzieren müssen, nicht als Diagnose. Die fünf Prüfungen im nächsten Abschnitt sind so geordnet, dass jede eine andere Stelle ausschließt, an der sich der Fehler verstecken kann.
Was sollten Sie nach einer Ablehnung wegen Broken Functionality zuerst prüfen?
Führen Sie fünf Prüfungen an genau dem Release durch, den Google überprüft hat. Sie sind danach geordnet, was am günstigsten bis am schwersten auszuschließen ist, nicht danach, wie oft eine Ursache auftritt, denn keine öffentlichen Daten zeigen, wie häufig jede einzelne vorkommt.
Fünf Prüfungen, der Reihe nach
Installieren Sie den Build, den Google Play verteilt, nicht Ihren Debug-Build
Installieren Sie die App aus Ihrem Test-Track auf einem sauberen Gerät, das mit einem Google-Konto angemeldet ist, auf dem die App noch nie lief, und öffnen Sie sie dann so, wie es ein Prüfer tun würde. Google Play signiert die Builds, die es verteilt, mit Ihrem App-Signaturschlüssel (Play App-Signatur verwenden). Jeder Dienst, der einen Zertifikats-Fingerabdruck prüft, etwa Google Sign-In, Maps oder ein API-Schlüssel, der auf Paketname und SHA-1 beschränkt ist, kann deshalb in Ihrem Debug-Build funktionieren und im Store-Build fehlschlagen. Ein Entwickler führte 2025 einen Fehler, der nur im Release auftrat, auf eine Internetberechtigung zurück, die im Produktions-Manifest fehlte.
Stellen Sie sicher, dass der Prüfer hineinkommt
Wenn ein Teil der App hinter einem Login, einer Mitgliedschaft, einem Standort oder einer anderen Sperre liegt, verlangt Google, dass Sie die Zugangsdaten bereitstellen. Prüfen Sie, ob unter Sign-in details (früher App access) Zugangsdaten hinterlegt sind, die heute funktionieren, aus jedem Land und ohne Einmalcode. Der nächste Abschnitt führt Sie durch die Einrichtung.
Testen Sie das Backend von außerhalb Ihres eigenen Netzwerks
Anmelde- und Datenbildschirme schlagen fehl, wenn der Server aus dem Netzwerk des Prüfers nicht erreichbar ist. Entwickler führten Fehler 2026 auf eine versehentliche Firewall-Regel zurück, die die Anforderung eines Anmeldecodes blockierte, und berichteten von einem Fehler beim Zertifikatsvertrauen, der auf einem Anmeldebildschirm angezeigt wurde. Testen Sie über mobile Daten und ein anderes Netzwerk und aus einem anderen Land, wenn Ihr Server den Datenverkehr nach Region filtert.
Tippen Sie auf jedes sichtbare Bedienelement und öffnen Sie jeden leeren Bildschirm
Jede Schaltfläche und jeder Link sollte mit passenden Inhalten reagieren. Googles eigene Broken Functionality-Checkliste in der Play Console-Hilfe-Community sagt: "Stellen Sie sicher, dass Ihre App keine leeren oder unbeschriebenen Seiten ohne passende Hinweise oder Fehlermeldungen enthält." Entfernen Sie unfertige Funktionen, statt eine Schaltfläche auszuliefern, die nichts tut, und prüfen Sie, ob jede Funktion, die Ihr Store-Eintrag verspricht, im Build tatsächlich funktioniert. Geben Sie einer berechtigterweise leeren Liste, etwa wenn noch nichts gespeichert ist, einen erklärenden Satz und eine nächste Aktion. Wenn Ihre Navigation ungewöhnlich ist, etwa irgendwo tippen, um fortzufahren, ergänzen Sie einen sichtbaren Hinweis, den ein neuer Nutzer nicht übersehen kann.
Prüfen Sie den Start, die Zurück-Taste und die Berichte, die Google Play bereits hat
Starten Sie die App kalt, drehen Sie das Gerät, schicken Sie die App in den Hintergrund und holen Sie sie zurück, und drücken Sie auf jedem Bildschirm Zurück. Lesen Sie dann den Pre-Launch-Bericht und Android Vitals für die überprüfte Version. Ein dort erfasster Absturz ist der stärkste Beleg, den Sie bekommen werden, und ein sauberer Bericht hat Grenzen, die der übernächste Abschnitt erklärt.
Wie geben Sie den Prüfern von Google Sign-in details?
Gehen Sie in der Play Console zu Policy and programs, dann App content, dann Sign-in details. Der Abschnitt hieß früher App access, deshalb verwenden ältere Beiträge und einige übersetzte Hilfeseiten noch diesen Namen.
Wenn Ihre gesamte App oder Teile davon auf Grundlage von Anmeldedaten, Zugangsdaten, Mitgliedschaften, Standort oder anderen Formen der Authentifizierung eingeschränkt sind, müssen Sie alle erforderlichen Angaben machen, um den Zugriff auf Ihre App zu ermöglichen.
Anweisungen hinzufügen oder aktualisieren
- Öffnen Sie die Play Console und gehen Sie zur Seite App content (Policy and programs > App content).
- Wählen Sie unter Sign-in details die Option Start oder Manage, wenn Sie bereits Anweisungen hinterlegt haben.
- Wählen Sie + Add new instructions und geben Sie die Zugangsdaten ein. Nutzen Sie das Feld Any other instructions für alles Ungewöhnliche, etwa ein Einmalpasswort, eine Mehrfaktor-Authentifizierung oder einen Login mit mehr als zwei Feldern.
- Speichern Sie Ihre Änderungen. Sie können bis zu fünf Sätze von Anweisungen hinzufügen.
- Gehen Sie zu Publishing overview (Veröffentlichungsübersicht), suchen Sie die Änderung unter Changes ready to send for review und wählen Sie Send for review. Das Speichern allein reicht nichts ein.
Was als funktionierender Zugang zählt
Die Play Console-Anforderungen von Google verlangen: "Stellen Sie ein aktives Demokonto, Anmeldeinformationen und alle anderen Ressourcen bereit, die Google Play für die Überprüfung Ihrer App benötigt". Googles Anforderungen an Sign-in details erläutern, was das bedeutet:
- Ein Konto, das aktiv und wiederverwendbar ist, keine Einladung zur einmaligen Nutzung und keine Testversion, die während der Überprüfung abläuft.
- Zugangsdaten, die an Einmalcodes und der Bestätigung in zwei Schritten vorbeiführen, denn der Prüfer kann den Code, den Sie an ein Telefon oder Postfach senden, nicht empfangen.
- Ein Zugang, der von jedem Standort aus funktioniert, wenn die App nach Region einschränkt, und vollen Zugriff auf kostenpflichtige oder gesperrte Funktionen, die der Prüfer sehen muss, ohne dass ihm etwas berechnet wird.
- Angaben auf Englisch, die aktuell gehalten werden. Wenn Sie das Passwort ändern oder das Testkonto löschen, aktualisieren Sie Sign-in details noch am selben Tag.
- Wenn die Anmeldung etwas erfordert, das kein Text ist, etwa einen QR-Code oder Barcode, erzeugen Sie dafür eine statische URL und fügen Sie sie unter Sign-in details hinzu. Wenn die App Nutzer auffordert, eine eigene PIN festzulegen, oder einen Social Login verwendet, erklären Sie in den Anweisungen, wie ein Prüfer durchkommt.
Fehlender Zugang ist nicht dasselbe wie ein defekter Login
Wenn die Meldung Sign-in details nennt, hilft keine Codeänderung, bis die Zugangsdaten korrigiert und zur Überprüfung gesendet wurden. Wenn die Zugangsdaten in Ordnung waren und der Login selbst fehlgeschlagen ist, ist das ein Broken Functionality-Problem, und die Backend-Prüfung oben ist die Stelle, an der Sie suchen sollten.
Was, wenn die App auf Ihrem Smartphone funktioniert und Google keinen Screenshot geschickt hat?
Dann ist Ihr Smartphone nicht die Umgebung, in der der Fehler auftrat. Reproduzieren Sie auf dem Store-Build, auf einem sauberen Gerät und in einem anderen Netzwerk, und lesen Sie die zwei Berichte, die die Play Console für diesen Release bereits hat, bevor Sie irgendetwas entscheiden.
Der Pre-Launch-Bericht
Sie finden ihn unter Test and release > Testing > Pre-launch report. Google erstellt ihn automatisch, wenn Sie ein App Bundle oder APK hochladen, sofern die Kapazität es zulässt, indem die App auf Testgeräten ausgeführt wird. Prüfen Sie, welche Bildschirme der Crawler tatsächlich erreicht hat: Wenn er an Ihrem Anmeldebildschirm stehen geblieben ist, hat er den Rest der App nie gesehen. Google nennt eine Einschränkung, die Sie kennen sollten: "Anmeldedaten können nur in Android-Apps automatisch eingefügt werden, die Standard-Android-Widgets verwenden." (Probleme mithilfe eines Pre-Launch-Berichts erkennen). Ein sauberer Bericht ist ein Beleg, kein Bestehen. Dasselbe sagt Google über seine Prüfungen vor der Überprüfung: "Das Bestehen aller Prüfungen vor der Überprüfung garantiert nicht, dass die formelle App-Überprüfung bestanden wird".
Android Vitals
Sie finden sie unter Monitor and improve > Android vitals > Crashes and ANRs. Google erhebt diese Daten nur von Nutzern, die der Freigabe von Nutzungs- und Diagnosedaten zugestimmt haben (Technische Qualität mit Android Vitals überwachen). Eine neue App in einem kleinen Test zeigt dort deshalb womöglich gar nichts. Eine leere Vitals-Seite beweist nicht, dass die App nie abgestürzt ist.
Echte Menschen auf echten Geräten
Ein geschlossener Test ist dazu da, genau diese Art von Problem vor einer öffentlichen Veröffentlichung zu finden. Tester mit unterschiedlichen Smartphones, Android-Versionen und Netzwerken erreichen die Bildschirme, die auch ein Prüfer erreicht, und ihr Feedback zeigt Ihnen, wo etwas kaputtgeht. Das hilft Ihnen, Fehler zu finden und zu beheben; es ändert nichts daran, wie Google die App überprüft. Wenn Sie die Grundlagen des Tracks selbst brauchen, lesen Sie wie der geschlossene Test bei Google Play funktioniert.
Sollten Sie beheben und erneut einreichen oder Einspruch einlegen?
Beheben Sie den Fehler und reichen Sie erneut ein, wenn Sie einen Fehler reproduzieren oder eine plausible Ursache finden können. Legen Sie Einspruch ein, wenn Sie Belege dafür haben, dass die genannte Feststellung falsch ist. Reichen Sie nie denselben Build unverändert erneut ein: Google weist Entwickler an, eine abgelehnte App erst dann wieder zu veröffentlichen, wenn der Verstoß behoben ist.
Beheben, klarstellen oder Einspruch?
Beantworten Sie drei Fragen zu Ihrer Meldung und Ihren eigenen Tests. Nichts von dem, was Sie auswählen, verlässt diese Seite.
Beantworten Sie die Fragen, um eine Empfehlung zu sehen. Wenn Sie keinen Fehler reproduzieren können, entscheidet die dritte Frage.
Beheben Sie den Fehler und reichen Sie auf jedem Track erneut ein
Beheben und erneut einreichenSie haben einen reproduzierbaren Fehler, und das ist die beste Ausgangslage. Beheben Sie ihn, testen Sie die Korrektur auf dem Store-Build und folgen Sie dann den Schritten zur erneuten Einreichung unten, damit auf keinem Track ein nicht konformes Bundle aktiv bleibt.
Testen Sie den Store-Build, bevor Sie entscheiden
Zuerst testenEin Debug-Build ist nicht das, was der Prüfer ausgeführt hat. Installieren Sie die App aus Ihrem Test-Track auf einem sauberen Gerät mit einem neuen Konto, über ein Netzwerk, das Sie nicht kontrollieren, und führen Sie die fünf Prüfungen durch. Entscheiden Sie erst danach.
Sign-in details korrigieren, dann zur Überprüfung senden
Zugang korrigierenAktualisieren Sie die Anweisungen mit wiederverwendbaren Zugangsdaten, die Einmalcodes umgehen, speichern Sie und senden Sie die Änderung dann über Publishing overview zur Überprüfung. Laut Google können Sie das tun, ohne das Richtlinien-Supportteam zu kontaktieren oder auf dessen Antwort zu warten.
Zweck ergänzen, nicht nur Fehler beheben
ÜberarbeitenBei Limited Functionality and Content geht es darum, wie viel die App leistet. Ergänzen Sie echte app-spezifische Funktionen oder Inhalte, bevor Sie erneut einreichen; eine Stabilitätskorrektur beantwortet diese Feststellung nicht.
Machen Sie das Design eindeutig, dann entscheiden Sie
KlarstellenAuch wenn ein Offline-Bildschirm, ein leerer Zustand oder eine ungewöhnliche Geste beabsichtigt ist, kann ein Prüfer das als fehlerhaft lesen. Ergänzen Sie einen sichtbaren Hinweis, eine Erklärung und eine nächste Aktion. Sie können mit Belegen Einspruch einlegen, aber ein klarerer Bildschirm räumt den Zweifel auch für den nächsten Prüfer aus.
Mit Belegen Einspruch einlegen
EinspruchSie haben den Store-Build auf einem sauberen Gerät und in einem anderen Netzwerk getestet und keinen Fehler gefunden. Legen Sie einmal Einspruch ein, mit dem Versionscode, dem Gerät und der Android-Version, den genauen Schritten und einer Bildschirmaufzeichnung des Ablaufs, den die Meldung nennt.
Einen korrigierten Release erneut einreichen
Googles Schritte zur erneuten Einreichung umfassen mehr als das Hochladen eines neuen Versionscodes:
- Lesen Sie die Richtlinie, die in der E-Mail und Ihren Benachrichtigungen genannt wird, und prüfen Sie die App auch anhand der übrigen Richtlinien; Google warnt, dass weitere Verstöße zu weiteren Durchsetzungsmaßnahmen führen können.
- Aktualisieren Sie jeden Release-Typ, der die betroffene Version enthält, nicht nur die Produktion: offene, geschlossene und interne Test-Tracks eingeschlossen.
- Laden Sie das korrigierte App Bundle hoch und deaktivieren Sie die nicht konformen. Google warnt: Wenn Sie sie nicht deaktivieren, schlägt die erneute Einreichung fehl, und Live-Versionen können entfernt werden.
- Wählen Sie in jedem betroffenen Track Manage track und Create new release, fügen Sie das korrigierte Bundle hinzu (oder verwerfen Sie einen Entwurf, der das fehlerhafte enthält) und stellen Sie sicher, dass die nicht konforme Version unter Not included aufgeführt ist.
- Speichern Sie, wählen Sie Review release und führen Sie den Release ein.
Danach wartet die Änderung auf die Verarbeitung. Google schreibt: "Die Verarbeitung kann einige Stunden oder bis zu sieben Tage dauern (in Ausnahmefällen auch länger)" (Festlegen, wann App-Änderungen überprüft und veröffentlicht werden).
Behoben, aber die Warnung ist noch da
Wenn eine korrigierte Version live ist und Policy status das Problem weiterhin anzeigt, vergleichen Sie die Versionscodes und Tracks, die die Warnung nennt, mit dem, was jetzt aktiv ist: Ein nicht konformes Bundle, das auf einem Test-Track verblieben ist, ist das Erste, was Sie ausschließen sollten. Eine neuere Version löscht nicht automatisch jeden Durchsetzungseintrag. Wenn alles übereinstimmt, wenden Sie sich mit den Versionscodes, den betroffenen Tracks und gegebenenfalls einer früheren Fallnummer an den Play Console-Support.
Einspruch gegen die Entscheidung einlegen
Google stellt Apps wieder her, wenn ein Fehler seinerseits vorlag und die App nicht gegen die Richtlinien verstößt. Um Einspruch einzulegen, folgen Sie den Anweisungen in der E-Mail zur Durchsetzungsmaßnahme oder nutzen Sie das Einspruchsformular von Google. Sie können pro Durchsetzungsmaßnahme einen Einspruch einreichen (Umgang mit Richtlinienverstößen und Einsprüchen), und Google beantwortet Einsprüche auf Chinesisch, Englisch, Japanisch und Koreanisch. Google veröffentlicht keine Antwortzeit für Einsprüche, und Entwicklerberichte vermischen Antworten auf Einsprüche mit späteren Release-Überprüfungen. Planen Sie also ohne festes Datum.
Formulieren Sie den Einspruch als Beleg, nicht als Ausdruck von Frust: den überprüften Versionscode, das Gerät und die Android-Version, auf denen Sie getestet haben, die genauen Schritte, eine Bildschirmaufzeichnung des Ablaufs, den die Meldung nennt, und was Sie gegebenenfalls geändert haben.
Schadet eine Ablehnung wegen Broken Functionality Ihrem Konto oder Ihrem geschlossenen Test?
Eine Ablehnung allein wirkt sich nicht auf den Status Ihres Entwicklerkontos aus. Wiederholte Ablehnungen können zu einer Sperrung führen, und Sperrungen zählen als Verwarnungen (Strikes). Beheben Sie also den Fehler, bevor Sie erneut einreichen. Was eine Ablehnung mit einem laufenden geschlossenen Test macht, ist nicht dokumentiert.
Googles Seite Enforcement Process (Durchsetzungsverfahren) beschreibt den Unterschied:
- "Ablehnungen wirken sich nicht auf den Status Ihres Google Play-Entwicklerkontos aus."
- "Wenn ein Update einer bestehenden App abgelehnt wurde, bleibt die vor dem Update veröffentlichte App-Version bei Google Play verfügbar."
- "Eine Sperrung kann die Folge schwerwiegender oder mehrfacher Richtlinienverstöße sowie wiederholter Ablehnungen oder Entfernungen von Apps sein."
Google nennt keine Anzahl von Ablehnungen, die unbedenklich wäre. Denselben Fehler erneut einzureichen, ist genau das Muster, das die dritte Zeile beschreibt.
Und der 14-tägige geschlossene Test?
Die Testanforderung von Google verlangt von privaten Konten, die nach dem 13. November 2023 erstellt wurden, mindestens 12 Tester, die mindestens 14 Tage fortlaufend angemeldet sind, bevor der Produktionszugriff beantragt wird. Sie sagt nicht, ob eine Richtlinien-Ablehnung eines Releases im geschlossenen Track diesen Zeitraum zurücksetzt, pausiert oder erhält, und Behauptungen in Foren in die eine oder andere Richtung sind Vermutungen. Was Sie prüfen können: ob Ihre Tester noch einen genehmigten Release auf dem Track haben und was das Dashboard zum Produktionszugriff anzeigt. Halten Sie die Tester angemeldet, während Sie den Fehler beheben, und fragen Sie den Play Console-Support zu Ihrem Fall, wenn sich das Dashboard ändert. Die Regel selbst wird in was 14 aufeinanderfolgende Tage bedeuten erklärt.
Lehnt Google eine WebView- oder TWA-App als fehlerhaft ab?
Nicht wegen der Technologie. Google dokumentiert sowohl Trusted Web Activities als auch WebView für Android-Apps, und keine Richtlinie verbietet diese Architektur. Die Fragen sind, ob die App funktioniert, ob sie genug Zweck hat und ob Sie das Recht haben, die Website einzubinden.
Wir erlauben keine Apps, deren Hauptzweck darin besteht, Affiliate-Traffic auf eine Website zu lenken oder eine Website ohne Erlaubnis des Website-Inhabers oder -Administrators in einer WebView darzustellen.
Für eine webbasierte App sind die Broken Functionality-Prüfungen dieselben wie für jede andere App: Die Website muss nach einer frischen Installation in der App laden, Offline- und Fehlerzustände müssen sich selbst erklären, und jeder Link muss irgendwohin führen. Wenn die App überwiegend eine dünne Ansicht einer Website ist, ist der Abschnitt Limited Functionality and Content das größere Risiko. Dass ein Wechsel von einer TWA zu einer WebView oder umgekehrt eine Ablehnung für sich genommen behebt, ist nicht belegt.
Wie hilft PrimeTestLab vor der nächsten Überprüfung?
Wir können Ihren Code nicht reparieren und Googles Entscheidung nicht ändern. Was wir liefern, ist die Testseite: echte Menschen auf echten Geräten, die Ihre App über Ihren geschlossenen Test nutzen, sodass Probleme wie die oben beschriebenen in ihrem Feedback auftauchen, bevor ein Prüfer sie findet.
PrimeTestLab stellt 12 oder mehr echte Tester auf echten Geräten mit Android 7 bis 17 bereit, die die vollen 14 Tage angemeldet bleiben, mit Teststart in 4-6 Stunden. Wir haben betreute Tests für 12.100+ Apps mit Testern in 120+ Ländern durchgeführt.
Selbst testen oder betreut testen
| Aufgabe | In Eigenregie | Mit PrimeTestLab |
|---|---|---|
| Tester finden | In EigenregieFreunde, Gruppen und Foren, meist mit ähnlichen Smartphones | Mit PrimeTestLabEchte Tester auf echten Geräten, Ihrer App zugewiesen |
| Streuung von Geräten und Android-Versionen | In EigenregieWas Ihre Freiwilligen gerade besitzen | Mit PrimeTestLabGeräte mit Android 7 bis 17 |
| Tägliche Nutzung und Feedback | In EigenregieHängt vom guten Willen ab | Mit PrimeTestLabTester nutzen die App und melden, was kaputtgeht |
| 12 Tester 14 Tage lang angemeldet halten | In EigenregieSie laufen Aussteigern selbst hinterher | Mit PrimeTestLabAussteiger werden ersetzt, damit die Anzahl hält |
| Code und Meldung beheben | In EigenregieSie | Mit PrimeTestLabWeiterhin Sie; wir berichten, was die Tester gefunden haben |
| Googles Entscheidung | In EigenregieGoogle | Mit PrimeTestLabWeiterhin Google; niemand kann eine Genehmigung versprechen |
Wenn Google nach Ihrem vollständigen PrimeTestLab-Test keinen Produktionszugriff gewährt hat, wählen Sie zwischen einem kostenlosen neuen Test und einer vollständigen Rückerstattung; siehe die Richtlinie zu Rückerstattung und kostenlosem neuen Test. Das deckt die Testanforderung ab, nicht eine Richtlinien-Ablehnung Ihres Codes. Die Pläne beginnen bei $19.99 plus 5% Servicegebühr an der Kasse (mindestens $1.50), und die einmalige Registrierungsgebühr von $25 bei Google kommt separat hinzu. Vergleichen Sie die Pläne auf der Preisseite.
Häufig gestellte Fragen
Was ist die Broken Functionality-Richtlinie bei Google Play?
Sie ist ein Abschnitt der Google Play-Richtlinie Functionality, Content, and User Experience. Google erlaubt keine Apps, die abstürzen, zwangsweise beendet werden, einfrieren oder auf andere Weise nicht normal funktionieren, und nennt Apps, die sich nicht installieren lassen, Apps, die sich installieren lassen, aber nicht laden, und Apps, die laden, aber nicht reagieren, als häufige Verstöße.
Ist Broken Functionality dasselbe wie Minimum Functionality?
Nein. Minimum Functionality ist der ältere Name für das, was Google heute Limited Functionality and Content nennt; dieser Abschnitt betrifft Apps mit zu wenig Zweck oder Inhalt. Broken Functionality betrifft Apps, die in der eingereichten Form nicht funktionieren. Beide stehen in derselben Richtlinie, erfordern aber unterschiedliche Lösungen.
Wo hinterlege ich Demo-Zugangsdaten für die Überprüfung durch Google Play?
Gehen Sie in der Play Console zu Policy and programs, dann App content, dann Sign-in details (früher App access). Wählen Sie Start oder Manage, fügen Sie die Anweisungen hinzu und speichern Sie, und senden Sie die Änderung dann über die Seite Publishing overview zur Überprüfung. Die Zugangsdaten sollten wiederverwendbar sein und dürfen nicht von einem Einmalcode abhängen, der an Ihr Telefon gesendet wird.
Zählt eine Ablehnung als Verwarnung für mein Entwicklerkonto?
Laut Google wirken sich Ablehnungen nicht auf den Status Ihres Entwicklerkontos aus. Sperrungen zählen als Verwarnungen, und Google nennt wiederholte Ablehnungen oder Entfernungen von Apps unter den Gründen für eine Sperrung. Beheben Sie also das genannte Problem, bevor Sie erneut einreichen.
Wie lange dauert die Überprüfung, nachdem ich eine korrigierte App erneut eingereicht habe?
Laut Google kann die Verarbeitung von App-Änderungen einige Stunden oder bis zu sieben Tage dauern, in Ausnahmefällen auch länger. Das ist die Überprüfung des korrigierten Releases. Für Einsprüche veröffentlicht Google keine Antwortzeit.
Kann ich Einspruch gegen eine Ablehnung wegen Broken Functionality einlegen?
Ja, wenn Sie der Meinung sind, dass die Feststellung falsch ist. Folgen Sie den Anweisungen in der E-Mail zur Durchsetzungsmaßnahme oder nutzen Sie das Einspruchsformular von Google. Sie können pro Durchsetzungsmaßnahme einen Einspruch einreichen. Geben Sie deshalb den überprüften Versionscode, das Gerät und die getesteten Schritte sowie eine Aufzeichnung des Ablaufs an, den die Meldung nennt.
Setzt eine Ablehnung wegen Broken Functionality meinen 14-tägigen geschlossenen Test zurück?
Google dokumentiert das nicht. Die Anforderung lautet: mindestens 12 Tester, die mindestens 14 Tage fortlaufend angemeldet sind, bevor Sie den Produktionszugriff beantragen. Halten Sie die Tester angemeldet, während Sie den Release korrigieren, behalten Sie das Dashboard im Blick und fragen Sie den Play Console-Support, wenn sich Ihre Berechtigung ändert.
Warum wurde meine App abgelehnt, wenn sie auf meinem Smartphone funktioniert?
Ihr Smartphone deckt einen Build, ein Konto, einen Datenbestand und ein Netzwerk ab. Installieren Sie den Release, den Google Play verteilt, auf einem sauberen Gerät mit einem neuen Konto und testen Sie dann leere Inhalte und fehlgeschlagene Netzwerkanfragen. Ein Store-Build, der mit dem App-Signaturschlüssel signiert ist, kann dort fehlschlagen, wo Ihr Debug-Build funktioniert. Testen Sie also den Build, den der Prüfer installiert hat.
Meine App nutzt Google Sign-In oder einen Einmalcode. Was sollte ich den Prüfern geben?
Google verlangt Anmeldedaten, die wiederverwendbar sind, von jedem Standort aus funktionieren und Einmalpasswörter oder die Bestätigung in zwei Schritten umgehen. Geben Sie den Prüfern ein Testkonto und Anweisungen, die jede eingeschränkte Funktion erreichen, auch kostenpflichtige. Testen Sie die angegebenen Daten dann selbst genau so; zu erklären, wie ein normaler Nutzer einen Code erhält, ist kein funktionierender Zugang.
Google hat keinen Screenshot und kein Absturzprotokoll geschickt. Was nun?
Prüfen Sie Policy status und die E-Mail zur Durchsetzungsmaßnahme auf die betroffene Version und alle Details, die Google ergänzt hat. Reproduzieren Sie dann den Hauptablauf auf dem eingereichten Release und zeichnen Sie Ihr eigenes Video und Ihre eigenen Logs auf. Eine saubere Android Vitals-Seite oder ein sauberer Pre-Launch-Bericht beweist nicht, dass jeder Bildschirm und jede Backend-Anfrage beim Prüfer funktioniert hat.
Werden TWA- und WebView-Apps automatisch abgelehnt?
Nein. Google dokumentiert beide Technologien, und keine Richtlinie verbietet sie. Google schränkt allerdings Apps ein, die eine Website ohne Erlaubnis des Inhabers einbinden, sowie Apps mit zu wenig Funktionen oder Inhalten. Diagnostizieren Sie den tatsächlichen Fehler, etwa Login-, Navigations- oder Netzwerkfehler; der Wechsel von einer Wrapper-Technik zur anderen ist keine dokumentierte Lösung.
Das Fazit
Fazit
Eine Ablehnung wegen Broken Functionality besagt, dass der von Google überprüfte Release nicht funktioniert hat: Er ist abgestürzt, eingefroren, hat nicht geladen oder nicht reagiert. Lesen Sie, welche Richtlinie die Meldung nennt, reproduzieren Sie auf dem Build, den Google Play verteilt, stellen Sie sicher, dass sich Prüfer über Sign-in details anmelden können, testen Sie das Backend von außerhalb Ihres Netzwerks und sorgen Sie dafür, dass jedes Bedienelement und jeder leere Bildschirm sich selbst erklärt. Beheben Sie den Fehler auf jedem betroffenen Track und senden Sie den korrigierten Release zur Überprüfung. Legen Sie nur mit Belegen Einspruch ein, dass die Feststellung falsch war. Eine Ablehnung allein ist keine Verwarnung, aber wiederholte erneute Einreichungen ohne Korrektur können zu einer führen.
Wenn echte Menschen auf echten Geräten den fehlerhaften Bildschirm finden sollen, bevor der nächste Prüfer es tut, übernimmt PrimeTestLab die Seite des geschlossenen Tests, während Sie die App korrigieren.
Offizielle Google-Dokumentation
Was sich auf dieser Seite ändern kann
- Bezeichnungen in der Play Console ändern sich. Sign-in details hieß bis vor Kurzem App access, und einige übersetzte Hilfeseiten verwenden noch den alten Namen.
- Der Wortlaut der Meldungen wird nicht als Vorlage veröffentlicht und unterscheidet sich von Fall zu Fall; verlassen Sie sich eher auf Ihre eigene E-Mail und Ihre Seite Policy status als auf ein Beispiel hier.
- Google dokumentiert nicht, was eine Richtlinien-Ablehnung mit einem laufenden geschlossenen Test macht. Wenn Google eine Regel veröffentlicht, folgt diese Seite ihr.
Quellen geprüft am 16. Oktober 2026.