Android-Entwicklerverifizierung 2026: Fristen und Schritte

Fast alles, was 2025 über die Android-Entwicklerverifizierung geschrieben wurde, ist heute in mindestens einem wichtigen Punkt falsch, und ein überraschend großer Teil des Anfang 2026 Geschriebenen ebenfalls. Der Zuschnitt des Programms änderte sich nach der ersten Ankündigung, das genaue Datum der Durchsetzung stand erst im Juni 2026 fest, und der Geltungsbereich wurde am 22. Juli 2026 schriftlich enger gefasst. Die Frage, die Entwickler tatsächlich in die Suche tippen, lautet dabei nicht "was ist die Entwicklerverifizierung?" Sie lautet: Google sagt, ich sei gescheitert, was genau stimmt nicht, was passiert jetzt, und hatte ich das nicht längst erledigt?

Dieser Beitrag ist deshalb als Störungsbehebung geschrieben und nicht als Richtlinienkommentar. Er beantwortet zuerst die Frage "bin ich schon fertig?", gibt Ihnen die exakte Navigation in der Play Console statt vager Ratschläge, trennt die zwei Durchsetzungsebenen, die jede andere Seite zu einem einzigen Schrecksatz verschmilzt, und benennt ausdrücklich die Stellen, an denen Google nichts veröffentlicht hat. Er zieht außerdem eine harte Linie zwischen der Verifizierung und der separaten Regel des geschlossenen Tests mit 12 Testern, weil diese Verwechslung fast jede Woche im Posteingang von PrimeTestLab landet. Jedes Datum und jede Zahl unten wurde am 9. August 2026 gegen Googles eigene Seiten geprüft.

Die Android-Entwicklerverifizierung sind zwei Aufgaben, nicht eine

Wenn Sie auf Google Play veröffentlichen, verlangt die Android-Entwicklerverifizierung zwei getrennte Dinge von Ihnen: Ihre Identität verifizieren und die Paketnamen Ihrer Apps registrieren. Die meisten bestehenden Play-Entwickler haben das Erste bereits erledigt, und in der überwiegenden Mehrzahl der Fälle ist das Zweite automatisch passiert. Für viele Konten bleibt nur, zwei Bildschirme zu prüfen, auch wenn Google keine allgemeingültige Bearbeitungsdauer veröffentlicht und ein Dokument- oder Kontoproblem deutlich länger dauern kann.

Was jedes Tor tatsächlich feststellt

Die zwei Aufgaben beantworten zwei verschiedene Fragen, und eine zu bestehen sagt Google nichts über die andere. Sie auseinanderzuhalten ist das Wertvollste, was diese Seite für Sie tun kann, denn Fehlerbilder, Korrekturen und sogar die Bildschirme in der Play Console sind verschieden.

Ein Konto kann also bei der Identität vollständig verifiziert sein und trotzdem einen nicht registrierten Paketnamen still in der Liste stehen haben. Genau diese Kombination geht an einem Stichtag schief, weil der Entwickler auf den Bildschirm geschaut hat, der "verifiziert" sagt, und den nie geöffnet hat, der die Apps auflistet.

Die Ein-Minuten-Antwort für bestehende Play Console-Entwickler

Wenn Sie bereits auf Google Play veröffentlichen, ist das hier der gesamte Compliance-Pfad in der Reihenfolge, in der er geprüft gehört. Die meisten Leser hören bei Schritt zwei auf.

1. 01

   Bestätigen Sie Ihren Identitätsstatus

   Öffnen Sie Entwicklerkonto in der Play Console. Googles Verifizierungsleitfaden beschreibt den Pfad als Einstellungen › Entwicklerkonto, während die neuere Dokumentation zur Kontoverwaltung Entwicklerkonto › Über Sie nennt. In beiden Fällen gibt Google an, dass Sie diesen Schritt nicht wiederholen müssen, wenn Sie die Identitätsverifizierung bereits erfolgreich abgeschlossen haben. Verifiziert

2. 02

   Bestätigen Sie, dass jedes Paket registriert ist

   Öffnen Sie die Seite Android-Entwicklerverifizierung in der Play Console und sehen Sie sich den Registrierungsstatus jeder App an. Auch die Startseite der Play Console kann Registrierungsinformationen zu Apps anzeigen. Wenn alle Ihre Paketnamen automatisch registriert wurden, gibt Google an, dass für diese Apps keine weitere Registrierung nötig ist. Verifiziert

3. 03

   Beanspruchen Sie den Rest vor dem 30. September

   Für ein Paket, das nicht automatisch registriert wurde, folgen Sie Googles manueller Registrierung. Welche Gestalt sie hat, hängt vom Paketnamen ab: ein Name, den Android noch nie gesehen hat, braucht nur die Paketdaten und Ihr öffentliches Signaturzertifikat, während ein Name mit vorhandenen Installationen ein signiertes Nachweis-APK braucht, das den Besitz des privaten Schlüssels belegt. Beide Abläufe stehen in Abschnitt 05.

Wenn Sie auf Google Play veröffentlichen, nutzen Sie die Play Console

Das ist die Falle, die Entwickler auf einen einstündigen Umweg schickt. In diesem Programm gibt es zwei Konsolen. Die Play Console ist der Ort, an dem Google Play-Entwickler beide Aufgaben erledigen. Die Android Developer Console ist eine eigene Oberfläche für Entwickler, die außerhalb von Google Play vertreiben, und ihre Hilfeseiten beschreiben einen anderen Ablauf, unter anderem die Verifizierung der Organisationswebsite über die Google Search Console. Beide Anleitungen ranken für dieselben Suchanfragen.

