Richtlinie zu fehlerhafter Funktionalität: warum Google eine App ablehnt, die auf Ihrem Handy einwandfrei läuft

Google schickt Ihnen eine Zeile: Ihre App verstößt gegen die Richtlinie zu fehlerhafter Funktionalität (Broken Functionality). Kein Stacktrace, kein Screenshot, keine Schritte zum Nachstellen. Sie installieren denselben Release-Build auf Ihrem eigenen Gerät und alles läuft. Was ändern Sie also vor dem nächsten Einreichen? Meist nichts am Code — der Prüfer ist nie so weit gekommen.

Zuletzt aktualisiert: Juli 2026

Was in der Richtlinie tatsächlich steht

Broken Functionality ist ein Abschnitt der Google-Play-Richtlinie „Funktionalität, Inhalte und Nutzerfreundlichkeit“. Die Regel ist ein Satz: Apps, die abstürzen, sich unerwartet beenden, einfrieren oder anderweitig nicht normal funktionieren, sind nicht zulässig. Google nennt genau drei Beispiele — Apps, die sich nicht installieren lassen, Apps, die sich installieren, aber nicht laden, und Apps, die laden, aber nicht reagieren.

Lesen Sie das noch einmal und achten Sie darauf, was NICHT drinsteht. Kein Wort über Ihre Architektur, Ihre Testabdeckung, Ihr Framework oder Ihre Codequalität. Es ist eine Verhaltensrichtlinie. Sie beschreibt, was auf einem Gerät, in einer Sitzung, in einem Netz passiert ist, während einer Prüfung von wenigen Minuten. Dieser Unterschied ist das ganze Spiel: Besserer Code hilft nicht, nur eine App, die die ersten fünf Minuten mit einem Fremden übersteht.

Google-Play-Richtlinie: Funktionalität, Inhalte und Nutzerfreundlichkeit

Finden Sie Ihre genaue Ablehnungszeile

Der Mailtext ist ein Baustein, der an Tausende Entwickler geht. Die Fehlerzeile darunter ist es nicht — sie ist das Nächste an einem Fehlerbericht, das Sie bekommen werden. Suchen Sie Ihre in der ersten Spalte.

Die Zeile, die Google Ihnen gegeben hat	Was der Prüfer gesehen hat	Die tatsächlich wahrscheinlichste Ursache	Das machen Sie vor dem erneuten Einreichen
`App doesn't install`	Aus dem Artefakt wurde auf dem Prüfgerät nie eine lauffähige Installation.	Ein Fehler bei der Installation, kein Laufzeitfehler: eine minSdkVersion oberhalb des Testgeräts, ein fehlender ABI- oder Density-Split oder ein Signaturkonflikt.	Installieren Sie das Artefakt, das Google wirklich hat — laden Sie es aus Ihrem internen Testtrack herunter, nicht aus Android Studio — auf einem Gerät, das zu Ihrer deklarierten minSdk passt.
`App installs, but doesn't load`	Sie startete und blieb dann auf einem Bildschirm stehen, der nie nutzbar wurde.	Der Splash wartet auf etwas, das die Sitzung des Prüfers nicht hat: ein Auth-Token, einen ersten API-Aufruf, einen Remote-Config-Abruf, ein FCM-Token.	Starten Sie die App kalt im Flugmodus, ohne zwischengespeicherte Sitzung. Wenn sie hängt statt einen Fehler zu zeigen, haben Sie Ihre Ablehnung gerade nachgestellt.
`App loads, but crashes`	Ein Absturz in den ersten Minuten der Sitzung.	Ein Erstnutzungs-Pfad, den Sie lokal nie treffen. Ihr Gerät hat Daten, das des Prüfers keine — eine leere Liste oder ein Profil ohne Werte legt den Bildschirm lahm.	Pre-Launch-Report → Tab Stabilität. Der Stacktrace liegt dort bereits, von einem echten Gerät, auf Googles Seite.
`App loads, but is not responsive`	Tippen bewirkte nichts, oder die Oberfläche fror ein.	Arbeit auf dem Main-Thread beim Start: ein synchroner Netzwerkaufruf, ein großes JSON-Parsing, eine Datenbankmigration.	Verlagern Sie das vom Main-Thread. Android löst nach 5 Sekunden ohne verarbeitetes Eingabeereignis einen ANR aus — ein Prüfer gibt lange vor dem System auf.
`App contains icon(s) or button(s) that are not responsive`	Bestimmte Bedienelemente taten beim Antippen nichts.	Tote Bedienelemente: eine Kachel „Demnächst“, ein CTA hinter einem ausgeschalteten Feature-Flag, eine Menüzeile ohne Ziel, ein Link, der auf 404 läuft.	Tippen Sie bei einer frischen Installation ohne Konto jedes Bedienelement der App an. Alles, was nicht reagiert, wird angeschlossen oder entfernt — eine dritte Möglichkeit gibt es nicht.

