Google-Play-Richtlinien 2026: Checkliste vor der Einreichung

Drei Termine gehören bereits in den Release-Plan

Die unangenehmsten Play-Store-Probleme wirken zunächst oft harmlos. Der Build ist fertig, der Eintrag freigegeben, und dann passt eine Angabe zur Datensicherheit nicht zu einem SDK oder das Prüfkonto bleibt an einer Zwei-Faktor-Abfrage hängen. Aus einer Kleinigkeit werden neue Abstimmungen zwischen Entwicklung, Datenschutz und Marketing.

Deshalb ist die Veröffentlichung keine reine Aufgabe für den letzten Projekttag. Richtlinien greifen in den Funktionsumfang ein: Kontolöschung, sensible Berechtigungen, digitale Zahlungen, Moderation und der Zugang zu geschützten Bereichen. Wer diese Punkte erst beim Hochladen entdeckt, verschiebt nicht nur den Termin, sondern muss unter Umständen die App umbauen.

Diese Checkliste wurde am 8. September 2026 anhand der aktuellen Google-Unterlagen geprüft. Da sich Termine und Regeln ändern, sollte der Release-Verantwortliche die verlinkten Quellen vor jeder Einreichung erneut öffnen.

Bei neu angelegten persönlichen Entwicklerkonten gelten besondere Testvoraussetzungen. Wurde das Konto nach dem 13. November 2023 erstellt, verlangt Google in der Regel einen geschlossenen Test mit mindestens 12 dauerhaft angemeldeten Testpersonen über 14 aufeinanderfolgende Tage. Erst danach kann der Inhaber den Produktionszugang beantragen. Ein Testkreis, der die App lediglich installiert, liefert wenig überzeugende Antworten. Besser sind definierte Abläufe, ein Rückmeldekanal und dokumentierte Verbesserungen.

Für den Build ist der 31. August 2026 entscheidend. Ab diesem Datum müssen neue Smartphone- und Tablet-Apps sowie Updates Android 16 beziehungsweise API-Level 36 oder höher als Ziel verwenden. Für Wear OS und Android Automotive gilt API 35, für Android TV und XR API 34. Bestehende, nicht aktualisierte Apps haben eine eigene Sichtbarkeitsgrenze. Die aktuelle Ziel-API-Seite gehört deshalb in jeden Android-Wartungsplan.

Der nächste Schritt der Android-Entwicklerverifizierung beginnt am 30. September 2026, gilt aber nicht pauschal für alle Märkte. Der regionale Start betrifft Brasilien, Indonesien, Singapur und Thailand: teilnehmende Stores auf zertifizierten Geräten ab Android 7. Die globale Ausweitung ist für 2027 vorgesehen. Prüfen Sie den Paketstatus in Play Console, statt sich allein auf eine automatische Registrierung zu verlassen.

Eine Wahrheit für Build, Formulare und Store-Seite

In vielen Teams liegen nicht nur die Informationen verteilt; jede Abteilung trägt auch ein etwas anderes Bild der App im Kopf. Entwicklung kennt die SDKs, Marketing formuliert Nutzenversprechen, Datenschutz erstellt einen Text und eine weitere Person beantwortet die Fragen in Play Console. So entstehen Widersprüche, obwohl niemand nachlässig gearbeitet hat.

Wir empfehlen eine kompakte Freigabematrix, die eine benannte Person mit dem signierten Build abgleicht. Mehr Bürokratie braucht es dafür nicht:

Die Matrix muss zu genau dem Release-Kandidaten gehören, der eingereicht wird. Kommt danach ein Analyse- oder Werbe-SDK hinzu, ist die Datenerklärung erneut zu prüfen. Fällt eine Funktion aus dem ersten Umfang heraus, darf sie nicht in Screenshots weiterleben.

Datensicherheit beginnt bei den tatsächlichen Datenflüssen

Die Angaben im Bereich Datensicherheit sind keine Kurzfassung, die man allein aus der Datenschutzerklärung ableiten kann. Maßgeblich ist das Verhalten des Builds einschließlich aller eingebundenen Bibliotheken.

Erfassen Sie Registrierung, Analyseereignisse, Absturzberichte, Gerätekennungen, Standort, Support-Nachrichten, hochgeladene Dateien und Zahlungszustände. Prüfen Sie für jedes SDK, welche Funktionen wirklich aktiviert sind. Ein Analysewerkzeug ohne Werbekennung kann eine andere Erklärung erfordern als dasselbe Werkzeug mit Marketing-Verknüpfung.

Auch der Zweck zählt. Eine E-Mail-Adresse für Anmeldung und Wiederherstellung ist nicht automatisch mit einer Übergabe an ein Kampagnensystem gleichzusetzen. Halten Sie fest, ob Daten das Gerät verlassen, ob die Erhebung freiwillig ist, wie die Übertragung geschützt wird und wie eine Löschung erfolgt. Ein archivierter SDK-Bericht je Release erleichtert spätere Aktualisierungen erheblich.

