Google-Play-Anforderungen 2026: So veröffentlichst du deine App

Die Google-Play-Anforderungen ganz einfach erklärt

Du hast deine App fertig, drückst auf „Veröffentlichen“ - und im Kopf läuft schon der Film, wie sie jetzt elegant in den Store fliegt. Stattdessen knallst du gegen eine Wand aus Regeln. Kommt dir bekannt vor? Na klar.

Sieh es so. Google Play ist ein Flughafen mit Passkontrolle. Deine App ist der Passagier. Um an Bord zu kommen, muss sie mehrere Schalter passieren: aktuellen Pass vorzeigen, die Zollerklärung ehrlich ausfüllen, nichts Verbotenes im Koffer schmuggeln, durch die Kontrolle gehen. Versemmelt sie auch nur einen Schalter, wird sie direkt an der Gangway umgedreht.

Es sind genau vier Schalter: ein aktuelles Target-API-Level Target-API-Level (Ziel-API-Level) - eine Zahl in den App-Einstellungen, die angibt, für welche Android-Version du beim Bauen ausgerichtet hast. Je höher die Zahl, desto neuer das Android. Google zwingt dich, sie aktuell zu halten, damit Apps nach den neuen Sicherheitsregeln spielen. , das Data-safety-Formular, das Fehlen verbotener Inhalte und ein bestandener Test. Gehen wir jeden einzeln durch.

Warum du als Entwickler die Store-Anforderungen kennen musst

Klar, du kannst deine App auch „wie sie ist“ hochladen und auf Glück hoffen. Nur prüft Google alles - automatisch und von Hand durch Moderatoren. Die Ablehnung kommt nicht sofort, sondern nach Tagen des Wartens. Und die erneute Prüfung schickt dich wieder ans Ende der Schlange. Macht so mittel Spaß.

• Du verstehst, warum deine App abgelehnt wurde, und musst nicht mehr im Kaffeesatz lesen.
• Du fängst dir keine Kontosperre ein für etwas, das du am Start hättest einplanen können.
• Du füllst das Data-safety-Formular einmal und richtig aus statt siebenmal mit Korrekturen.
• Du sparst Wochen. Die Prüfungen laufen der Reihe nach, und jede Ablehnung wirft dich zurück.

Die meisten Ablehnungen bei Neulingen sind kein „schlechter Code“. Es ist eine verpasste Target-API-Deadline, ein schiefes Datenformular oder ein vergessener Test. Und das alles ist vorher sichtbar.

Die vier Prüfungen von Google Play der Reihe nach

1. Target-API-Level - zeig den aktuellen Pass

Google will nicht, dass im Store Apps ihr Dasein fristen, die nach alten Sicherheitsregeln gebaut wurden. Deshalb kriecht die Target-API-Latte jedes Jahr nach oben: neue Apps und Updates müssen auf eine aktuelle Android-Version zielen, meist die vom Vorjahr.

In der Praxis heißt das Folgendes. Etwa ab Spätsommer lässt der Store nur noch durch, was auf das aktuelle API-Level zielt. Für Wear OS, Android TV und Auto-Systeme liegt die Latte meist eine Stufe tiefer.

targetSdkVersion targetSdkVersion - eine Zeile in den Android-Build-Einstellungen (Datei build.gradle), in der genau diese Target-API-Level-Zahl steht. Genau die prüft Google beim Hochladen. Hochziehen ist meist nicht schwer, aber manchmal muss man reparieren, was wegen neuer Regeln kaputtgegangen ist. ziehst du in den Build-Einstellungen hoch. Und hier lauert die Falle nicht in der Zahl selbst. Die neue Android-Version könnte die Spielregeln geändert haben: irgendwelche Berechtigungen wurden verschärft, irgendein gewohnter Weg, etwas zu erledigen, funktioniert plötzlich nicht mehr. Also lass nach dem Hochziehen unbedingt die App laufen und prüf - ist nichts abgefallen?

2. Data-safety-Formular - die ehrliche Erklärung am Zoll

Data safety Data safety - ein Bereich auf der App-Seite, in dem der Entwickler ehrlich aufzählt, welche Daten die App sammelt, wozu, ob sie sie an jemanden weitergibt und wie sie sie schützt. Der Nutzer sieht das im Store schon vor der Installation. ist ein Formular, in dem du selbst erzählst, was deine App mit den Nutzerdaten anstellt. Name, E-Mail, Standort, die Werbe-ID des Geräts - all das musst du deklarieren.