Fehlerzeilen, wie sie unter dem Broken-Functionality-Verdikt in der Play Console erscheinen. Die erste, dritte und vierte sind Googles eigene veröffentlichte Beispiele; die übrigen sind wiederkehrende Meldungen aus der Play-Entwicklercommunity.

Broken Functionality ist nicht Limited Functionality

Das sind zwei verschiedene Abschnitte derselben Richtlinienseite, und sie haben gegensätzliche Lösungen. Broken Functionality heißt: Ihre App versagt. Limited Functionality and Content heißt: Ihre App funktioniert einwandfrei und ist trotzdem keine Installation wert — ein WebView-Mantel um Ihre Website, ein einzelner statischer Bildschirm, ein Viewer für ein einziges PDF. Wer die beiden verwechselt, baut Features, während er einen Hänger beheben müsste.

	Broken Functionality	Limited Functionality and Content
Die Regel	„Apps, die abstürzen, sich unerwartet beenden, einfrieren oder anderweitig nicht normal funktionieren, sind nicht zulässig.“	„Apps, die nur über eingeschränkte Funktionen und Inhalte verfügen, sind nicht zulässig.“
Was schiefging	Ihre App hat nicht getan, was sie verspricht.	Ihre App hat genau das getan, was sie verspricht. Genau das ist das Problem.
Typischer Auslöser	Hängender Splash, Absturz beim ersten Start, totes Bedienelement, unerreichbares Backend.	Website in einer WebView, ein Textbildschirm, ein Mantel ohne nativen Mehrwert.
Die Lösung	Den vorhandenen Ablauf auf einem frischen Gerät zum Laufen bringen.	Etwas bauen, das ein Browser-Tab nicht kann — oder es nicht veröffentlichen.
Der falsche Zug	Features hinzufügen.	Fehler beheben.

Unser eigener Leitfaden zu Google-Play-Ablehnungen hat beides früher in einem einzigen Punkt vermischt. Das war falsch, und es ist ein guter Teil des Grundes, warum es diese Seite gibt. Why Google Play rejects apps

Ihre App funktioniert. Der Prüfer kam trotzdem nicht hinein.

Hier liegen die meisten dieser Ablehnungen tatsächlich, und fast niemand schreibt darüber. Ihr Build ist in Ordnung. Ihr Rechner ist nicht der Rechner des Prüfers. Gehen Sie diese Liste durch, bevor Sie eine Zeile Code anfassen.