Vier Vertriebswege, vier Antworten. Suchen Sie Ihre Zeile, bevor Sie ein weiteres Wort von Googles Dokumentation lesen, denn die falsche Zeile kostet Sie einen Nachmittag:

Zuordnung der Wege aus Googles Play Console-Verifizierungsleitfaden und seinem Leitfaden zum eingeschränkten Vertrieb, abgerufen am 13. August 2026. Verifiziert

Der Verifizierungszeitplan 2026 und das Datum, das Artikel immer noch falsch angeben

Die Verifizierung kam nicht in einer Ankündigung. Sie kam in fünf, und jede hat die vorherige eingeengt oder korrigiert. Die Chronologie unten stützt sich auf Googles eigenes Material aus Juni und Juli 2026 als maßgebliche Quelle, was zählt, weil die viel zitierte Prognose vom März überholt wurde.

Wie das Programm tatsächlich kam, Meilenstein für Meilenstein

Jeder Eintrag stellt neben das, was Google veröffentlicht hat, das, was ein Play-Entwickler daraus mitnehmen sollte, denn mehrere dieser Daten werden anderswo isoliert zitiert und lesen sich völlig anders, sobald die Abfolge sichtbar ist.

1. November 2025

   Der Early Access öffnet

   Zum Early Access eingeladene Entwickler konnten beginnen, Apps zu verifizieren, die außerhalb von Google Play vertrieben werden.

   Was daraus folgt: nur ein historischer Meilenstein. Nichts davon begründet heute eine Pflicht für einen Play-Entwickler.

2. 30. März 2026

   Der Rollout an alle Entwickler beginnt

   Google gab bekannt, mit dem Rollout der Android-Entwicklerverifizierung an alle Entwickler zu beginnen, sowohl in der Play Console als auch in der Android Developer Console, und wies Play-Entwickler an, in den folgenden Wochen auf den Zugang zu achten. Verifiziert

   Was daraus folgt: lesen Sie das nicht als "jedes Play-Konto hat die Verifizierung am 30. März bekommen". Googles eigener Wortlaut ist, dass der Rollout an diesem Tag begann.

3. Juni 2026

   Der Systemdienst Android Developer Verifier wird ausgerollt

   Googles aktualisierter Zeitplan setzt den Rollout des Verifizierungs-Systemdienstes in den Juni 2026. Verifiziert

   Was daraus folgt: nehmen Sie Juni. Der Blogbeitrag vom 30. März hatte April prognostiziert, und mehrere aktuelle Drittartikel wiederholen diese Prognose immer noch, als wäre sie Geschichte.

4. 18. Juni 2026

   Das genaue Datum der Durchsetzung steht

   Google nannte den 30. September 2026 als ersten Stichtag, benannte die sieben teilnehmenden Stores und gab an, dass über 99% der Apps von Play-Entwicklern bereits registriert waren. Verifiziert

   Was daraus folgt: das ist die stärkste Einzelquelle sowohl für das Datum als auch für die Zahl zur automatischen Registrierung. Alles, was davor veröffentlicht wurde, rät beim Datum.

5. Juli 2026

   Werkzeuge: die ID Status API und die Console API

   Die Android Developer ID Status API wurde weltweit ausgerollt, die Console API und die eingeschränkte Verteilung liefen im Early Access.

   Was daraus folgt: relevant für Automatisierungs- und Tooling-Teams, nicht für einen Erstveröffentlicher, der sich per Hand durch die Play Console arbeitet.

6. 15. Juli 2026

   Die aktuellen Leitfäden erscheinen

   Googles allgemeiner Verifizierungsleitfaden und der Play Console-Leitfaden wurden aktualisiert, einschließlich des anfänglichen Store-Geltungsbereichs und der Anleitung zur Registrierung von Play-Paketnamen. Verifiziert

   Was daraus folgt: behandeln Sie diese beiden Seiten als die maßgebliche aktuelle Dokumentation für alles Operative.

7. 22. Juli 2026

   Die FAQ engt den Geltungsbereich schriftlich ein

   Googles FAQ stellte klar, dass Stores außerhalb der teilnehmenden Liste und das direkte Sideloading nicht unter die Phase vom 30. September fallen. Verifiziert

   Was daraus folgt: das ist der Satz, der die Erzählung von 2025 beendet, Google beende an diesem Tag das Sideloading. Es ist eine Beschränkung der ersten Phase, keine dauerhafte Ausnahme.

8. August 2026

   Für globale Verfügbarkeit geplant: eingeschränkter Vertrieb und Advanced Flow

   Googles Verifizierungsseite führt Konten für eingeschränkten Vertrieb, die Android Developer Console API und den Advanced Installation Flow als Starts im August 2026. Stand 13. August 2026 sagt der eigene Leitfaden zum eingeschränkten Vertrieb weiterhin, dass die Anmeldung zum Early Access geschlossen ist und im August 2026 mehr Informationen folgen. Diese Zeile ist deshalb als geplant und nicht als geliefert gezeichnet. Teilweise, Start nicht bestätigt

   Was daraus folgt: das ist der schnelllebigste Punkt auf dieser Seite, und dass der Kalender im August steht, ist kein Beleg dafür, dass es ausgeliefert wurde. Prüfen Sie Googles Verifizierungsseite auf den aktuellen Stand, statt einem mitten im Monat veröffentlichten Artikel zu vertrauen, auch diesem nicht.