Der Leitfaden zur Datenschutzerklärung für mobile Apps zeigt die Verbindung zwischen technischer Bestandsaufnahme, öffentlichem Text und Store-Angaben. Bei Gesundheits-, Finanz- oder Kinderprodukten ersetzt diese Arbeitsweise keine fachkundige rechtliche Prüfung.

Kontolöschung muss technisch vollständig sein

Kann ein Nutzer in der App ein Konto anlegen, braucht er nach der Google-Play-Vorgabe einen Löschweg in der App und eine von außen erreichbare Webseite für den Löschantrag. Eine allgemeine Supportadresse ohne klaren Ablauf reicht dafür nicht.

Testen Sie mit einem echten Konto. Ist die Funktion auffindbar? Benennt die Webseite App und Anbieter eindeutig? Wird erklärt, welche Daten gelöscht und welche aus zulässigen Gründen noch gespeichert werden? Werden Authentifizierung, Dateien, Newsletter, Supportsystem und verbundene Anbieter berücksichtigt?

Bei Abonnements, offenen Bestellungen, Rechnungen oder Streitfällen kann nicht jeder Datensatz sofort verschwinden. Genau deshalb muss das Produkt vor der Umsetzung festlegen, was der Nutzer erwarten darf und welche gesetzlichen Aufbewahrungspflichten fachlich geprüft werden müssen.

Berechtigungen auf den Kernzweck begrenzen

Vergleichen Sie Manifest, Laufzeitdialoge und Play-Console-Erklärungen. Alte Bibliotheken hinterlassen gelegentlich Berechtigungen, obwohl die dazugehörige Funktion längst entfernt wurde. Für jeden sensiblen Zugriff sollte das Team eine konkrete Nutzerhandlung nennen können, die ohne ihn nicht funktioniert.

Nutzen Sie möglichst enge Android-Schnittstellen. Für die Auswahl eines Bildes ist der Foto-Picker meist passender als ein weitreichender Medienzugriff. Eine einzelne Kontaktauswahl ist kein Grund, das gesamte Adressbuch zu lesen. Dauerhafter präziser Standortzugriff passt eher zu aktiver Kurierverfolgung als zu einer einmaligen Filialsuche.

Für Ende Oktober 2026 hat Google weitere Richtlinien zu Kontakten und genauer Standortbestimmung sowie zusätzliche Vorabprüfungen angekündigt. Wer Android 17 als Ziel plant, sollte Contact Picker und Location Button früh prüfen. Technische Schutzmaßnahmen, Serverberechtigungen und sichere Speicherung behandelt die Android-Sicherheitscheckliste.

Prüfer dürfen nicht an Anmeldung oder Bezahlschranke scheitern

Geschützte App-Bereiche brauchen in Play Console dauerhaft nutzbare Zugangsdaten. Sie müssen unabhängig vom Standort funktionieren und während der gesamten Veröffentlichung gepflegt werden. Ein einmaliges SMS-Kennwort, eine standortgebundene Anmeldung oder ein abgelaufener Testtarif blockieren die Prüfung.

Schreiben Sie eine kurze Route: anmelden, Rolle wählen, Kernfunktion erreichen, einen geschützten Inhalt öffnen und bei Bedarf einen Testkauf oder eine Buchung nachvollziehen. Google verlangt die Zugangshinweise auf Englisch. Bei einer deutschsprachigen Oberfläche helfen die sichtbaren deutschen Schaltflächennamen in Klammern.

Lassen Sie diese Anleitung auf einem frischen Gerät von einer unbeteiligten Person testen. Benötigt sie interne Hilfe, ist der Ablauf noch nicht prüfbar.

Store-Metadaten müssen belegbar sein

Die Metadatenrichtlinie gilt für jede Sprachfassung. App-Name, Kurzbeschreibung, Langtext, Symbol, Feature-Grafik, Screenshots und Video dürfen keine noch nicht verfügbare Funktion, irreführende Automatisierung oder nicht belegte Auszeichnung zeigen. Unnatürliche Wiederholungen von Suchbegriffen helfen weder Nutzern noch der Richtlinienprüfung.

Verwenden Sie echte Ansichten des aktuellen Produkts. Grafische Rahmen und Erläuterungen sind möglich, solange der gezeigte Ablauf tatsächlich existiert. Text in Screenshots sollte je Store-Sprache lokalisiert sein. Hinweise zu Formaten stehen in den Google-Play-Screenshot-Anforderungen, Marktvarianten in der Lokalisierungscheckliste.

Eine einfache Gegenprobe lautet: Kann ein Prüfer jedes zentrale Versprechen im Build finden? Sind Abopreis und Laufzeit vor dem Kauf verständlich? Sieht eine manuelle Dienstleistung nicht versehentlich wie ein vollständig automatisches Ergebnis aus?