Ein Anmeldebildschirm ohne funktionierende Testzugangsdaten. Der Prüfer öffnet Ihre App, sieht ein Anmeldeformular, hat nichts einzutippen und schließt sie wieder. Von außen ist das nicht zu unterscheiden von einer App, die sich „installiert, aber nicht lädt“.
SMS- oder E-Mail-OTP. Sie haben ein Demokonto geliefert, aber der Code geht an ein Telefon auf Ihrem Schreibtisch. Google ist eindeutig: Wenn Ihre App normalerweise eine Zwei-Faktor-Bestätigung oder ein Einmalpasswort verlangt, müssen Sie wiederverwendbare Zugangsdaten liefern, die das umgehen.
Ein geografisch gesperrtes oder per IP-Allowlist geschütztes Backend. Die Prüfung läuft nicht aus Ihrem Büro. Wenn Ihre API Ihren Büro-CIDR freischaltet oder die App Länder blockiert, in denen Sie nicht verkaufen, landet der Prüfer auf Ihrem Fehlerbildschirm. Googles eigene Formulierung: Die Anmeldedaten müssen unabhängig vom Standort des Nutzers gültig sein, und eine Geosperre braucht Master-Zugangsdaten.
Eine Staging- oder localhost-Basis-URL im Release-Build. Das klingt zu dumm, um zu passieren, und passiert ständig — eine falsch konfigurierte Build-Variante, eine nicht getauschte .env, eine Debug-URL, die einen Merge überlebt hat. Ihr Laptop löst diesen Host über das Büro-VPN oder eine /etc/hosts-Zeile auf. Das Prüfgerät nicht.
Ein Backend, das schläft. Scale-to-zero und Gratis-Tarife starten kalt in 5 bis 30 Sekunden. Ihre erste Anfrage am Morgen ist langsam und Sie merken es längst nicht mehr. Jede Anfrage des Prüfers ist eine erste Anfrage am Morgen.
Ein Feature-Flag, das aus blieb. Sie haben mit deaktiviertem Remote-Flag ausgeliefert und wollten es nach der Freigabe umlegen. Der Prüfer testet, was vor ihm liegt, findet einen leeren Bildschirm und lehnt ab.
Ein abgelaufener API-Schlüssel oder ein Maps-/Firebase-Schlüssel, der auf Ihr Debug-Signaturzertifikat beschränkt ist. Play App Signing signiert Ihren Release mit einem anderen SHA-1 als Ihr Debug-Schlüssel. Jede Kachel und jeder Aufruf scheitert dann — nur in der Produktion, nie auf Ihrem Rechner.

Jeder einzelne Punkt erzeugt eine App, die auf Ihrem Schreibtisch makellos und in der Prüfung kaputt ist. Und keiner davon taucht je in Ihren Absturzberichten auf, weil nichts abgestürzt ist.

Wie gebe ich Google-Play-Prüfern ein Testkonto?

Gehen Sie in der Play Console zu Richtlinien und Programme → App-Inhalte → Anmeldedaten → Start (oder Verwalten), klicken Sie auf „+ Neue Anleitung hinzufügen“ und tragen Sie die Zugangsdaten ein. Sie können bis zu fünf Sätze hinterlegen. Öffnen Sie danach die Seite „Übersicht über Veröffentlichungen“ und klicken Sie auf „Zur Überprüfung senden“. Wenn Sie nur die Zugangsdaten geändert haben, müssen Sie kein neues .aab hochladen.

Googles Anforderungen an diese Angaben, in ihren Worten:

Jederzeit erreichbar, wiederverwendbar und unabhängig vom Standort des Nutzers gültig.
Jederzeit gepflegt und fehlerfrei.
Auf Englisch bereitgestellt.
Wenn die Anmeldung weder numerisch noch alphanumerisch ist — ein QR-Code oder Barcode — erzeugen Sie eine statische URL und laden Sie diese in der Play Console hoch.
Wenn Nutzer eine eigene PIN oder ein eigenes Passwort setzen, um an Inhalte in der App zu kommen, geben Sie klare Anweisungen.
Wenn Sie auf „Mit Google anmelden“, Facebook oder Ähnliches setzen, liefern Sie alle Kontoinformationen plus eine ausführliche Anleitung.

Der Fehlerfall, vor dem niemand warnt: Ihr Demokonto funktioniert — und dann eben nicht mehr. Eine 30-Tage-Testphase läuft ab. Ein Rate Limiter blockt es bei der dritten Prüfung. Jemand im Team setzt freitags die Testdatenbank zurück. „Jederzeit erreichbar“ leistet in diesem Satz sehr viel Arbeit — behandeln Sie das Prüfkonto wie Produktionsdaten.

Ein Konto reicht auch nicht. Der Prüfer muss jedes Feature erreichen, das Ihr Store-Eintrag bewirbt. Wenn der Premium-Tab einen bezahlten Tarif braucht, muss das Demokonto diese Berechtigung bereits haben.

Google Play: Anforderungen an Anmeldedaten für die Überprüfung