9. 30. September 2026

   Zwei Dinge passieren am selben Tag

   Die Registrierung von Apps wird für Installationen über die sieben teilnehmenden Stores in Brasilien, Indonesien, Singapur und Thailand Pflicht. Getrennt davon müssen nach den Play Console-Anforderungen alle Play-Pakete registriert sein, und Google gibt an, dass nicht registrierte Apps von Google Play entfernt werden. Verifiziert

   Was daraus folgt: ein Datum, zwei unabhängige Folgen. Abschnitt 03 trennt sie sauber.

10. 2027 und danach

    Weltweite Ausweitung, Datum nicht genannt

    Google gibt an, dass die Schutzmaßnahmen 2027 weltweit ausgeweitet werden. Mit Stand 9. August 2026 wurden weder ein exaktes weltweites Datum noch ein weiterer Länderfahrplan genannt. Verifiziert

    Was daraus folgt: behandeln Sie jedes "1. Januar 2027" oder "Anfang 2027", das Sie anderswo lesen, als Prognose. Google hat keine veröffentlicht.

Ist der 30. September 2026 eine weltweite Frist?

Nein für die Durchsetzung auf Android-Geräteebene und ja für die Frist zur Registrierung der Google Play-Pakete. Das sind zwei verschiedene Regeln, die sich zufällig ein Datum teilen, und fast jeder Artikel über dieses Programm wirft sie zusammen. Die Geräteregel startet in vier Ländern über sieben Stores. Die Play-Regel betrifft Ihren Play-Eintrag, und Google beschreibt die Folge eines Versäumnisses als weltweite Entfernung aus Google Play.

Die vier Länder und die sieben Stores

Google benennt beide Listen präzise, es ist also keine Auslegung nötig. Die erste Durchsetzungsstufe erfasst App-Installationen in diesen vier Ländern:

Und sie gilt für Installationen über diese sieben teilnehmenden App-Stores:

Beide Listen stammen aus Googles Ankündigung vom 18. Juni 2026 und dem Verifizierungsleitfaden vom 15. Juli 2026, abgerufen am 9. August 2026. Google kann Stores oder Regionen ergänzen: prüfen Sie die Quelle nahe am Stichtag erneut, bevor Sie auf dieser Liste handeln.

Gilt der 30. September für Sie? Lösen Sie Ihren eigenen Vertriebsweg auf

Beantworten Sie zwei Fragen, und das Werkzeug unten wendet beide Ebenen auf Ihren konkreten Vertriebsweg an. Es ist bewusst deutlich bei den Fällen, in denen Googles Antwort "noch nicht" lautet, denn "noch nicht" ist nicht dasselbe wie "nie".

So prüfen Sie, ob Sie bereits verifiziert sind

Zwei Bildschirme beantworten die ganze Frage. Entwicklerkonto trägt Ihre Identität und die Kontoinformationen. Die Seite Android-Entwicklerverifizierung trägt den Registrierungsstatus jeder App. Wenn Sie nur den ersten öffnen, bestehen Sie eine Prüfung, die Sie in Wahrheit nicht bestanden haben.

Die vier Orte, an denen ein Status auftauchen kann

Vom Status zur Aktion, ohne Bezeichnungen zu erfinden

Google veröffentlicht, wo Sie nachsehen und was Sie tun sollen. Ein erschöpfendes Glossar der Play-Identitätsstatus veröffentlicht Google nicht, also erfindet dieser Beitrag keines. Die Tabelle unten ist danach geordnet, was Sie prüfen und wie "erledigt" aussieht, und genau das ist der Teil, den Google dokumentiert.

Navigation und Definitionen von "erledigt" aus der Play Console-Hilfe Antwort 16984799, Googles Play Console-Verifizierungsleitfaden und der Hilfeseite zu den Informationen des Entwicklerkontos; die Zeile zum geschlossenen Test aus der Play Console-Hilfe Antwort 14151465. Alle abgerufen am 9. August 2026. Googles eigene Seiten verwenden derzeit zwei verschiedene Formulierungen für den Identitätspfad, die Navigation der Play Console ändert sich häufig, und die Bezeichnungen stehen hier auf Deutsch, während Ihre Console leicht abweichende Begriffe zeigen kann: behandeln Sie jeden Pfad hier deshalb als zum Stichtag aktuell und nicht als dauerhaft.

Was "automatisch registriert" tatsächlich heißt

Die automatische Registrierung betrifft genau eine enge Beziehung: die Verbindung zwischen dem Paketnamen einer App und den Signaturdaten, die belegen, wer sie kontrolliert. Google gibt an, dass berechtigte Apps mit Play App Signing Teil der automatischen Registrierung sind, weil Google die nötigen Eigentums- und Signaturinformationen bereits vorliegen hat.

Wenn alle Ihre Paketnamen erfolgreich automatisch registriert wurden, gibt Google an, dass für die entsprechenden Play-Apps keine weitere Registrierung nötig ist. Dieser Satz leistet genau so viel, wie er sagt, und keinen Deut mehr.

Bei diesem letzten Punkt lohnt sich ein Innehalten. Die Registrierung läuft pro Paket, ein Konto mit sechs Apps kann also zu vier Sechsteln fertig sein und nirgends etwas Alarmierendes anzeigen außer auf der einen Seite, die sie auflistet. Google rahmt die Verifizierung außerdem als Bestätigung dessen, wer der Entwickler ist, und beschreibt sie als getrennt von der Sicherheitsprüfung der App-Inhalte: nichts hiervon sagt also etwas darüber aus, ob Ihre App den Play-Richtlinien entspricht.