Sondererklärungen folgen der Funktion, nicht dem Wunschetikett

Je nach Produkt fragt Play Console nach Werbung, Zielgruppe, Altersfreigabe, Nachrichten, Gesundheit, Finanzfunktionen, staatlichem Bezug oder weiteren sensiblen Bereichen. Die bequemste Kategorie ist nicht automatisch die richtige. Funktionen, Inhalte und tatsächliche Zielgruppe entscheiden.

Bei von Nutzern erzeugten Inhalten gehören Regeln, Melden, Blockieren und ein betreuter Moderationsprozess zum ersten öffentlichen Umfang. Kinder als Zielgruppe lösen zusätzliche Families-Anforderungen aus. Gesundheits- und Finanz-Apps müssen Aussagen und Formulare besonders sorgfältig abgleichen. Für digitale Inhalte und Funktionen ist vor der Umsetzung die aktuelle Zahlungsrichtlinie samt anwendbaren Ausnahmen zu prüfen.

Solche Anforderungen sind Entwicklungsaufwand. Ein privater Chat braucht neben Nachrichten auch Missbrauchsmeldung, Sperre, Supportzugriff und Aufbewahrungsregeln. Ein Abo benötigt Kaufwiederherstellung, Kündigungszustand, klare Bedingungen und Tests. Der Appfyl-Fragebogen zur Aufwandsschätzung macht diese Abhängigkeiten früh sichtbar.

Den signierten Release-Build prüfen

Nicht die Debug-Version, sondern das signierte App Bundle mit produktionsnaher Infrastruktur zählt. Führen Sie Neuinstallation, Update, Registrierung, Wiederherstellung, Löschung, verweigerte Berechtigungen, schwaches Netz, Kernkauf, Deep Links und alle Prüferrollen durch. Testzahlungen dürfen nicht versehentlich echte Belastungen auslösen.

Vorabprüfungen in Play Console sind hilfreich, decken aber nur einen Teil der Richtlinien ab. Für Abstürze, ANR, Geräteabdeckung und Nutzererlebnis ergänzen die Google-Play-Qualitätscheckliste und die QA-Checkliste für mobile Apps diesen Artikel.

Die letzten 48 Stunden vor der Einreichung

Zwei Tage vor Abgabe sollten keine optionalen SDKs und keine spontanen Werbeversprechen mehr in den Release rutschen. Am ersten Tag bestätigt Technik Paketname, Signatur, Ziel-API, Berechtigungen, SDKs, Löschung und Testzugang. Produkt prüft Zahlungen, Rollen, Moderation und Sondererklärungen. Marketing gleicht Texte und Bilder mit der App ab.

Am zweiten Tag folgt ein vollständiger Probelauf auf einem sauberen Gerät. Danach kontrolliert die Release-Verantwortung alle öffentlichen Links, speichert den Stand der Erklärungen und verifiziert, dass Publisher-Konto und Schlüssel organisatorisch abgesichert sind.

Planen Sie trotzdem Zeit für Rückfragen oder Ablehnung ein. Der Launch-Leitfaden verbindet Store-Freigabe mit Analyse, Support und Überwachung nach Veröffentlichung. Liegt bereits eine Ablehnung vor, hilft der Leitfaden zur Behebung von Store-Ablehnungen bei der Ursachenanalyse.

So sieht ein ausgefüllter Freigabenachweis aus

Notieren Sie für eine fiktive Buchungs-App die Build-Nummer, den Paketnamen und das Prüfdatum. Ein konkreter Befund könnte lauten: „Kontolöschung ist in den Einstellungen erreichbar, der öffentliche Löschlink führt jedoch zur Anmeldung.“ Ordnen Sie den Punkt dem Website-Verantwortlichen zu. Er bleibt offen, bis die erforderlichen Informationen ohne Konto zugänglich sind. Ein Häkchen bei „Datenschutz erledigt“ würde diesen Unterschied verdecken.

Prüfen Sie den Reviewer-Zugang genauso konkret. Halten Sie fest, dass eine frische Installation mit dem Demokonto einen kostenpflichtigen Testkurs erreicht, ohne Einmalcode oder echte Belastung. Macht eine Serveränderung dieses Konto unbrauchbar, gilt der bisherige Nachweis nicht mehr. Wiederholen Sie den betroffenen Test und dokumentieren Sie das Ergebnis.

Eine vollständige Liste unterstützt die Entscheidung zur Einreichung, garantiert aber keine Store-Freigabe. Bewahren Sie Build-Kennung und offene Punkte gemeinsam auf. Klären Sie im Projektgespräch mit Appfyl auch, wer diese Nachweise führt und nach Änderungen aktualisiert.

Häufige Fragen