Der Pre-Launch-Report belügt Sie, wenn Sie einen Anmeldebildschirm haben

Der Robo-Test kann Ihre Testzugangsdaten nur in Standard-Android-Widgets und in Compose eintippen. Er kann sich nicht durch einen WebView-basierten Anmeldeablauf klicken und keine Bedienelemente steuern, die Ihre App in OpenGL rendert. Eine React-Native- oder Flutter-App mit WebView-Login bekommt daher einen sauberen, absturzfreien Pre-Launch-Report über genau einen Bildschirm: den Anmeldebildschirm. Grüner Bericht, abgelehnte App.

Hinterlegen Sie ein Wegwerf-Testkonto unter Testen und veröffentlichen → Testen → Pre-Launch-Report → Einstellungen. Nie ein echtes Konto. Lesen Sie dann den Tab Screenshots vor dem Tab Stabilität — wenn alle 20 Screenshots Ihr Anmeldebildschirm sind, haben Sie Ihre Ablehnung gefunden, und es war nie ein Absturz.

Google Play: mit dem Pre-Launch-Report Probleme erkennen

Ab wann gilt langsam als eingefroren?

Android meldet einen ANR, wenn Ihre App nicht innerhalb von 5 Sekunden auf ein Eingabeereignis reagiert. Dieselbe 5-Sekunden-Grenze gilt für einen Broadcast-Receiver im Vordergrund und für den Aufruf von startForeground() nach startForegroundService(). Das sind die Grenzen des Systems. Die Geduld eines Prüfers ist deutlich kürzer, und gegen Langeweile gibt es keinen Einspruch.

Zur Einordnung der Zahlen, die Google selbst für inakzeptabel hält: Die Android-vitals-Schwellen für schlechtes Verhalten liegen bei 1,09 % nutzerseitig wahrgenommener Absturzrate und 0,47 % nutzerseitig wahrgenommener ANR-Rate über alle Geräte oder 8 % auf einem einzelnen Modell. Wer sie überschreitet, bekommt einen Warnhinweis im Store-Eintrag — aber Sie können weit darunter liegen und trotzdem abgelehnt werden, denn eine Prüfung ist eine Sitzung, keine Verteilung.

So sieht das in der Praxis aus. Ein Entwickler postete genau die Zeile „App installs, but doesn't load“ im Android-Builder-Forum und beteuerte, es sei nichts kaputt; auf Nachfrage erwähnte er, dass „der erste Bildschirm manchmal ein paar Sekunden stehen bleibt“. Kein Absturz. Kein ANR. Unter der 5-Sekunden-Grenze des Systems. Trotzdem abgelehnt.

Womit wir beim effizientesten Weg wären, sich diese Ablehnung einzuhandeln: der Splashscreen, der ein totes Backend verdeckt. Er sieht identisch aus, ob Ihre API in 200 ms geantwortet hat oder nie. Geben Sie ihm ein Timeout — 3 Sekunden, dann ein echter Fehlerbildschirm mit einer Schaltfläche „Erneut versuchen“. Eine App, die sagt „Server nicht erreichbar“, ist eine funktionierende App mit einem schlechten Tag. Eine App, die ewig dreht, ist „installs, but doesn't load“.

Android Developers: ANRs · Android-vitals-Schwellenwerte

In 30 Minuten nachstellen

Versetzen Sie sich in den Zustand des Prüfers. Ein zurückgesetzter Emulator oder ein Zweitgerät: kein angemeldetes Konto, keine zwischengespeicherte Sitzung, kein VPN, kein /etc/hosts-Eintrag, mobile Daten statt Büro-WLAN. Installieren Sie das Artefakt, das Google hat — laden Sie das .aab aus dem internen Testtrack, statt lokal zu bauen. Allein dieser Schritt findet die meisten Fälle.
Öffnen Sie den Pre-Launch-Report (Testen und veröffentlichen → Pre-Launch-Report). Zuerst der Tab Screenshots: Ist der Crawler an Ihrem Login vorbeigekommen? Dann Stabilität für den Stacktrace und Leistung für die Startzeit.
Lassen Sie beim Kaltstart adb logcat mitlaufen, gefiltert auf Ihren Prozess: adb logcat --pid=$(adb shell pidof -s com.your.package). Achten Sie auf die Anfrage, die nie zurückkommt. Das ist Ihr Splash-Hänger.
Prüfen Sie Crashlytics und Play Console → Qualität → Android vitals → Abstürze und ANRs, gefiltert auf den eingereichten Versionscode. Sind beide leer, war Ihr Problem nie ein Absturz — zurück zur Liste der Prüfumgebung weiter oben.
Gehen Sie Ihren eigenen Store-Eintrag durch. Öffnen Sie jeden Screenshot, lesen Sie jeden Feature-Satz und machen Sie auf dem frischen Gerät genau das, der Reihe nach.