Was tun, wenn eine App nicht automatisch registriert wurde

Die manuelle Registrierung hat zwei Gestalten, und welche Sie bekommen, hängt vom Paketnamen ab, nicht von Ihnen. Für einen Paketnamen, den Android noch nie gesehen hat, liefern Sie die Paketdaten und das öffentliche Zertifikat Ihres Signaturschlüssels. Für einen Paketnamen, der bereits Installationen trägt, weisen Sie zusätzlich nach, dass Sie den passenden privaten Schlüssel besitzen, indem Sie ein APK mit einem Schnipsel von Google hochladen. Nur der zweite Fall braucht ein signiertes Nachweis-APK, und keiner der beiden Fälle braucht Ihr echtes Produktions-APK.

Klären Sie zuerst, in welchem Fall Sie sind

Fünf Zeilen, und heute gehören Sie in genau eine davon. Das hier zu verwechseln ist der teuerste Fehler dieses Abschnitts, denn die Nachweis-APK-Route ist Build-Arbeit, und drei dieser Zeilen brauchen sie überhaupt nicht.

Fallunterscheidung aus der Play Console-Hilfe, "Registering Android package names" (Antwort 16761053), abgerufen am 13. August 2026. Verifiziert

A. Einen neuen Paketnamen registrieren

Der kurze Weg. Alles passiert in der Play Console, nichts kommt Ihrer Build-Umgebung nahe, und es gibt kein APK zu erzeugen.

1. 01

   Öffnen Sie die Seite Android-Entwicklerverifizierung

   Öffnen Sie in der Play Console die Seite Android-Entwicklerverifizierung und sehen Sie den Registrierungsstatus jedes Paketnamens im Konto durch. Auch die Startseite der Play Console kann Registrierungsinformationen zu Apps anzeigen.

2. 02

   Wählen Sie Paketnamen registrieren

   Damit starten Sie eine frische Registrierung statt eines Anspruchs auf einen bereits vorhandenen Namen.

3. 03

   Tragen Sie Paketnamen und Anzeigenamen ein

   Der Anzeigename ist eine interne Bezeichnung für Ihre eigene Liste. Er ist nicht das, was Nutzer in Ihrem Store-Eintrag sehen.

4. 04

   Wählen Sie Schlüssel hinzufügen

   Damit beginnt die Zuordnung zwischen einem Signaturschlüssel, den Sie kontrollieren, und dem Paketnamen, den Sie registrieren.

5. 05

   Hinterlegen Sie das öffentliche Signaturzertifikat

   Liefern Sie das öffentliche Zertifikat aus dem Signaturschlüsselpaar Ihrer App. Weil Android diesen Paketnamen noch nie gesehen hat, ist das Zertifikat alles, was Google braucht. Ihr privater Schlüssel verlässt Ihren Rechner nie.

6. 06

   Absenden und auf die Bestätigung warten

   Google sendet eine E-Mail, sobald der Paketname erfolgreich registriert ist, und der aktualisierte Status wird in der Play Console sichtbar.

B. Einen vorhandenen Paketnamen registrieren

Das ist der längere Weg, und der, den jeder Artikel so beschreibt, als wäre er der einzige. Er gilt, wenn der Paketname auf Android bereits Installationen hat, denn dann nimmt Google Ihnen Ihr Wort nicht ab: Sie müssen die Kontrolle über den privaten Schlüssel belegen. Zwei dieser Schritte passieren außerhalb der Play Console, halten Sie Ihre Build-Umgebung also vorher offen.

1. 01

   Tragen Sie die Paketdaten ein

   Starten Sie auf der Seite Android-Entwicklerverifizierung die Registrierung für den Paketnamen, den Sie beanspruchen.

2. 02

   Öffnen Sie Schlüssel auswählen

   Google bietet die Zertifikate an, die es für diesen Paketnamen als geeignet ansieht, gestützt auf Installationsbelege.

3. 03

   Wählen Sie einen geeigneten öffentlichen Zertifikat-Fingerabdruck

   Nehmen Sie den Fingerabdruck des Schlüssels, den Sie tatsächlich besitzen. Wird nichts Geeignetes angeboten, halten Sie hier an und lesen Sie die Eignungsregeln weiter unten, bevor Sie etwas anderes versuchen.

4. 04

   Starten Sie den Eigentumsnachweis und kopieren Sie Googles Schnipsel

   Google erzeugt für diesen Anspruch ein eindeutiges Schnipsel. Kopieren Sie es exakt. Dieser Wert belegt, dass das APK, das Sie gleich bauen, für genau diese Prüfung entstanden ist.

5. 05

   Legen Sie assets/adi-registration.properties an

   Erstellen Sie im assets-Ordner eines APK-Projekts eine Datei mit exakt dem Namen adi-registration.properties. Pfad und Dateiname sind beide wörtlich zu nehmen. Ein Tippfehler hier ist die häufigste Art, wie dieser Schritt scheitert.

6. 06

   Fügen Sie das Schnipsel in diese Datei ein

   Mehr muss nicht hinein. Die Datei existiert einzig, um die Zeichenkette zu tragen.

7. 07

   Bauen Sie ein Release-APK

   Google sagt, Sie können es aus der echten Anwendung oder aus einem leeren Projekt mit demselben Paketnamen bauen. Das leere Projekt ist meist schneller und sicherer, weil nichts aus Ihrem Produktionscode beteiligt ist.