Und genau hier fliegen Neulinge am häufigsten auf die Nase. Es zählen auch die Daten, die fremde Bibliotheken und SDKs in deiner App sammeln. Werbung oder Analytics eingebaut - fertig, dann sammelst du auch Daten. Selbst wenn du sie mit keinem Finger angefasst hast.

3. Verbotene Inhalte - was du nicht im Koffer mitnehmen darfst

Es gibt Themen, für die sofort und ohne Diskussion gelöscht wird. Das ist kein „wir stufen dich im Ranking runter“. Das ist „wir nehmen die App raus und machen vielleicht gleich noch dein Konto dicht“.

• Kindersicherheit - absolute Priorität und null Toleranz. Jeder Inhalt, der Kinder ausbeutet, führt zur sofortigen Löschung.
• Täuschung und Betrug - gefälschte Dienste, betrügerische Schemata, Apps, die in die Irre führen.
• Deepfakes und Fälschungen - sexuelle Deepfakes ohne Einwilligung, gefälschte Aufnahmen echter Menschen für Betrug.
• KI-generierte Inhalte spielen nach denselben Regeln wie ganz normale. Generiert deine App Bilder oder Texte - muss sie Verbotenes blockieren.
• Sensible Berechtigungen - Zugriff auf Kontakte, Fotos, Standort muss begründet sein. Kredit- und Mikrokredit-Apps zum Beispiel ist der Zugriff auf Fotos und Kontakte ausdrücklich verboten.

4. Tests - die Kontrolle vor dem Abflug

Ein neues privates Entwicklerkonto angelegt? Dann lässt Google dich nicht gleich in die Produktion. Erst fährst du einen geschlossenen Test mit echten Menschen.

„Am Stück“ heißt ununterbrochen. Kommt jemand rein, bleibt drei Tage, geht wieder - zählt nicht. Selbst wenn er später zurückkommt. Also sammelst du Leute, die wirklich bereit sind, die App zwei Wochen installiert zu lassen.

So veröffentlichst du eine App in Google Play: Schritt für Schritt

Hier ist die realistische Reihenfolge, wenn du zum ersten Mal veröffentlichst.

Zieh das Target-API-Level in den Build-Einstellungen auf das aktuelle Level hoch. Lass die App laufen und vergewissere dich, dass nach dem Hochziehen nichts kaputtgegangen ist.
Erstelle eine Liste mit ALLEN Bibliotheken und SDKs im Projekt. Prüfe, welche davon Nutzerdaten sammeln - das ist auch deine Verantwortung.
Fülle das Data-safety-Formular ehrlich aus: was du sammelst, wozu, an wen du weitergibst, wie du schützt. Gleiche das Formular mit dem echten Verhalten der App ab.
Bereite eine Datenschutzerklärung vor und gib einen funktionierenden Link darauf an - ohne sie wird die App-Seite nicht angenommen.
Lies die Developer Program Policy zum Thema verbotene Inhalte erneut. Vergewissere dich, dass dein Thema und deine Berechtigungen im Rahmen sind.
Konto neu und privat? Starte einen geschlossenen Test, sammle echte Tester und halte den Test zwei Wochen am Stück.
Und erst danach beantragst du den Zugang zur Produktion und veröffentlichst. Und vor der Einreichung selbst öffnest du noch einmal die offizielle Play-Console-Hilfe - Zahlen und Deadlines könnten sich aktualisiert haben.

Häufige Fehler bei der Veröffentlichung in Google Play

• Die Target-API-Deadline verschlafen. Die Latte springt jedes Jahr. Nach Vorjahresregeln gebaut und zu spät dran - das Update wird abgewiesen. Gleiche das mit der Hilfe ab.
• Data safety für eine Formalität halten. Das ist eine abgleichbare Erklärung. Weicht sie von der Realität ab - erst Ablehnung, dann Sperre.
• Fremde SDKs vergessen. Werbung und Analytics sammeln Daten für dich. Im Formular haftest du dafür.
• „Aus Unwissenheit“ in verbotene Inhalte rutschen. Unwissenheit schützt nicht vor dem Bann. Lies die Developer Program Policy vor der Einreichung erneut.
• Denken, Berechtigungen „schaden ja nicht“. Bittest du ohne klaren Bedarf um Zugriff auf Kontakte oder Fotos - kriegst du eine Ablehnung. Nimm das Minimum.
• Den Test bei einem neuen Konto ignorieren. Ohne geschlossenen Test mit echten Menschen kommst du schlicht nicht in die Produktion. Plan die zwei Wochen vorab ein.
• Zahlen aus alten Artikeln glauben. Tester-Anzahl, API-Level und Deadlines ändern sich. Die einzige Quelle der Wahrheit ist die offizielle Play-Console-Hilfe.