Ihr Store-Eintrag ist das Testskript

Prüfer raten nicht, was Ihre App können soll. Sie lesen Ihren Eintrag und Ihre Screenshots und prüfen dann nach. Damit wird Ihr eigener Werbetext zur Spezifikation, an der Sie gemessen werden. Ein Screenshot eines Features, das nächsten Monat kommt, ist heute ein kaputtes Feature. Genauso eine Kachel „Demnächst“, eine Einstellungszeile, die nichts öffnet, und ein Support-Link auf einen 404. Entfernen Sie den Screenshot oder liefern Sie das Feature aus.

Erneut einreichen oder Einspruch einlegen?

Reichen Sie erneut ein, wenn Sie eine konkrete Ursache gefunden und behoben haben: neuer Versionscode, App-Inhalte aktualisiert, zur Überprüfung senden. Legen Sie nur Einspruch ein, wenn Sie sicher sind, dass nichts kaputt ist, und es zeigen können — Sie haben einen Einspruch pro Maßnahme, und die Antwort kommt in der Regel in etwa 2 Werktagen.

Deutlich gesagt: Die meisten „an meiner App ist nichts kaputt!!!“-Threads in der Play-Community enden damit, dass der Entwickler eine Anmeldeschranke oder ein schlafendes Backend findet. Machen Sie zuerst den 30-Minuten-Durchgang. Wenn Sie Einspruch einlegen und sich irren, haben Sie Ihren einen Einspruch und eine Woche Umsatz verbraucht.

So oder so: Sagen Sie, was sich geändert hat. Googles Prüfer arbeiten mit derselben einen Zeile wie Sie. Fügen Sie das hier in das Einspruchsformular ein oder in das Anweisungsfeld der Anmeldedaten, wenn Sie erneut einreichen:

brokenFunctionality.template

Apples Version derselben Ablehnung

Apple nennt das Guideline 2.1 — Performance — App Completeness, und es ist ihr meistgenannter Ablehnungsgrund. Dieselben Ursachen, andere Konsole: Das Demokonto kommt in App Store Connect → Ihre App → App-Prüfungsinformationen, mit aktiviertem Schalter „Anmeldung erforderlich“, plus das Feld Anmerkungen für alles, was ein Fremder nicht erraten kann. Ein Unterschied zählt in der Praxis sehr: Apple sagt Ihnen meist, welcher Bildschirm versagt hat, und hängt einen Screenshot an. Google gibt Ihnen eine Zeile. Diese Asymmetrie ist der Grund, warum es die Entschlüsselungstabelle oben geben musste.

Die häufigsten App-Store-Ablehnungsgründe

Was wir für Sie prüfen können — und was nicht

Laden Sie das .aab oder .apk hoch, das Sie einreichen wollen, und wir lesen sein Manifest. Von den 24 Android-Prüfungen im Werkzeug laufen 10 automatisch, und vier davon zeigen direkt auf Broken-Functionality-Ursachen:

usesCleartextTraffic — eine http://-Basis-URL, die auf Ihrem Rechner läuft und in einem Release-Build ab Android 9 stillschweigend blockiert wird.
android:debuggable — ein versehentlich ausgelieferter Debug-Build, der ohnehin für sich genommen eine sofortige Ablehnung bedeutet.
MAIN/LAUNCHER-Activity — kein startbarer Einstiegspunkt ist buchstäblich „app doesn't load“.
targetSdkVersion und minSdkVersion — der Widerspruch hinter „app doesn't install“ auf einem Prüfgerät.