8. 08

   Signieren Sie es mit dem passenden privaten Schlüssel

   Darum geht es bei der ganzen Übung. Die Signatur ist der Beweis, nicht der Inhalt.

9. 09

   Laden Sie es über die Play Console hoch

   Laden Sie das signierte Nachweis-APK im Eigentumsablauf hoch. Das ist kein Release, es erreicht keinen Nutzer, und Ihr echtes Produktionsartefakt bleibt außen vor.

10. 10

    Behalten Sie Status und Bestätigungsmail im Blick

    Google sendet eine E-Mail, sobald der Paketname erfolgreich registriert ist, und der aktualisierte Status wird in der Play Console sichtbar.

C. Wenn ein anderer App-Store Ihren Signaturschlüssel hält

Manche Stores signieren im Namen des Entwicklers, dann können Sie selbst kein korrekt signiertes Nachweis-APK erzeugen. Google dokumentiert dafür einen eigenen Weg, und der ist kurz:

1. 01

   Bauen Sie das Release und laden Sie es in diesen Store

   Schicken Sie den Build mit dem Schnipsel durch den normalen Release-Prozess der anderen Plattform.

2. 02

   Laden Sie das fertige signierte APK aus diesem Store herunter

   Sie brauchen das Artefakt so, wie der Store es signiert hat, nicht das, was Sie hochgeladen haben.

3. 03

   Laden Sie dieses vom Store signierte APK in die Play Console

   Die Signatur des Stores erfüllt die Eigentumsprüfung.

Ablaufschritte aus der Play Console-Hilfe, "Registering Android package names" (Antwort 16761053), abgerufen am 13. August 2026. Verifiziert

Weitere Schlüssel später hinzufügen

Ein Paketname kann mehr als einen Signaturschlüssel haben. Google sagt, die Konsole erlaubt es, mehrere Signaturschlüssel für ein einzelnes Paket hinzuzufügen und zu verifizieren, und das Verfahren spiegelt Weg B: assets/adi-registration.properties mit dem Schnipsel für diesen Schlüssel anlegen, ein Release-APK bauen und mit dem passenden privaten Schlüssel signieren, dann hochladen. Erst den Paketnamen registrieren, dann die weiteren Schlüssel ergänzen.

Wenn kein geeigneter Schlüssel angeboten wird: die Vorrangregeln

Die meisten Entwickler sehen das nie. Es zählt, wenn ein Paketname im Lauf seines Lebens von mehr als einem Schlüssel signiert wurde oder wenn mehr als eine Partei einen plausiblen Anspruch darauf hat. Google löst das über eine Rangfolge nach Installationen.

Rangfolge der Eignung aus der Play Console-Hilfe Antwort 16761053, abgerufen am 13. August 2026. Verifiziert

Praktisch gelesen, und zwar sorgfältig: Wenn Ihr Signaturschlüssel die Rangfolge oben klar erfüllt, sollte er als direkt geeignet für den Anspruch erscheinen. Das entscheidet, ob Google Sie direkt registrieren lässt statt über einen geprüften Antrag. Die Registrierung erledigt es nicht für Sie. Ein Paket, das bei der automatischen Registrierung übersprungen wurde, muss trotzdem von Hand durch Weg B. Die Stufe "wer zuerst kommt, mahlt zuerst" ist die, bei der Sie zügig handeln sollten, denn sie entscheidet sich danach, wer handelt, nicht danach, wer im Recht ist.

Was private Entwicklerkonten einreichen müssen

Zwei Ebenen: allgemeingültige Angaben und länderspezifische Dokumente. Allgemeingültig ist, dass Ihre rechtlichen Identitäts- und Adressdaten exakt mit dem verknüpften Google-Zahlungsprofil übereinstimmen müssen. Der Dokumententeil hängt vollständig vom Land oder der Region in diesem Profil ab, und deshalb kann kein ehrlicher Artikel Ihnen eine einzige weltweite Checkliste in die Hand drücken.

Der Teil, der überall gleich ist

Private Konten liefern rechtliche Identitäts- und Kontoinformationen, und die aktuelle Play-Hilfe nennt darunter den rechtlichen Namen und die rechtliche Adresse. Der Verifizierungsprozess nutzt das verknüpfte Google-Zahlungsprofil, und Googles Seite zu den Dokumentanforderungen stellt fest, dass die persönlichen Identitätsangaben, gegebenenfalls der Organisationsname und die Adressdaten exakt mit den Angaben in Ihrem Zahlungsprofil übereinstimmen müssen.

Das Wort "exakt" trägt diesen ganzen Abschnitt, und es ist der Grund, warum es das nächste Werkzeug gibt.

Der Teil, der nicht überall gleich ist

Googles eigene Seite sagt, dass die akzeptierten Dokumente von Ihrem geografischen Standort abhängen. Die Länderauswahl auf dieser Seite ist für Ihren Fall maßgeblich, nicht irgendeine anderswo abgeschriebene Liste. Um die Form der Anforderung greifbar zu machen, ohne sie als allgemeingültig auszugeben, hier das, was Googles US-Seite derzeit von Privatpersonen verlangt:

Die Bildanforderungen, die Google ausdrücklich nennt

Sie gelten für den Lichtbildausweis selbst und sind eindeutig, was sie zu den billigsten Fehlerquellen macht, die Sie vor jedem Upload beseitigen können:

• Der amtliche Lichtbildausweis muss gültig und nicht abgelaufen sein.
• Das Bild muss in Farbe sein.
• Das Bild muss scharf und gut ausgeleuchtet sein.
• Das Bild darf keine Fotokopie sein.

Google stellt außerdem fest, dass seine aktuelle Seite zu den Dokumentanforderungen nicht unterstützte Dokumente als Hauptgrund für gescheiterte Entwicklerverifizierungen benennt und dass gefälschte oder veränderte Dokumente zu harten Maßnahmen bis hin zur Entfernung von Konto und Apps führen können. Nichts auf dieser Seite ist es wert, das zu riskieren.

Die Prüfung, bevor Sie irgendetwas hochladen

Google veröffentlicht nicht, wie viele Verifizierungsversuche Sie haben, und Entwickler berichten regelmäßig, einen Zustand zu erreichen, in dem die Schaltfläche für einen neuen Versuch schlicht nicht mehr sichtbar ist. Diese Kombination macht eine unbedachte Einreichung wirklich teuer. Machen Sie zuerst diese Prüfung.

Der Fehler, den Sie vor jedem Upload prüfen sollten

Wenn Sie aus diesem Beitrag nur eine Anweisung mitnehmen, dann diese: öffnen Sie Ihr Google-Zahlungsprofil und vergleichen Sie den rechtlichen Namen und die Adresse Feld für Feld mit Ihren Dokumenten, bevor Sie die Upload-Schaltfläche anfassen. Google verlangt, dass die Angaben übereinstimmen; eine Regel auf Zeichen- oder Interpunktionsebene veröffentlicht Google nicht, behandeln Sie "Feld für Feld" also als praktischen Weg, die Anforderung zu erfüllen, und nicht als eigene Regel.

Die erste Hälfte davon ist Googles eigene Anforderung. Die zweite Hälfte ist das, wovon die Support-Foren 2026 voll sind. Threads aus April, Juni, Juli und August 2026 haben alle dieselbe Form: ein Entwickler ist sicher, dass die Dokumente korrekt sind, die Verifizierung scheitert ohne konkreten Grund, und die Antwort der Community verweist zurück auf eine Abweichung zwischen der eingereichten Identität und dem Zahlungsprofil. In mehreren dieser Threads entdeckte der Entwickler das Namensproblem im Profil erst nach einem erfolglosen Einspruch.

Was Organisationskonten brauchen

Organisationen verifizieren sich über rechtliche Unternehmensangaben statt über eine persönliche Identität und brauchen in der Regel eine D-U-N-S-Nummer: eine eindeutige neunstellige Kennung, ausgegeben von Dun and Bradstreet. Googles Play-Dokumentation nennt Ausnahmen für bestimmte staatliche Einrichtungen. Google gibt an, dass Entwickler ohne Nummer sie kostenlos erhalten können, warnt aber, dass es Wochen dauern kann, womit dies der einzige Punkt auf dieser Seite mit echter Vorlaufzeit ist. Googles eigene Seiten widersprechen sich bei der Dauer: die FAQ zur Android-Verifizierung nennt bis zu 28 Tage, die aktuelle Play Console-Kontohilfe bis zu 30. Dieser Beitrag plant mit 30.

Was eine Organisation sonst noch vorbereitet

• Rechtliche Angaben zur Organisation, die zu Ihren Registerdaten passen, plus die vertretungsberechtigte Person und die Kontoinformationen.
• Die neunstellige D-U-N-S-Nummer, kostenlos bei Dun and Bradstreet erhältlich und den von Google genannten Ausnahmen für bestimmte staatliche Organisationen unterworfen. Diese Ausnahmen sind eng: sie bedeuten nicht, dass staatliche Organisationen die Verifizierung überspringen.
• Passende Unterlagen der Organisation und Identitätsdokumente der vertretungsberechtigten Person, nach denselben länderspezifischen Regeln und derselben Anforderung exakter Übereinstimmung wie bei privaten Konten.
• Eine verifizierte Website, wenn Sie als Organisation den vollen Vertrieb außerhalb von Google Play betreiben. Googles Verifizierungsleitfaden sagt, dass Organisationen eine Website angeben, die über die Google Search Console verifiziert werden muss. Dieser Schritt gehört zum Weg über die Android Developer Console, nicht zur Play Console.

Eines ändert ein Organisationskonto nicht: wenn Sie auch auf Google Play veröffentlichen, bleibt das Arbeit in der Play Console. Und wenn Sie für ein neues Konto zwischen privat und Organisation abwägen, reichen die Abwägungen weit über die Verifizierung hinaus, eine Entscheidung, die der Vergleich zwischen privatem Konto und Organisationskonto sauber durchspielt.

Was tatsächlich passiert, wenn Sie am 30. September nicht verifiziert sind

Vier verschiedene Dinge, je nachdem, wie Ihre App ihre Nutzer erreicht. Google dokumentiert Einschränkungen bei der Neuinstallation, bei Aktualisierungen dort, wo die Kontrollen greifen, und die Entfernung aus Google Play für nicht registrierte Play-Pakete. Nicht dokumentiert ist ein erzwungenes Deinstallieren von Apps, die bereits auf Telefonen liegen.

Folgen aus der Play Console-Hilfe Antwort 16984799, Googles Play Console-Verifizierungsleitfaden, dem Rollout-Beitrag vom 30. März, dem Zeitplan in der Hilfe der Android Developer Console und der FAQ vom 22. Juli. Alle abgerufen am 9. August 2026.