Die anderen 14 sind die Fragen, die kein Parser für Sie beantworten kann, und drei davon sind genau diese Richtlinie: Ist jedes Feature funktionsfähig, ohne Platzhalter und tote Links, haben Sie auf echten Geräten getestet und die Android vitals geprüft, und tut die App wirklich etwas jenseits eines Website-Mantels?

Was wir schlicht nicht können: Wir führen Ihre App nicht aus. Wir können Ihnen nicht sagen, dass Ihr Backend schläft, Ihr Demokonto letzten Dienstag abgelaufen ist oder Ihr Maps-Schlüssel an den falschen SHA-1 gebunden ist. Kein Werkzeug, das eine Binärdatei liest, kann das. Dafür ist der 30-Minuten-Durchgang da.

Häufige Fragen

Was bedeutet „Your app contains content that isn't compliant with the Broken Functionality policy“?

Es bedeutet, dass Googles Prüfer Ihre App geöffnet hat und sie abgestürzt ist, eingefroren ist oder nie nutzbar wurde. Es ist ein Urteil über das Verhalten, keine Code-Review. Die kurze Zeile darunter — etwa „App installs, but doesn't load“ — ist die einzige Diagnose, die Sie bekommen. Fangen Sie dort an.

Meine App läuft einwandfrei. Warum sagt Google, sie sei kaputt?

Weil der Prüfer weder auf Ihrem Gerät noch in Ihrem Netz ist. Ein Anmeldebildschirm ohne Testzugangsdaten, eine API mit Allowlist auf Ihre Büro-IP, eine Staging-URL im Release-Build oder ein schlafendes Backend erzeugen alle eine App, die bei ihm scheitert und bei Ihnen läuft. Nichts davon taucht in Absturzberichten auf.

Muss ich ein neues .aab hochladen, um eine Broken-Functionality-Ablehnung zu beheben?

Nicht immer. Lag es an fehlenden oder abgelaufenen Anmeldedaten, aktualisieren Sie sie unter Richtlinien und Programme → App-Inhalte → Anmeldedaten und klicken auf der Seite „Übersicht über Veröffentlichungen“ auf „Zur Überprüfung senden“ — der vorhandene Build wird erneut eingereicht. Liegt es in der App, brauchen Sie einen neuen Versionscode.

Findet der Pre-Launch-Report Broken-Functionality-Probleme?

Teilweise. Der Robo-Test findet Abstürze und ANRs auf echten Geräten, kann sich aber nicht durch einen WebView-Login anmelden und keine in OpenGL gerenderten Bedienelemente steuern. Hat Ihre App einen WebView-Login, sieht der Bericht sauber aus und deckt doch nur den Anmeldebildschirm ab. Prüfen Sie im Tab Screenshots, wie weit der Crawler wirklich kam.

Kann ich gegen eine Broken-Functionality-Ablehnung Einspruch einlegen?

Ja — ein Einspruch pro Maßnahme, mit einer Antwort meist innerhalb von etwa 2 Werktagen. Legen Sie nur Einspruch ein, wenn Sie die Bedingungen des Prüfers auf einem frischen Gerät nachgestellt und wirklich nichts gefunden haben. Sonst beheben Sie die Ursache, erhöhen den Versionscode und reichen erneut ein; das ist schneller, als den Einspruch zu verlieren.

Wie lange dauert die Freigabe nach dem erneuten Einreichen?

Google nennt keine garantierte Bearbeitungszeit, und sie schwankt je nach Konto und Verstoßhistorie zwischen einem Tag und ein paar Wochen. Planen Sie damit, dass die erneute Einreichung Ihre letzte ist: Eine zweite Broken-Functionality-Ablehnung für dieselbe App kostet weit mehr Zeit, als der 30-minütige Diagnosedurchgang gekostet hätte.

Quellen

Prüfe deinen Build, bevor du einreichst

Lass deine .ipa oder .apk durch App Review Checker laufen und erkenne diese Probleme in Sekunden.

App prüfen