Die Aussage, mit der man am vorsichtigsten sein sollte

Diese Unterscheidung ist keine Wortklauberei. Sie ändert, was Sie diesen Monat tun sollten. Eine Entfernung aus Play ist ein Vertriebsnotfall, den Sie durch die Registrierung eines Pakets beheben. Ein hypothetisches Massen-Deinstallieren wäre ein Notfall in der Kundenbeziehung, der eine völlig andere Kommunikation verlangt. Nur eines von beidem ist dokumentiert.

Wie der Advanced Flow tatsächlich abläuft

Google dokumentiert den Advanced Flow als bewusst langsamen Weg statt als Schalter, und die Reibung ist der Zweck: jeder Schritt existiert, damit niemand jemanden am Telefon hindurchlotsen kann, während das Gespräch noch läuft.

1. 01

   Entwicklermodus in den Systemeinstellungen aktivieren

   Ein bewusster erster Schritt, damit hier nichts versehentlich oder durch eine Ein-Tipp-Umgehung wie bei Betrugsmaschen ausgelöst wird.

2. 02

   Bestätigen, dass Sie nicht angeleitet werden

   Eine kurze Prüfung, dass niemand Sie dazu drängt, einen Schutz abzuschalten.

3. 03

   Telefon neu starten und erneut authentifizieren

   Das kappt Fernzugriff oder ein laufendes Gespräch, über das jemand mitverfolgen könnte, was Sie als Nächstes tun.

4. 04

   Nach der Schutzwartezeit zurückkommen

   Google beschreibt sie als einmalige Wartezeit von einem Tag. Danach bestätigen Sie mit biometrischer Authentifizierung oder der Geräte-PIN.

5. 05

   Von nicht verifizierten Entwicklern installieren

   Sie können es für sieben Tage oder unbefristet erlauben. Eine Warnung erscheint weiterhin bei jeder Installation, und Sie bestätigen sie selbst.

Schritte des Advanced Flow aus Googles FAQ zur Android-Entwicklerverifizierung, abgerufen am 13. August 2026. Verifiziert

Die Sideloading-Frage, in einem Absatz

Die Phase vom 30. September gilt noch nicht für das direkte Sideloading und nicht für App-Stores außerhalb von Googles teilnehmender Liste, und Google unterstützt weiterhin die Installation per ADB sowie einen erweiterten Ablauf für Nutzer, die bewusst von nicht verifizierten Entwicklern installieren wollen. Das ist die aktuelle, dokumentierte Lage mit Stand 9. August 2026, und sie unterscheidet sich deutlich von der Erzählung "Google beendet das Sideloading", die nach der ursprünglichen Ankündigung von 2025 kursierte. Es ist zugleich ausdrücklich eine erste Phase, das als endgültiges Ergebnis zu lesen wäre also der spiegelbildliche Fehler. Wenn Sie die Folgen für Sideloading und ein offenes Ökosystem hierher geführt haben und nicht eine Play-Frist, verdient das eine eigene Behandlung und keinen Absatz mitten in einem Compliance-Beitrag.

Die Verifizierung ersetzt nicht den geschlossenen Test mit 12 Testern

Das sind zwei voneinander unabhängige Anforderungen, die beide erfüllt sein müssen, wenn beide für Sie gelten. Die Android-Entwicklerverifizierung beantwortet "wem gehören dieses Konto und dieses Paket?" Die Regel für den Produktionszugriff beantwortet "wurde diese App von echten Menschen getestet?" Sie können die eine perfekt bestehen und von der anderen vollständig blockiert bleiben.

Googles Anforderung für infrage kommende neue private Entwicklerkonten wird durch nichts im Verifizierungsprogramm verändert: mindestens 12 Tester, die zum Zeitpunkt Ihres Antrags auf Produktionszugriff über die letzten 14 Tage fortlaufend für einen geschlossenen Test angemeldet waren.

Verifizierungsspalten aus Googles Verifizierungsleitfaden und der Play Console-Hilfe Antwort 16984799; Spalten zum geschlossenen Test aus der Play Console-Hilfe Antwort 14151465 und der Hilfeseite zum internen Test. Alle abgerufen am 9. August 2026. Verifiziert

Warum das Leute erwischt

Weil beides "Anforderungen" heißt, beides in der Play Console lebt und beides zwischen einem Entwickler und einer veröffentlichten App steht. Ein Konto, das gerade die Identitätsverifizierung geschafft hat, fühlt sich deshalb fertig an. Dann wird der Produktionszugriff verweigert, und nichts in den Verifizierungsbildschirmen erklärt warum, weil diese Antwort dort nicht wohnt.

Die Abfolge, die ein neues privates Konto tatsächlich live bringt, lautet: Identität verifiziert, jedes Paket registriert, und getrennt davon ein geschlossener Test mit mindestens 12 Testern, die vor dem Antrag auf Produktionszugriff 14 Tage fortlaufend angemeldet waren. Die Regel der 14 aufeinanderfolgenden Tage hat mehr Sonderfälle, als die meisten Entwickler erwarten, und sie ist der Teil dieser Abfolge, der sich durch härteres Arbeiten nicht verkürzen lässt.

Zählt ein interner Test stattdessen?

Nein, und es lohnt sich, beim Warum präzise zu sein, denn "der interne Test ist nutzlos" ist ebenfalls falsch. Google erlaubt den internen Test mit bis zu 100 Testern, und er ist ein wirklich guter Weg, Probleme schnell zu finden. Aber die Anforderung für den Produktionszugriff nennt ausdrücklich einen geschlossenen Test, der die Bedingung von 12 Testern über 14 Tage erfüllt. Der interne Test ist ein eigener Track, die Teilnahme dort ist also nicht der qualifizierende Test für genau diese Anforderung.

Auch Organisationskonten sind hier einen klärenden Satz wert: die Testanforderung für den Produktionszugriff ist ausdrücklich für neue private Entwicklerkonten geschrieben, Organisationskonten sind also nicht die Kontoklasse, die unter genau diese 12-Tester-Regel fällt. Das ist eine andere Frage als die Verifizierung, die beide Kontotypen erreicht.

Wenn die Verifizierung gescheitert ist, prüfen Sie das, bevor Sie es erneut versuchen

Entwickler berichten häufig von unspezifischen Ablehnungsmeldungen, und Google dokumentiert die Ursache nicht für jede einzelne Ablehnung. Der sinnvolle Schritt ist also nicht, die Meldung zu erraten, sondern die Anforderungen durchzugehen, die Google tatsächlich veröffentlicht. Wählen Sie unten das Symptom, das Sie sehen. Jedes führt zum ersten Prüfpunkt, zur Stärke der Belege hinter diesem Rat und zur sicheren nächsten Handlung.

Beginnen Sie mit dem Symptom, das Sie tatsächlich sehen

Die zehn Einträge unten sind so formuliert, wie Entwickler es in Googles Support-Foren formulieren, einschließlich der um zwei Uhr nachts geschriebenen. Einen auszuwählen liefert Ihnen den wertvollsten Prüfpunkt für dieses Symptom statt einer Liste von allem, was theoretisch falsch sein könnte.

Was die Belege stützen und was nicht

Die Fehlermuster unten stammen aus Threads der Google Play Developer Help Community über das Jahr 2026, darunter Fälle aus Brasilien, Indien, Usbekistan und mehrere portugiesischsprachige Threads, dazu ältere Berichte von Reddit und Stack Overflow. Sie sind danach gruppiert, wie stark die Belege tatsächlich sind, denn das ändert, was Sie damit tun sollten.

Die Checkliste vor der Frist

Fünf Zustände entscheiden, ob der 30. September ein Datum in Ihrem Kalender ist oder ein Problem in Ihrem Posteingang. Vier gelten für jeden Play-Entwickler. Der fünfte gilt nur, wenn Ihr Konto unter die Regel des geschlossenen Tests fällt, und er ist der, der echte Kalenderzeit verbraucht.

Die vier Punkte, die Sie klären

Haken Sie ehrlich ab und nicht optimistisch. Jede Zeile verlinkt zurück auf den Abschnitt, der sie auflöst, ein leeres Kästchen ist also ein Zwei-Minuten-Umweg und keine Sackgasse. Zwei davon sind bedingt und deshalb so formuliert, dass Sie sie abhaken können, wenn sie nie auf Sie zutrafen: Wer alle Apps automatisch registriert bekommen hat, hat keinen manuellen Anspruch abzuschließen, und wer bereits verifiziert ist und nie eine Dokumentanfrage hatte, hat nichts zu korrigieren.

Wo PrimeTestLab hilft und wo nicht

Zuerst die Grenze, deutlich gesagt: niemand kann Ihre Identität für Sie verifizieren. Ihre Dokumente hochzuladen, Ihr Zahlungsprofil abzugleichen und Ihre Paketnamen zu beanspruchen kann nur der Kontoinhaber, und dieser Beitrag ist unser gesamter Beitrag dazu. Was wir abdecken, ist die Anforderung, die für ein neues privates Konto unmittelbar nach der Verifizierung kommt: die 12 echten Tester, 14 Tage am Stück angemeldet.

Das ist die Trennlinie, die immer in derselben Form in unserem Posteingang landet. Ein Entwickler besteht die Identitätsverifizierung, sieht einen grünen Zustand in der Play Console, hält den Weg für frei und stellt dann fest, dass der Produktionszugriff ein völlig eigenes Tor mit einem Zwei-Wochen-Boden ist. Die Verifizierung ist Papierkram, und wie lange sie dauert, hängt von Ihren Dokumenten und Ihrem Konto ab. Der geschlossene Test ist Kalenderzeit, die Sie nicht komprimieren können.

Den geschlossenen Test selbst fahren oder abgeben

Die Reihenfolge, die am wenigsten Zeit kostet

Wenn Verifizierung und geschlossener Test beide vor Ihnen liegen, fahren Sie sie parallel statt nacheinander. Die 14 Tage fortlaufender Anmeldung sind reale Zeit, die erst startet, wenn tatsächlich 12 Personen eingetragen sind, das ist also der Punkt, der Ihren echten Starttermin bestimmt. Starten Sie diese Uhr, während Sie sich durch die Dokumente arbeiten, nicht danach.

Häufige Fragen

Fazit

Letzter Richtlinien-Check: 13. August 2026. Googles Rollout zum 30. September und die Ausweitung 2027 entwickeln sich weiter, Daten und Länderabdeckung sollten deshalb vor jeder Handlung erneut gegen Googles Seite zur Android-Entwicklerverifizierung geprüft werden. Dieser Beitrag ist für eine erneute Prüfung am 30. September 2026 und unmittelbar nach dem Beginn der Durchsetzung vorgesehen sowie jedes Mal, wenn Google eine Geografie oder ein Datum für 2027 veröffentlicht.