Kurzantwort
Stand 13. August 2026 können Tester ein rohes APK, das Sie direkt mit ihnen teilen, weiterhin installieren. Die Durchsetzung durch Google ab dem 30. September 2026 in Brasilien, Indonesien, Singapur und Thailand gilt zunächst nur für sieben teilnehmende App-Stores, und die FAQ von Google vom 15. Juli sagt, dass Direktinstallationen noch nicht erfasst sind. Google plant für 2027 eine weitergehende Durchsetzung auf zertifizierten Geräten ab Android 7, ohne ein genaues Datum anzukündigen. Sobald das gilt, behalten Apps, die bei einem verifizierten Entwickler registriert sind, den gewohnten Installationsweg, während nicht registrierte Apps weiterhin über ADB oder über den erweiterten Ablauf von Google installiert werden können. Firebase App Distribution bleibt für die QA nützlich, führt aber keine Android-Entwicklerverifizierung durch und zählt nicht als der geschlossene Test bei Google Play, der 12 über 14 aufeinanderfolgende Tage angemeldete Tester verlangt.
Wie dieser Artikel jede Aussage bewertet
- Verifiziert heißt, die Aussage stammt direkt von einer aktuellen Seite von Google, Android oder Firebase. Der größte Teil dieses Artikels ist verifiziert. Verifiziert
- Teilweise heißt, die Primärquellen stützen die Schlussfolgerung, aber es braucht einen Schluss dazwischen, oder die Seiten von Google lassen den Sonderfall offen. Teilweise
- Aus der Community heißt, wiederholte Berichte von Entwicklern aus Stack Overflow, Reddit oder den Foren von Google. Nützlich für die Fehlersuche, nicht für Richtlinien. Community
- Nicht dokumentiert heißt, Google hat zu genau diesem Fall nichts veröffentlicht, und wir sagen das, statt zu raten. Nicht dokumentiert
Die Geschichte, die sich 2025 verbreitet hat, war einfach: Android beendet die Direktinstallation. Die Position, die Google im August 2026 tatsächlich dokumentiert, ist enger, genauer und als Schlagzeile deutlich weniger brauchbar. Google hat den Umfang der ersten Durchsetzungsphase im Juni und Juli 2026 präzisiert und diese Eingrenzung am 15. Juli 2026 in einem einzigen Satz festgehalten: die Frist zum 30. September "gilt nur für die konkreten teilnehmenden Stores". Ein großer Teil der weiterhin kursierenden Berichterstattung aus 2025 und dem frühen Jahr 2026 entstand, bevor dieser Satz existierte, und beschreibt einen breiteren ersten Rollout als den, den Google tatsächlich durchführt.
Deshalb ist dieser Artikel um die Entscheidung herum aufgebaut, die Sie wirklich treffen müssen, und nicht um die Aufregung. Sie haben zwölf Freunde, Kollegen oder Tester und einen Build, der auf deren Telefone soll. Können Sie das APK noch per E-Mail schicken? Brauchen Sie ADB? Funktioniert Firebase App Distribution? Und die Frage, die fast jede Woche im Postfach von PrimeTestLab landet: zählt irgendetwas davon für den geschlossenen Test mit 12 Testern, den Google vor dem Produktionszugriff verlangt? Jedes Datum, jede Zahl und jeder Mechanismus weiter unten wurde am 13. August 2026 gegen die Seiten von Google geprüft, und wo Google nichts veröffentlicht hat, benennt dieser Artikel die Lücke, statt sie zu füllen.
Können Ihre Tester Ihr APK nach dem 30. September 2026 noch installieren?
Ja. Nach den aktuellen Regeln von Google kann ein Tester ein APK, das Sie ihm direkt schicken, auch nach dem 30. September 2026 installieren. Das Datum ist real, die vier Länder sind real und die Durchsetzung ist real, aber die aktuelle FAQ von Google sagt, die Frist "gilt nur für die konkreten teilnehmenden Stores". Für eine Direktinstallation sagt dieselbe FAQ, sie "gilt für Ihre App noch nicht".
Der genaue Wortlaut von Google, Fragment für Fragment
Die Frist "gilt nur für die konkreten teilnehmenden Stores" · für eine Direktinstallation "gilt sie für Ihre App noch nicht" · die Durchsetzung erfasst "zertifizierte Android-Geräte ab Android 7" · Google wird "die Android-Verifizierungsanforderung weltweit ausweiten" im Jahr 2027
Fragmente einzeln zitiert aus der FAQ von Google zur Android-Entwicklerverifizierung (aktualisiert am 10. August 2026) und der Ankündigung vom 18. Juni 2026, beide abgerufen am 13. August 2026. Die Quellseiten sind englisch: die deutsche Formulierung oben ist unsere Übersetzung. Verifiziert
Was der 30. September berührt und was nicht
Drei Zeilen klären die Frage für fast alle Leser. Die mittlere Zeile ist die, die von vielen älteren Beiträgen zu diesem Datum abweicht.
Am 30. September 2026 betroffen
Die Installation über einen der sieben teilnehmenden Stores in Brasilien, Indonesien, Singapur oder ThailandDie App muss bei einem verifizierten Entwickler registriert sein, damit die gewöhnliche Installation durchgeht. Google gibt an, dass der Teil dieser anfänglichen regionalen Durchsetzung außerhalb von Play für die Formfaktoren Smartphone und Tablet gilt.
Von der ersten Phase noch nicht erfasst
Ein direktes APK: per E-Mail, von Ihrer Website geladen, über Drive geteilt oder über ADB installiertDie FAQ von Google vom 15. Juli sagt, dass die Frist zum 30. September für die Direktinstallation noch nicht gilt. App-Stores außerhalb der Liste der Teilnehmer liegen ebenfalls außerhalb dieser ersten Phase. Das Wort, das in beiden Sätzen die Arbeit macht, ist noch. Ein APK aus Firebase App Distribution sollte dieselbe Antwort erben, denn es ist Direktverteilung eines signierten APK, aber Google hat keine Firebase-spezifische Festlegung veröffentlicht. Teilweise, Schluss
So oder so unverändert
Die eigenen Veröffentlichungsregeln von Google PlayPlay verlangt gesondert, dass jedes Play-Paket registriert ist, und der geschlossene Test mit 12 Testern für betroffene neue private Konten bleibt davon völlig unberührt. Die Verifizierung verkürzt ihn nicht, erlässt ihn nicht und ersetzt ihn nicht.
Umfang aus der FAQ von Google zur Android-Entwicklerverifizierung (Fassung vom 10. August 2026) und der Ankündigung vom 18. Juni 2026, die das Datum, die vier Länder und die sieben Stores nennt. Die Anforderung an den geschlossenen Test aus der Antwort 14151465 der Play Console-Hilfe. Alle abgerufen am 13. August 2026.
Warum das keine Lücke ist
"Noch nicht erfasst" beschreibt eine Rollout-Phase und keine dauerhafte Ausnahme, und es als Ausnahme zu lesen ist das genaue Spiegelbild des Fehlers, den dieser Artikel korrigiert. Google hat gesagt, dass die Anforderung 2027 weltweit ausgeweitet wird. Die richtige Reaktion auf diesen Abschnitt ist Erleichterung über den September und Vorbereitung auf das Jahr danach, und genau dafür ist die Checkliste gegen Ende da. Verifiziert
Was sich am 30. September 2026 wirklich ändert
Google hat das Datum am 18. Juni 2026 gesetzt und es dann am 15. Juli schriftlich eingegrenzt. Ab dem 30. September wird eine Installation über einen von sieben benannten Stores in vier benannten Ländern geprüft: die App muss bei einem verifizierten Entwickler registriert sein. Die aktuelle FAQ von Google sagt, dass diese erste Phase für die benannten teilnehmenden Stores gilt und dass die Direktinstallation sowie nicht teilnehmende Stores noch nicht erfasst sind.
Wenn Sie bei Google Play veröffentlichen
Registrieren Sie bis zum 30. September 2026 jedes verbliebene Paket. Der Play-Console-Leitfaden von Google sagt, alle Apps zu registrieren, die Sie weiter vertreiben wollen, um "eine weltweite Entfernung aus Google Play zu vermeiden". Diese Pflicht ist global. Sie hat mit den vier Ländern nichts zu tun und gilt auch dann, wenn kein einziger Ihrer Nutzer dort lebt.
Was Nutzer am 30. September erleben
Die geräteseitige Durchsetzung startet nur in vier Ländern. Die erste Installationsprüfung betrifft die sieben teilnehmenden Stores in Brasilien, Indonesien, Singapur und Thailand. Sie erfasst weder das direkte Sideloading noch Stores außerhalb dieser Liste.
Das sind zwei getrennte Pflichten zum 30. September, und sie zu vermischen ist die häufigste Fehllesart dieses Datums. Die Play-Paketregistrierung ist global und entscheidet, ob Ihr Eintrag online bleibt; die Installationsdurchsetzung ist regional und entscheidet, was auf dem Telefon eines Nutzers passiert. Verifiziert
Die sieben teilnehmenden Stores
Nennen Sie sie genau. Das als Beschränkung für sämtliche App-Stores zu beschreiben ist nach dem aktuellen Wortlaut von Google für die erste Phase zu weit gefasst: nach der von Google veröffentlichten Liste liegt ein Store, der hier nicht genannt ist, außerhalb des Rollouts zum 30. September.
| Unternehmen | Teilnehmender Store | Ab 30. Sept. in den vier Ländern geprüft? |
|---|---|---|
| Google Play | Ja | |
| HONOR | HONOR App Market | Ja |
| OPlus | OPPO App Market | Ja |
| Samsung | Galaxy Store | Ja |
| Transsion | Palm Store | Ja |
| vivo | V-Appstore | Ja |
| Xiaomi | GetApps | Ja |
| Sie selbst, direkt | E-Mail, Download-Link, Ihre Website, Drive und per Schlussfolgerung ein APK aus Firebase App Distribution | Nein, noch nicht |
| Alle anderen | Jeder App-Store, der oben nicht genannt ist | Nein, noch nicht |
Store-Liste und Länder aus der Ankündigung von Google vom 18. Juni 2026; der Ausschluss der Direktinstallation und der nicht teilnehmenden Stores aus der Verifizierungs-FAQ in der Fassung vom 10. August 2026. Abgerufen am 13. August 2026. Verifiziert
Die vier Länder und die Formfaktoren darin
Zwei Details grenzen das weiter ein und lohnen sich zu merken. Für die Verteilung außerhalb von Google Play gibt die Verifizierungs-FAQ von Google an, dass die Durchsetzung in den ausgewählten Regionen zunächst für die Formfaktoren Smartphone und Tablet gilt. Dieselbe FAQ sagt, dass die Schutzmechanismen über Google Play services auf zertifizierten Android-Geräten ab Android 7 ausgeliefert werden, was den späteren Geräteumfang beschreibt und keine Grenze nur für September.
Was sich im September nicht ändert
Die folgende Liste ist kurz, deckt aber ab, wie die meisten kleinen Teams einen Build tatsächlich bewegen. Nichts davon ist von der Phase zum 30. September betroffen.
Eine Direktinstallation. Von der ersten Phase nicht erfasst.
Ebenfalls eine Direktinstallation, mit derselben Antwort.
Direkte Verteilung eines signierten APK an eingeladene Tester. Das ganze Bild steht in Abschnitt 08. Google veröffentlicht keine Firebase-spezifische Festlegung, das ist also eine Schlussfolgerung aus der Direkt-Sideload-Regel und keine ausdrückliche Ausnahme. Teilweise, Schluss
Google sagt, dass sich an der Funktionsweise von ADB nichts ändert. Abschnitt 05.
Außerhalb der ersten Phase, nach derselben FAQ-Antwort.
Das ist eine eigenständige Anforderung von Play, und sie gilt weltweit. Google sagte am 18. Juni 2026, dass über 99% der Apps von Play-Entwicklern bereits automatisch registriert worden seien.
Die 99%-Zahl trägt ein Datum
Die Zahl von über 99% automatischer Registrierung stammt aus dem Update von Google vom 18. Juni 2026. Manche Beiträge wiederholen noch einen älteren Wert von etwa 98%. Nutzen Sie die neuere Zahl und zitieren Sie sie mit ihrem Datum statt als zeitlose Tatsache, denn Google aktualisiert die Verbreitungsstatistiken im Lauf des Rollouts. Die aktuelle Übersichtsseite von Google zur Entwicklerverifizierung rundet dieselbe Zahl inzwischen auf 99%, nennen Sie also beide Zahlen mit Quelle und Datum statt als feste Konstante. Verifiziert
Was passiert, wenn die Verifizierung 2027 weltweit ausgeweitet wird
Google sagt, die Anforderung werde 2027 und danach weltweit ausgeweitet, auf Apps auf zertifizierten Android-Geräten ab Android 7, ausgeliefert über Google Play services. Ein genaues weltweites Datum oder einen Fahrplan nach Ländern hat Google nicht angekündigt. Behandeln Sie jedes konkrete Datum für 2027 als inoffiziell, solange Google es nicht veröffentlicht.
Die Chronologie und was jedes Datum mit einem geteilten APK macht
-
30. März 2026
Die Verifizierung wird an alle Entwickler ausgerollt
Google hat begonnen, die Android-Entwicklerverifizierung in der Play Console und der Android Developer Console an alle Entwickler auszurollen.
Rohes APK Allein durch dieses Datum ändert sich für Nutzer nichts an der Installation. Nicht verifizierte App Weiterhin nach dem bestehenden Android-Verhalten installierbar. -
August 2026
Erweiterter Ablauf und Konten mit begrenzter Verteilung gehen weltweit live
Google hat den weltweiten Start des erweiterten Installationsablaufs und der Konten mit begrenzter Verteilung für diesen Monat geplant. Stand 13. August 2026 nennen die geprüften Quellen den Monat, aber keinen genauen Tag, und sie belegen nicht, dass der Ablauf bereits alle Nutzer erreicht hat. Teilweise
Rohes APK Weiterhin verfügbar. Nicht verifizierte App Der erweiterte Ablauf ist der Mechanismus, der ihre Installation erhalten soll. -
30. September 2026
Die Durchsetzung der Registrierung beginnt in sieben Stores, vier Ländern
Installationen über Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore und Xiaomi GetApps in Brasilien, Indonesien, Singapur und Thailand setzen voraus, dass die App bei einem verifizierten Entwickler registriert ist. Verifiziert
Rohes APK Von dieser ersten Phase noch nicht erfasst. Nicht verifizierte App Eine Installation über einen teilnehmenden Store kann eingeschränkt werden; der direkte Weg bleibt in dieser Phase unberührt. -
2027 und danach
Weltweite Ausweitung auf zertifizierte Android-Geräte
Die Verifizierung wird weltweit auf Apps auf zertifizierten Android-Geräten ab Android 7 ausgeweitet. In dieser Phase ändert sich die Antwort zur Direktinstallation. Verifiziert
Rohes APK Registrierte App: der gewohnte Installationsweg. Nicht registrierte App: erweiterter Ablauf oder ADB nach dem angekündigten Modell. Nicht verifizierte App Erweiterter Ablauf oder ADB bleibt der angekündigte Weg. -
Genaues Datum 2027
Stand 13. August 2026 nicht angekündigt
Der von Google veröffentlichte Zeitplan sagt 2027 und danach, mehr nicht. Auch eine Reihenfolge nach Ländern wurde nicht mitgeteilt. Nicht dokumentiert
Rohes APK Planen Sie nicht auf einen bestimmten Tag. Nicht verifizierte App Planen Sie nicht auf einen bestimmten Tag.
Chronologie aus dem Rollout-Beitrag von Google vom 30. März 2026, der Ankündigung vom 18. Juni 2026 und der FAQ zur Android-Entwicklerverifizierung in der Fassung vom 10. August 2026. Abgerufen am 13. August 2026.
Die Frist, die es nicht gibt
Der "1. Januar 2027" taucht in Sekundärberichten und in Antworten von KI-Assistenten auf. In keiner für diesen Artikel geprüften Google-Quelle steht er. Google hat sich auf 2027 und danach festgelegt, ohne einen Tag zu nennen. Wenn eine Ihrer Planungen davon abhängt, dieses Datum zu kennen, ist der ehrliche Stand: außerhalb von Google kennt es noch niemand. Die praktische Absicherung ist, Ihre Pakete lange vor dem Jahreswechsel registrieren zu lassen. Nicht dokumentiert
Verifiziertes gegen nicht verifiziertes APK: was Android wirklich prüft
"Bin ich verifiziert?" ist für sich genommen die falsche Frage. Die Android-Entwicklerverifizierung erzeugt, was Google eine formale, überprüfbare Verbindung nennt: zwischen einer Entwickleridentität, dem Paketnamen einer App und dem Signaturschlüssel oder den Signaturschlüsseln dieses Pakets. Die Identitätsprüfung ist ein Glied dieser Kette, nicht die ganze Kette.
Die Kette, Glied für Glied
Wer Sie sind, einmalig über die Play Console oder die Android Developer Console bestätigt.
Einmal pro KontoDie Kennung der App, zum Beispiel com.example.app, registriert auf diese verifizierte Identität.
Das Eigentum wird belegt, indem Sie ein mit Ihrem privaten Schlüssel signiertes APK bereitstellen. Die Console erlaubt es, mehrere Schlüssel für ein Paket hinzuzufügen und zu verifizieren.
Pro Schlüssel, nicht pro BuildIst die Kette vollständig, bleibt laut Google die gewohnte Installationserfahrung der Nutzer erhalten, sobald die weitergehende Durchsetzung greift.
Das gewünschte ErgebnisKette aus den Leitfäden von Google zur Android-Entwicklerverifizierung, einschließlich der Beschreibung des Eigentumsnachweises, und der Unterstützung mehrerer Signaturschlüssel aus der Verifizierungs-FAQ. Abgerufen am 13. August 2026. Verifiziert
Google sagt ausdrücklich, dass die Direktinstallation für Android grundlegend ist und dass verifizierte Entwickler weiterhin direkt verteilen können. Die Nuance, die dieser Satz verdeckt: eine reibungslose Installation hängt daran, dass die App registriert ist, und nicht bloß daran, dass Sie eine Identitätsprüfung bestanden haben. Deshalb sagt dieser Artikel jedes Mal "bei einem verifizierten Entwickler registriert" statt der kürzeren, lockereren Formel "verifizierte App".
Was, wenn Sie einen Debug-Schlüssel oder einen eigenen QA-Signaturschlüssel nutzen?
Genau hier geraten echte QA-Teams in die Falle, denn es ist völlig normal, einen debug-signierten Build an interne Tester und einen release-signierten Build an den Store zu geben. Das sind unterschiedliche Zertifikate für denselben Paketnamen.
Audit der Signaturschlüssel, vier Fragen
- Welches Zertifikat signiert das APK, das Ihre Nutzer installieren? Genau das gehört registriert. Beim Play App Signing signiert der App-Signaturschlüssel das aus Google Play installierte APK, während der Upload-Schlüssel nur das bei Play hochgeladene Artefakt authentifiziert und nicht automatisch das Zertifikat der installierten Fassung ist. Ein Debug-, CI-, QA- oder Upload-Schlüssel zählt für die Direktverteilung nur dann, wenn er das APK signiert, das Sie Testern geben.
- Sind die relevanten Schlüssel für das Paket registriert? Google unterstützt es, mehrere Signaturschlüssel für einen Paketnamen hinzuzufügen und zu verifizieren: Sie müssen also nicht alles auf einen Schlüssel zusammenführen.
- Nehmen Sie nicht an, dass die Identitätsprüfung jeden Schlüssel abdeckt. Den Identitätsschritt zu bestehen segnet nicht stillschweigend jedes Zertifikat ab, das Sie je verwendet haben.
- Zwei APKs mit demselben Paketnamen, aber ohne dieselbe Signatur, sind nicht austauschbar. Das ist das gewöhnliche Verhalten der Android-App-Signatur und deutlich älter als die Verifizierung, wird aber leicht mit einem Verifizierungsproblem verwechselt. Siehe Abschnitt 12.
Fünf Grenzfälle, die Google tatsächlich beantwortet hat
Diese fünf kommen ständig auf, und alle fünf haben veröffentlichte Antworten. Man muss also nicht raten.
Umfangsfragen mit dokumentierter Antwort
- Android 6 oder älter? Außerhalb des angegebenen Umfangs. Google sagt, die Durchsetzung gilt für zertifizierte Android-Geräte ab Android 7, ausgeliefert über die Google Play-Dienste. Verifiziert
- Nicht zertifizierte Geräte oder Custom-ROMs ohne Google Play-Dienste? Google beschreibt diese Durchsetzung für zertifizierte Android-Geräte über die Play-Dienste. Übertragen Sie die Regel nicht pauschal auf jedes Custom-ROM oder nicht zertifizierte Gerät, denn die liegen außerhalb des von Google dokumentierten Mechanismus. Für solche Geräte nicht dokumentiert
- Unternehmens-Apps auf verwalteten Geräten? Apps, die über Ihren Organisationsstore auf verwaltete Geräte verteilt werden, müssen die Verifizierung nicht durchlaufen, weil Ihre IT-Abteilung sie geprüft hat. Google empfiehlt trotzdem, sie zu registrieren, falls die App auch aus einer anderen Quelle oder auf ein nicht verwaltetes Gerät installiert wird. Verifiziert
- Wo prüfe ich, ob ein Paket registriert ist? Play-Entwickler: die Seite zur Android-Entwicklerverifizierung in der Play Console, die den Status neben jeder App zeigt. Entwickler außerhalb von Play: der Tab Paketnamen in der Android Developer Console mit Registriert, Nicht registriert oder Entwurf. Auch Android Studio Panda 4 und höher zeigt den Registrierungsstatus beim Erstellen eines signierten APK oder App Bundle. Verifiziert
- Zahlen Entwickler außerhalb von Play 25 US-Dollar? Das Konto der Android Developer Console für die volle Verteilung kostet 25 US-Dollar. Das Konto für die begrenzte Verteilung ist kostenlos, verlangt keinen amtlichen Ausweis und ist auf 20 autorisierte Geräte begrenzt. Wer bereits bei Google Play veröffentlicht, verwaltet die Verifizierung in der Play Console statt ein separates Konto zu eröffnen. Prüfen Sie zuerst die Verfügbarkeit: Stand 13. August 2026 war der frühe Zugang noch geschlossen. Verfügbarkeit teilweise
Firebase verlangt ebenfalls eine Signatur, aber aus einem anderen Grund
Firebase App Distribution verlangt, dass ein APK mit einem Debug-Schlüssel oder einem App-Signaturschlüssel signiert ist, bevor es verteilt wird. Das ist eine Firebase-Anforderung an die Gültigkeit des Builds und kein Schritt der Android-Entwicklerverifizierung. Beide Systeme nutzen das Wort "registrieren", und sie auseinanderzuhalten ist bei diesem Thema eine wichtige Unterscheidung. Abschnitt 08 trennt sie. Verifiziert
Die Unterscheidung zwischen Upload- und App-Signaturschlüssel erklärt auch das häufigste Firebase-Ticket. Eine aus Play installierte Kopie Ihrer App kann mit dem App-Signaturschlüssel von Google Play signiert sein, während das Firebase-APK, das Sie demselben Tester geben, lokal mit einem Upload-, Release- oder Debug-Schlüssel signiert ist. Android kann das eine nicht über das andere installieren, solange die akzeptierten Signaturidentitäten nicht zusammenpassen. Der Tester sieht dann einen Fehler, der wie ein Verifizierungsproblem aussieht und keines ist. Verifiziert
ADB bleibt erlaubt, ist aber ein Entwickler-Workflow
Die klarste Zusage von Google in diesem ganzen Programm, aus seiner Verifizierungs-FAQ: an der Funktionsweise von ADB ändert sich nichts. Entwickler und erfahrene Nutzer können weiterhin so installieren, und die 24-Stunden-Wartezeit des erweiterten Ablaufs gilt für ADB-Installationen nicht. Es ist der beständigste technische Weg in diesem Artikel und zugleich der für gewöhnliche Tester am wenigsten geeignete.
Gut für
- Sie selbst, auf dem eigenen Gerät, den ganzen Tag
- Ein technisches QA-Team, das Android Studio ohnehin installiert hat
- CI-Pipelines und Gerätefarmen
- Einen nicht registrierten Build installieren, ohne die Wartezeit des erweiterten Ablaufs abzusitzen
- Eine Kollegin, die mit einem USB-Kabel neben Ihnen sitzt
Schlecht für
- Zwölf Freunde, Familienmitglieder oder angeworbene Tester
- Jeden, den Sie nicht am Telefon durch die Entwickleroptionen führen können
- Tester in anderen Ländern, ohne Kabel und ohne Laptop
- Schnelle Iteration: jeder neue Build braucht Zugriff auf das Gerät und einen weiteren Installationsbefehl, auch wenn der Tester nicht die ganze Einrichtung wiederholt
- Alles, was Google Play zählen soll. ADB-Installationen sind für die Testanforderungen von Play unsichtbar
Was ein Tester vorher tun muss
Die Werkzeugdokumentation von Google ist bei der Voraussetzung deutlich: um ADB über USB zu nutzen, müssen Sie das USB-Debugging aktivieren, in den Entwickleroptionen des Geräts. Auf einem aktuellen Telefon heißt das: die Build-Nummer finden, sie sieben Mal antippen, um die Entwickleroptionen freizuschalten, und dann in einem Einstellungsbildschirm mit Warnhinweis das USB-Debugging aktivieren. Für einen technischen Tester ist dieser Ablauf machbar, für jemanden, der sich einfach bereit erklärt hat, Ihre App auszuprobieren, ist er eine Zumutung.
Die Einrichtung wiederholt sich nicht bei jedem Build, und genau das steht in den meisten Anleitungen falsch. Sobald der Tester Ihren Rechner autorisiert hat, bleibt diese Autorisierung bestehen, bis er sie widerruft oder das Gerät vergisst. Ein neuer Build kostet also ein weiteres adb install -r und Zugriff auf das Telefon, nicht einen weiteren Gang durch die Entwickleroptionen. Ab Android 11 gibt es zusätzlich das drahtlose Debugging: Der Tester koppelt das Telefon einmal per QR-Code oder Kopplungscode mit dem Rechner, danach installieren Sie über das Netzwerk, solange beide Geräte darin sind, ganz ohne Kabel. Das erspart das Kabel, nicht die technische Voraussetzung.
Die drei Befehle, die fast jede Installation bei einem Tester abdecken. Nichts davon ist 2026 neu; es ist der Workflow, den Google als unverändert bezeichnet.
adb devicesadb install app-release.apkadb install -r app-release.apkDer Befehl, der überrascht: -r funktioniert nur, wenn das neue APK mit demselben Zertifikat signiert ist wie das installierte. Ein mit einem anderen Schlüssel signierter Build muss zuerst deinstalliert werden, was die Daten der App mitnimmt. Das ist das übliche Verhalten der Android-App-Signatur und keine Verifizierungsregel.
Nutzen Sie ADB als Rückfallebene, nicht als Plan
Im angekündigten Modell von Google ist ADB eine dokumentierte Rückfallebene, um nicht verifizierte Apps zu installieren, auch über den geplanten weitergehenden Rollout hinweg. Es ist der Weg, der weiter funktioniert, wenn ein Build nicht registriert ist und der Tester keinen ganzen Tag abwarten wird. Es lohnt sich trotzdem, die Regel zu prüfen, bevor Sie sich 2027 darauf verlassen. Was es nicht ist: ein Weg, zwölf gewöhnliche Menschen an Bord zu holen, und die Testanforderung von Google Play für den Produktionszugriff wird es nie erfüllen. Verifiziert
Was ist der erweiterte Ablauf von Android für nicht verifizierte Apps?
Google hat einen bewussten Weg für Nutzer gebaut, die eine App eines nicht verifizierten Entwicklers trotzdem installieren wollen. Es ist eine einmalige Einrichtung mit einem Reibungsschritt in der Mitte: Entwicklermodus aktivieren, bestätigen, dass einen niemand dabei anleitet, neu starten, einen Tag warten, sich authentifizieren und dann nicht verifizierte Installationen für 7 Tage oder unbefristet zulassen. Die 24-Stunden-Wartezeit gehört zu dieser Einrichtung, sie ist keine Verzögerung vor jedem APK.
-
01
Entwicklermodus aktivieren
Der Nutzer aktiviert den Entwicklermodus oder die entsprechende Einstellung auf seinem Gerät.
Google: verhindert versehentliches Auslösen und die Ein-Tipp-Umgehungen aus Drucksituationen -
02
Bestätigen, dass niemand anleitet
Der Nutzer bestätigt, dass ihn keine andere Person durch diese Sicherheitsänderung führt.
Google: eine kurze Prüfung, dass niemand Sie zum Abschalten Ihrer Sicherheit überredet -
03
Neu starten und erneut anmelden
Das Gerät startet neu und der Nutzer meldet sich wieder an.
Google: unterbricht Fernzugriff oder einen laufenden Anruf, über den ein Betrüger zusieht -
04
24 Stunden warten, ein einziges Mal
Google beschreibt das als einmalige Wartezeit von einem Tag. Sie passiert während der Einrichtung, und sie ist der Schritt, den alle falsch wiedergeben.
Nicht 24 Stunden vor jedem APK. Einmal, pro Konto. -
05
Identität auf dem Gerät bestätigen
Der Nutzer bestätigt die Änderung per Biometrie oder mit der Geräte-PIN.
Google: Biometrie oder PIN bestätigt, dass der Gerätebesitzer die Änderung vornimmt -
06
Nicht verifizierte Installationen für 7 Tage oder unbefristet zulassen
Einrichtung abgeschlossen. Der Nutzer wählt die Dauer und kann beim Installieren die Warnung zu nicht verifizierten Entwicklern durchlaufen.
Seine Wahl, sein Risiko, sein Gerät
Abfolge, Wortlaut und Dauerwahl aus der FAQ von Google zur Android-Entwicklerverifizierung, abgerufen am 13. August 2026. Google veröffentlicht zu jedem Schritt dieses Ablaufs eine Begründung, die Hinweise oben geben also die Begründung von Google wieder statt sie zu erschließen. Verifiziert
Drei Dinge, die dabei falsch verstanden werden
"Also braucht jede Installation 24 Stunden Wartezeit?"
Nein. Google beschreibt eine einmalige Wartezeit von einem Tag innerhalb der Einrichtung. Danach wählt der Nutzer 7 Tage oder unbefristet für die Dauer, in der nicht verifizierte Installationen erlaubt bleiben.
"Muss man das auf jedem neuen Telefon wiederholen?"
Google sagt nein. Die FAQ beschreibt die Einrichtung als einmalig pro Konto, sie wird auf ein neues Gerät übernommen.
"Braucht ADB die Wartezeit auch?"
Nein. Google gibt ausdrücklich an, dass die 24-Stunden-Wartezeit für ADB-Installationen nicht gilt. Abschnitt 05.
Entwickleroptionen müssen nicht angeschaltet bleiben
Ein Tester kann die Entwickleroptionen wieder ausschalten, sobald der erweiterte Ablauf aktiviert ist. Die FAQ von Google sagt das direkt: Sie müssen die Entwickleroptionen nicht angeschaltet lassen, denn sobald die Änderung auf dem Gerät vorgenommen ist, ist die Einstellung aktiv. Das zählt für Tester, deren Banking- oder Firmen-Apps sich beschweren, wenn die Entwickleroptionen an bleiben. Google sagt außerdem, die Einrichtung erfolgt einmal pro Konto und wird auf ein neues Gerät übernommen, sie wiederholt sich also nicht für jede App und jedes Telefon. Verifiziert
Ist er gerade aktiv?
Ehrlicher Stand am 13. August 2026
Google hat den Start des erweiterten Ablaufs weltweit für August 2026 geplant. Die für diesen Artikel geprüften Quellen nennen den Monat, aber keinen genauen Tag, und keine belegt, dass der Ablauf bereits alle Nutzer erreicht hat. Einem Tester sagen Sie heute also richtigerweise, dass der Weg existiert und geplant ist, nicht dass er ihn heute Nachmittag mit Sicherheit nutzen kann. Prüfen Sie die Verifizierungsseiten von Google, bevor Sie ein Supportskript darum herum bauen. Teilweise
Die praktische Lesart für Entwickler: der erweiterte Ablauf ist eine echte, dokumentierte Antwort auf "kann ein Nutzer meine nicht verifizierte App noch installieren?" und eine schlechte Antwort auf "wie bekomme ich diese Woche einen Build zu zwölf Testern?". Eine Sicherheitsverzögerung von einem Tag mitten im Onboarding bedeutet echte Reibung für gelegentliche Tester und Remote-Tester. Wenn Ihre Tester gewöhnliche Nutzer sind, werden die Methoden, die deren Zeit respektieren, in Abschnitt 09 verglichen.
Was passiert mit bereits installierten APKs?
Die Dokumentation von Google behandelt das Installieren und das Aktualisieren. Sobald die Durchsetzung greift, kann eine nicht registrierte App nicht normal installiert oder aktualisiert werden, und Google sagt, eine gewöhnliche Aktualisierung "wird fehlschlagen", ohne den erweiterten Ablauf oder ADB. Was die geprüfte Dokumentation nicht sagt: dass Kopien, die bereits auf den Telefonen der Leute liegen, entfernt oder am Start gehindert werden.
| Situation, sobald die weitergehende Durchsetzung greift | Dokumentiertes Ergebnis | Beleg |
|---|---|---|
| Die App ist bereits installiert und der Nutzer öffnet sie einfach | Die geprüfte Google-Dokumentation kündigt keine erzwungene Entfernung und kein Blockieren zur Laufzeit an. Sie behandelt Installation und Aktualisierungen. | Teilweise |
| Ein Nutzer versucht, eine nicht registrierte App auf normalem Weg zu installieren | Die normale Installation ist eingeschränkt. | Verifiziert |
| Der Nutzer hat den erweiterten Ablauf aktiviert | Die nicht registrierte App kann installiert werden. | Verifiziert |
| Die Installation läuft über ADB | Die nicht registrierte App kann installiert werden. Es gilt keine Wartezeit des erweiterten Ablaufs. | Verifiziert |
| Eine installierte, nicht registrierte App erhält eine gewöhnliche Aktualisierung, erweiterter Ablauf aus | Google sagt, die Aktualisierung schlägt fehl. | Verifiziert |
| Dieselbe App wird über ADB aktualisiert | Zulässig, nach der von Google angekündigten Ausnahme. | Verifiziert |
Verhalten aus der FAQ von Google zur Android-Entwicklerverifizierung, abgerufen am 13. August 2026. Die erste Zeile stellt das Fehlen eines angekündigten Mechanismus fest, was nicht dasselbe ist wie das Versprechen, dass sich dieses Verhalten nie ändern kann.
Schreiben Sie nicht "Ihre App wird gelöscht"
Das ist die viralste Behauptung zu diesem Thema, und sie ist nicht belegt. Die korrekte Formulierung, die in diesem ganzen Artikel verwendet wird, lautet: Google dokumentiert Einschränkungen bei Installation und Aktualisierung; es hat nicht angekündigt, dass bereits installierte Kopien von Geräten entfernt oder am Start gehindert werden. Das Fehlen einer Quelle zu berichten ist ehrlich. Dieses Fehlen in eine Sicherheitsgarantie oder in die Vorhersage einer Massenlöschung umzumünzen ist es nicht. Teilweise, fehlende Quelle
Diese Unterscheidung ändert, was Sie tatsächlich tun sollten. Eine blockierte Aktualisierung ist ein echtes, dokumentiertes Betriebsproblem: ein betroffener Tester kann auf einem älteren Build hängen bleiben, weil sich die Aktualisierung auf normalem Weg nicht installieren lässt, und er meldet es womöglich nie, weil aus seiner Sicht nichts passiert ist. Eine Massendeinstallation wäre ein völlig anderer Notfall und bräuchte eine völlig andere Kommunikation. Nur eines von beidem ist belegt.
Wo Firebase App Distribution nach der Verifizierung hineinpasst
Firebase App Distribution bringt Vorabversionen auf die Geräte Ihrer Tester. Es ist kein Verifizierungssystem, kein Test-Track von Google Play, und es befreit nichts von der Android-Entwicklerverifizierung. Was es gut kann: die Handarbeit daraus nehmen, einen signierten Build an eine Liste von Menschen zu geben.
Wie der APK-Ablauf tatsächlich läuft
Sie laden ein signiertes APK in die Firebase-Konsole. Firebase verlangt, dass es mit einem Debug-Schlüssel oder einem App-Signaturschlüssel signiert ist.
Wählen Sie Testergruppen oder einzelne Tester für diesen Release aus.
Die Tester erhalten eine Einladung und installieren den verteilten Build.
Verteilte Builds bleiben 150 Tage verfügbar. Einladungen an Tester laufen nach 30 Tagen ab, und Firebase warnt 5 Tage vorher.
Ablauf, Signaturanforderung, 150 Tage Aufbewahrung der Builds und 30 Tage Ablauf der Einladungen aus der Android-Dokumentation von Firebase App Distribution, abgerufen am 13. August 2026. Verifiziert
Zwei Ablauffristen, zwei verschiedene Supportfälle
Der Ablauf der Einladung nach 30 Tagen und die Aufbewahrung des Builds über 150 Tage sind zwei verschiedene Dinge. Ein Tester, der die E-Mail fünf Wochen liegen lässt, hat eine abgelaufene Einladung, während der Build noch völlig in Ordnung ist. Daraus entsteht eine verwirrte Meldung im Stil von "der Link ist kaputt", die mit Verifizierung, Signatur oder Android überhaupt nichts zu tun hat. Verifiziert
Funktioniert Firebase während der Septemberphase weiterhin?
Mit ziemlicher Sicherheit ja, und es kommt darauf an, wie man zu dieser Antwort kommt. Der APK-Ablauf von Firebase ist die direkte Verteilung eines signierten APK an eingeladene Tester. Die FAQ von Google sagt, dass die Direktinstallation von der Phase zum 30. September nicht erfasst ist. Legt man beides zusammen, sollte die APK-Verteilung über Firebase in dieser ersten Phase nutzbar bleiben.
Diese Schlussfolgerung ist ein Schluss und ist als solcher gekennzeichnet
Keine Google-Quelle nennt Firebase App Distribution und gewährt ihm eine Ausnahme. Die obige Schlussfolgerung folgt aus zwei verifizierten Fakten: Direktinstallationen liegen außerhalb der anfänglichen Durchsetzung im September, und der APK-Ablauf von Firebase ist eine direkte Verteilung. Das ist ein solider Schluss, und er bleibt ein Schluss: deshalb bewertet dieser Artikel ihn, statt ihn schlicht zu behaupten. Teilweise, Schluss
Firebase-Verteilung per APK und per AAB sind nicht dasselbe
Das ist die Nuance, die fast jeder Artikel einebnet. Firebase unterstützt beides, und beide nehmen unterschiedliche Wege zum Telefon des Testers.
| Firebase-Ablauf | Wie der Build zum Tester kommt | Wie man ihn für die Verifizierung einordnet |
|---|---|---|
| APK | Firebase verteilt das signierte APK direkt an eingeladene Tester. | Direkte Verteilung. Verhält sich wie der Weg der Direktinstallation, auch im September. Teilweise |
| Android App Bundle (AAB) | Der AAB-Ablauf von Firebase ist mit dem internen App-Sharing von Google Play verzahnt. | Ein mit Play verbundener Weg: denken Sie darüber also nicht wie über den Weg des rohen APK nach. Google hat nicht gesagt, wie er unter der Durchsetzung im September behandelt wird. Verzahnung verifiziert Durchsetzung nicht dokumentiert |
Ein AAB lässt sich gar nicht sideloaden
Bevor irgendeine Verifizierungsfrage zählt, gibt es eine einfachere, über die viele stolpern: Ein Android App Bundle lässt sich nicht direkt auf einem Telefon installieren. Eine .aab-Datei ist ein Veröffentlichungsformat, kein gerätefertiges Paket. Google Play, der Play-gebundene AAB-Ablauf von Firebase oder bundletool muss daraus erst APKs machen. Wenn Sie also eine Datei brauchen, die Sie per E-Mail verschicken, auf Drive legen oder einem Tester direkt geben können, bauen Sie ein APK. Die Build-Dokumentation von Android sagt selbst, dass ein App Bundle nicht direkt auf ein Gerät ausgerollt werden kann. Verifiziert
Die Frage "funktioniert Firebase noch?" hat also zwei Antworten, je nachdem, welches Artefakt Sie hochladen. Wenn Sie darüber schreiben oder eine Kollegin danach fragen, sagen Sie ausdrücklich Firebase-Verteilung per APK oder Firebase-Verteilung per AAB. Die Kurzform verdeckt ein Detail, das die Analyse maßgeblich verändert.
Zählt Firebase App Distribution für die Regel der 12 Tester?
Nein. Die Anforderung von Google für den Produktionszugriff betroffener Konten verlangt mindestens 12 zu einem geschlossenen Test bei Google Play angemeldete Tester, fortlaufend, über die letzten 14 Tage. Firebase-Tester sind nicht zu einem geschlossenen Test bei Play angemeldet, ein Test über Firebase erfüllt die Anforderung also nicht, egal wie viele Menschen teilnehmen und wie gründlich sie testen.
| Frage | Firebase App Distribution | Geschlossener Test bei Google Play |
|---|---|---|
| Wofür ist es da? | Vorabversionen schnell zu Testern bringen | Die Vorproduktionshürde von Play nehmen und im Store testen |
| Wo melden sich Tester an? | Über eine Einladungs-E-Mail von Firebase | Über einen Anmeldelink von Play, im geschlossenen Track |
| Registriert es Ihre App für die Android-Entwicklerverifizierung? | Nein das "App registrieren" von Firebase ist ein völlig anderer Vorgang | Nein die Paketregistrierung ist eine eigene Aufgabe |
| Erfüllt es die Anforderung von 12 Testern über 14 fortlaufende Tage? | Nein | Ja für infrage kommende Tester und Konten |
| Lohnt es sich trotzdem? | Ja als QA-Kanal, neben dem geschlossenen Test | Ja es ist der verlangte Weg |
Play-Anforderung aus der Antwort 14151465 der Play Console-Hilfe; Firebase-Verhalten aus der Dokumentation von Firebase App Distribution. Beide abgerufen am 13. August 2026. Die zwei Produkte definieren unterschiedliche Vorgänge, die sich das Wort "registrieren" teilen. Verifiziert
Das dabei entstehende Muster verdient einen Namen, denn es kostet zwei Wochen. Ein Entwickler führt einen wirklich gründlichen Firebase-Test mit fünfzehn engagierten Testern durch, hakt das Thema Testen ab, öffnet die Play Console, um den Produktionszugriff zu beantragen, und stellt fest, dass die Uhr für die 14 Tage nie angelaufen ist. Abschnitt 10 stellt die beiden Anforderungen nebeneinander, damit Ihnen das nicht passiert.
Der beste Weg, 2026 einen Build zu 12 Testern zu bringen
Es gibt keinen einzelnen Sieger, denn die Methoden lösen verschiedene Probleme. Ein rohes APK ist das Einfachste, was heute funktioniert. ADB ist das Beständigste und das am wenigsten Benutzbare. Firebase ist der beste reine QA-Kanal. Und nur eine Methode auf dieser Seite erfüllt die Anforderung von Google Play für den Produktionszugriff, also das, was wirklich über Ihren Starttermin entscheidet.
Prüfer für die Verteilungsmethode
Es wird nichts irgendwohin gesendet. Die Logik läuft in Ihrem Browser und stützt sich auf den von Google veröffentlichten Umfang, die Dokumentation von Firebase und die Regel von Play für den Produktionszugriff.
1 Wie bringen Sie den Build zu ihnen?
2 Wo sind Ihre Tester?
3 Ist die App bei einem verifizierten Entwickler registriert?
Umfang aus der Verifizierungs-FAQ von Google (10. August 2026), der Dokumentation von Firebase App Distribution und der Antwort 14151465 der Play Console-Hilfe. Abgerufen am 13. August 2026.
Alle sieben Methoden nebeneinander
Das Werkzeug beantwortet eine Situation. Diese Tabelle beantwortet alle, einschließlich der zwei Spalten, die man überspringt, bis es zu spät ist: das angekündigte Verhalten für 2027 und die Frage, ob die Methode überhaupt etwas für Ihren Antrag auf Produktionszugriff bei Play bringt.
| Methode | Was der Tester tun muss | Erste Phase am 30. Sept. 2026 | Angekündigtes Modell 2027 | Zählt für 12/14 bei Play? | Praktisches Urteil |
|---|---|---|---|---|---|
| Rohes APK per E-Mail, Drive oder Website | Das APK herunterladen und die Installation aus dieser Quelle zulassen | Weiterhin tragfähig die Direktinstallation ist noch nicht erfasst | Registrierte App installiert normal; bei nicht registrierter App sind erweiterter Ablauf oder ADB zu erwarten | Nein | Für spontane QA heute völlig in Ordnung. Nicht der Test für den Produktionszugriff. |
| ADB | Entwickleroptionen und USB-Debugging aktivieren, verbinden, mit Entwicklerwerkzeugen installieren | Ja | Ja Google erhält ADB ausdrücklich | Nein | Beständig, aber für gewöhnliche Tester zu technisch. |
| Firebase App Distribution, APK | Die Einladungs-E-Mail annehmen und den verteilten Build installieren | Wahrscheinlich nicht betroffen nach der Direkt-Sideload-Regel. Keine Firebase-spezifische Festlegung. Teilweise | Ein registriertes Paket sollte reibungslos bleiben; ein nicht registriertes folgt dem weiteren Modell der Direktinstallation | Nein | Hervorragender QA-Workflow. Kein Ersatz für den Test bei Play. |
| Firebase App Distribution, AAB | Den Build über einen Ablauf erhalten, der mit dem internen App-Sharing von Play verzahnt ist | Nicht dokumentiert über das interne App-Sharing mit Play verbunden; Google hat nicht gesagt, wie dieser Weg behandelt wird Nicht dokumentiert | Hängt von Play und der Paketregistrierung ab | Nein | Nützlich, und verdient eine eigene Erklärung statt mit Firebase APK in einen Topf geworfen zu werden. |
| Interner Test bei Google Play | Dem internen Test beitreten und aus Play installieren | Tragfähig für eine ordentlich registrierte Play-App | Tragfähig | Nein kein Ersatz für den verlangten geschlossenen Test | Gute schnelle QA auf Play-Basis. Bis zu 100 Tester. |
| Geschlossener Test bei Google Play | Sich über den Link zum geschlossenen Test anmelden und angemeldet bleiben | Tragfähig | Tragfähig | Ja für infrage kommende Tester und Konten | Der verlangte Weg für betroffene neue private Konten, die Produktionszugriff wollen. |
| Begrenzte Verteilung bei Android | Ein Gerät haben, das im System der begrenzten Verteilung autorisiert ist | Für August 2026 geplant, früher Zugang noch geschlossen Teilweise | Als beständiger Weg für kleines Publikum entworfen | Nein | Für Hobbyentwickler, die mit bis zu 20 Geräten teilen. Kostenlos, ohne amtlichen Ausweis, kann nicht bei Play veröffentlichen. |
Quellen: die FAQ und die Leitfäden von Google zur Verifizierung, die Dokumentation zum Werkzeug ADB, die Dokumentation zu Firebase App Distribution, die begrenzte Verteilung, die Play Console-Hilfe zum internen Test und zu den Testanforderungen für den Produktionszugriff. Alle abgerufen am 13. August 2026.
Die ehrliche Empfehlung
Fahren Sie zwei Stränge parallel, denn sie beantworten verschiedene Fragen. Nutzen Sie für echte QA, was einen Build am schnellsten auf Geräte bringt: ein rohes APK für einen Kollegen, Firebase für eine Gruppe, ADB, wenn Sie alles umgehen müssen. Und starten Sie davon getrennt und so früh wie möglich den geschlossenen Test bei Play, wenn Ihr Konto der Anforderung für den Produktionszugriff unterliegt, denn der wird in Kalendertagen gemessen und lässt sich durch mehr Einsatz nicht verkürzen.
Der Fehler, den es zu vermeiden gilt, ist, beides als nacheinander zu behandeln. Einen gründlichen Firebase-Test abzuschließen bringt die Uhr über 14 Tage keinen einzigen Tag voran.
Die Entwicklerverifizierung ersetzt den geschlossenen Test bei Google Play nicht
Das sind zwei voneinander unabhängige Anforderungen, die viele zu einem einzigen gedanklichen Häkchen verschmelzen. Die Verifizierung beantwortet "wer hat dieses Paket erstellt und signiert?" Der geschlossene Test beantwortet "hat dieses Konto den Vorproduktionstest von Google abgeschlossen?" Eines von beiden zu erfüllen bringt für das andere überhaupt nichts.
Verifizierungsmodell aus den Leitfäden von Google zur Android-Entwicklerverifizierung; Testanforderung aus der Antwort 14151465 der Play Console-Hilfe und der Seite zum internen Test (Antwort 9845334). Abgerufen am 13. August 2026.
Warum "der interne Test zählt, es ist doch auch ein Play-Test" falsch ist
Google erlaubt bis zu 100 Tester in einem internen Test, was ihn nach der ernsteren Option aussehen lässt. Die Anforderung für den Produktionszugriff ist aber um einen bestimmten Track herum formuliert: die zählenden Tester müssen über die letzten 14 Tage fortlaufend zu einem geschlossenen Test angemeldet gewesen sein. Der interne Test ist ein anderer Track und erfüllt diesen Satz daher nicht.
Eine Anmerkung zur Quelle dieser Aussage
Google veröffentlicht keinen Satz mit dem Inhalt "der interne Test zählt nicht". Was Google veröffentlicht, ist eine Anforderung, die einen geschlossenen Test benennt. Die Schlussfolgerung folgt aus der Definition und nicht aus einem Zitat, und dieser Artikel formuliert sie so, statt Google Worte in den Mund zu legen. Verifiziert über die Definition der Anforderung
Die Zahlen und woher sie stammen
Zwei Punkte aus der Vorgeschichte klären Fragen, die ständig auftauchen. Google hat die Anforderung am 9. November 2023 angekündigt, und die aktuelle Regel wendet sie auf private Konten an, die nach dem 13. November 2023 erstellt wurden: zwei verschiedene Daten, die zwei verschiedene Dinge bedeuten. Und das Minimum lag ursprünglich bei 20 Personen über mindestens zwei Wochen; der Community-Leitfaden von Google nennt selbst Dezember 2024 als Zeitpunkt der Senkung auf 12. Zeitgenössische Entwicklerberichte verorten die Änderung in der Play Console auf den 11. Dezember 2024, eine datierte Google-Ankündigung für genau diesen Tag ließ sich aber nicht finden: behandeln Sie den Tag also als berichtet und nicht als offiziell. Teilweise
Organisationskonten liegen außerhalb dieser bestimmten Hürde: die Anforderung gilt für infrage kommende private Konten. Und die Gebühr ist in beiden Fällen dieselbe, eine einmalige Registrierungsgebühr von 25 $ bei Google Play. Wenn Sie den vollständigen Vergleich der Kontotypen statt eines Absatzes möchten, steht er unter privates Konto oder Organisationskonto.
Zehn Behauptungen dazu, die nicht mehr aktuell sind
Ein großer Teil der Beiträge zur Android-Entwicklerverifizierung wurde geschrieben, bevor Google die erste Phase im Juni und Juli 2026 eingegrenzt hat. Die folgenden Behauptungen sind keine Lügen; mehrere waren bei ihrer Veröffentlichung zutreffend. Sie beschreiben schlicht eine Fassung der Regel, die den aktuellen Seiten von Google nicht mehr entspricht.
Behauptung Ab dem 30. September sind in den vier Ländern alle direkten APK-Installationen blockiert.
Aktuelle Regel Falsch nach der FAQ von Google vom 15. Juli 2026. Der 30. September erfasst sieben teilnehmende Stores. Direktinstallationen sind noch nicht erfasst. Verifiziert
Behauptung Entwicklerverifizierung heißt, dass man keine App eines nicht verifizierten Entwicklers mehr installieren kann.
Aktuelle Regel Zu absolut. ADB bleibt verfügbar, und Google hat den erweiterten Ablauf genau für nicht verifizierte Apps gebaut. Verifiziert
Behauptung Die weltweite Frist ist der 1. Januar 2027.
Aktuelle Regel Nicht belegt. Google hat "2027 und danach" angekündigt und kein genaues weltweites Datum. Nicht dokumentiert
Behauptung Ist die Identität einmal verifiziert, ist jedes APK, das Sie signieren, in Ordnung.
Aktuelle Regel Unvollständig. Der Paketname und die betroffenen Signaturschlüssel müssen ebenfalls registriert sein. Verifiziert
Behauptung Firebase App Distribution verifiziert Ihre Android-App.
Aktuelle Regel Verwechslung. Das "App registrieren" von Firebase und die Registrierung der Android-Entwicklerverifizierung sind verschiedene Systeme. Verifiziert
Behauptung Firebase-Tester zählen für die 12 Tester von Google.
Aktuelle Regel Falsch. Google verlangt 12 zum geschlossenen Test bei Play angemeldete Tester. Verifiziert
Behauptung Der interne Test bei Play zählt, es ist ja auch ein Play-Test.
Aktuelle Regel Für diese Hürde nicht. Die Anforderung für den Produktionszugriff nennt ausdrücklich einen geschlossenen Test. Über die Definition verifiziert
Behauptung Bereits installierte, nicht verifizierte Apps werden gelöscht.
Aktuelle Regel Nicht belegt. Google dokumentiert Einschränkungen bei Installation und Aktualisierung und kündigt keine automatische Entfernung installierter Kopien an. Teilweise, fehlende Quelle
Behauptung Der erweiterte Ablauf ist bestimmt überall aktiv, es ist ja August.
Aktuelle Regel Zu stark. Google hat einen weltweiten Start im August 2026 geplant, ohne einen genauen Starttag zu veröffentlichen. Teilweise
Behauptung Etwa 98% der Play-Apps wurden automatisch registriert.
Aktuelle Regel Veraltet. Das Update von Google vom 18. Juni 2026 sagt über 99%. Verifiziert
Wo sich die beiden Google-Seiten zu widersprechen scheinen
Das gehört benannt, denn eine aufmerksame Leserin stößt darauf. Die allgemeine Formulierung in der Hilfe von Google sagt, dass Apps, deren Entwickler die Anforderung nicht erfüllt haben, in den betroffenen Ländern für Neuinstallationen nicht mehr verfügbar sind, was weiter klingt als die auf Stores begrenzte Ausnahme. Die spezifischere FAQ, aktualisiert am 10. August 2026, sagt, dass die Frist zum 30. September nur für die teilnehmenden Stores gilt und die Direktinstallation noch nicht erreicht.
Wie dieser Beitrag das auflöst, und warum das eine Ermessensfrage ist
Redaktionelle Auslegung. Für die erste Phase zum 30. September folgt dieser Beitrag der neueren, szenariospezifischen FAQ-Antwort, weil sie direkte Sideloads und nicht teilnehmende Stores ausdrücklich benennt statt sie nur mitzumeinen, und weil ihre Antwort zum Direkt-Sideload den Stempel 15. Juli 2026 trägt. Der allgemeine Hilfetext beschreibt das Programm als Ganzes. Google hat keine förmliche Regel veröffentlicht, nach der eine Quelle die andere aussticht, das ist also unsere redaktionelle Entscheidung, offen benannt statt versteckt. Die beiden Seiten liest man besser als Beschreibungen verschiedener Ebenen desselben Rollouts denn als Widerspruch. Redaktionelle Auslegung
Vom Symptom zur Lösung: was wirklich nicht stimmt
Suchen Sie den Satz, den Sie oder Ihr Tester tatsächlich gesagt haben. Eine häufige Ursache für eine fehlgeschlagene Installation oder Aktualisierung bei einem Tester ist ein Konflikt der Signaturzertifikate. Das ist gewöhnliches Android-Verhalten, hat mit der Entwicklerverifizierung nichts zu tun und ist ein Jahrzehnt älter als sie.
"Mein Freund kann das APK seit der Verifizierung nicht installieren"
Wahrscheinliche Erklärung. Fast sicher nicht die Entwicklerverifizierung. Vor dem breiteren Rollout 2027 wird eine fehlgeschlagene direkte APK-Installation nicht durch die Regel zum 30. September verursacht, denn diese Regel erfasst den direkten Weg noch gar nicht. Die häufigste echte Ursache ist ein nicht passendes Signaturzertifikat: Auf dem Telefon liegt bereits eine Kopie der App, die mit einem anderen Zertifikat signiert ist.
Sicherste nächste Prüfung, in dieser Reihenfolge. Arbeiten Sie zuerst die gewöhnlichen Android-Installationsfehler ab: eine installierte Kopie mit anderem Zertifikat, ein niedrigerer versionCode als der installierte Build, eine nicht unterstützte Android-Version oder CPU-Architektur, ein abgebrochener oder beschädigter Download, zu wenig Speicher, die fehlende Berechtigung zur Installation aus der App, die die Datei ausliefert, oder eine Play-Protect-Warnung, die der Tester weggeklickt hat. Danach, und nur wenn die Installation über einen teilnehmenden Store läuft oder die breitere Durchsetzung begonnen hat, prüfen Sie Paket- und Signaturschlüsselregistrierung.
Konzept verifiziert
"Firebase meldet, die Installation über meine Play-Version sei fehlgeschlagen"
Wahrscheinliche Erklärung. Ein Tester, der bereits einen von Play signierten Build installiert hat, kann ihn nicht an Ort und Stelle mit einem Firebase-APK aktualisieren, das ein anderes Zertifikat trägt. Entwickler haben genau das berichtet, und Tester verstehen die Fehlermeldung selten.
Sicherste nächste Prüfung. Vergleichen Sie die Signaturzertifikate beider Artefakte. Nutzen Sie entweder einen kompatiblen Signaturweg oder lassen Sie den Tester den alten Build zuerst deinstallieren, was dessen Daten mitnimmt: warnen Sie ihn also vor.
Aus der Community berichtetes Beispiel
"Muss ich 24 Stunden warten, um über ADB zu installieren?"
Antwort. Nein. Google gibt an, dass die 24-Stunden-Wartezeit des erweiterten Ablaufs für ADB-Installationen nicht gilt.
Nächster Schritt. Nutzen Sie den gewohnten ADB-Workflow. Abschnitt 05 enthält die Befehle.
Verifiziert
"Meine nicht registrierte App war schon installiert, lässt sich aber nicht aktualisieren"
Wahrscheinliche Erklärung. Sobald die Durchsetzung für diesen Installationsweg greift, verlangen Aktualisierungen einer nicht registrierten App laut Google den erweiterten Ablauf oder ADB, und eine gewöhnliche Aktualisierung schlägt fehl.
Sicherste nächste Prüfung. Registrieren Sie das Paket ordentlich. In der Zwischenzeit kann der Tester den erweiterten Ablauf aktivieren, oder Sie schieben die Aktualisierung über ADB nach.
Verifiziert
"Ich habe mit 12 Leuten in Firebase getestet, aber Play lässt mich den Produktionszugriff trotzdem nicht beantragen"
Wahrscheinliche Erklärung. Firebase-Tester sind nicht zu einem geschlossenen Test-Track bei Play angemeldet, also zählt nichts von diesem Testen für die Anforderung an den Produktionszugriff.
Sicherste nächste Prüfung. Führen Sie den geschlossenen Test bei Play durch: mindestens 12 infrage kommende Tester, angemeldet und angemeldet bleibend, über 14 aufeinanderfolgende Tage. Die Uhr startet, wenn sie tatsächlich eingetragen sind, nicht, wenn Sie mit dem Testen begonnen haben.
Verifiziert
"Ich hatte 12 Leute im internen Test bei Play, aber die Produktion bleibt gesperrt"
Wahrscheinliche Erklärung. Der interne Test ist nicht der Track, den die Anforderung für den Produktionszugriff benennt. Die Regel verlangt einen geschlossenen Test.
Sicherste nächste Prüfung. Verlegen Sie den zählenden Test auf einen geschlossenen Track bei Play. Der interne Test bleibt daneben für schnelle QA nützlich.
Über die Definition der Regel verifiziert
"Mein Tester hat die Firebase-Einladung nie bekommen oder sagt, der Link sei tot"
Wahrscheinliche Erklärung. Einladungen an Firebase-Tester laufen nach 30 Tagen ab, mit einer Warnung 5 Tage vorher. Wer die E-Mail einen Monat liegen lässt, hat eine abgelaufene Einladung, obwohl der Build selbst noch 150 Tage verfügbar ist.
Sicherste nächste Prüfung. Schicken Sie die Einladung erneut, bevor Sie irgendetwas über Signatur, Verifizierung oder Gerät vermuten. Onboarding-Fehler in App Distribution werden oft als Konto-, Einladungs- oder Installationsquellenprobleme gemeldet und nicht als Probleme mit dem Build.
Verifiziert Aus der Community berichtetes Muster
"Ein Artikel sagt, am 30. September endet jede Direktinstallation"
Wahrscheinliche Erklärung. Er stützt sich auf Beiträge aus 2025 oder dem frühen 2026, die geschrieben wurden, bevor Google den anfänglichen Umfang eingegrenzt hat.
Sicherste nächste Prüfung. Lesen Sie die Verifizierungs-FAQ von Google direkt. Die aktuelle Antwort lautet, dass die Frist zum 30. September für die teilnehmenden Stores gilt und die Direktinstallation noch nicht erfasst.
Korrektur verifiziert
Die Regel, die am meisten Supportzeit spart
Zwei APKs mit demselben Paketnamen, aber ohne verwandte Signaturen, sind nicht austauschbar, und das waren sie nie. Bevor Sie irgendetwas als Problem der Entwicklerverifizierung diagnostizieren, prüfen Sie, ob Sie Android nicht schlicht bitten, eine App durch einen anders signierten Doppelgänger ihrer selbst zu ersetzen. Die Architektur der Verifizierung unterstreicht, warum Signaturidentität zählt, aber dieser Fehler wird leicht mit einem Verifizierungsproblem verwechselt, obwohl er weder neu noch damit verwandt ist.
Was Sie vor dem 30. September wirklich tun sollten
Wenn Sie APKs nur direkt verteilen, setzt die erste Phase zum 30. September die Entwicklerverifizierung auf diesem Weg nicht durch. Das ist vorübergehend, nicht dauerhaft: Google empfiehlt, die Verifizierung vor dem weltweiten Rollout ab 2027 abzuschließen. Wenn Sie bei Google Play veröffentlichen, verlangt er eine Sache: jedes Paket registriert. Und unabhängig von beidem gilt: wenn Ihr Konto der Hürde für den Produktionszugriff unterliegt, ist die Uhr über 14 Tage der Punkt, der über Ihren Starttermin entscheidet, sie sollte also längst laufen.
Tracker vor der Frist
Zwölf Punkte in der Reihenfolge, in der sie wirklich anfallen. Haken Sie unterwegs ab; nichts wird gespeichert, machen Sie es also in einem Zug oder lassen Sie den Tab offen.
0 / 12 erledigt
Noch nichts abgehakt. Klären Sie zuerst, auf welchem Weg Sie sind.
Wann dieser Artikel veraltet
Das ist ein ungewöhnlich verderblicher Artikel, und es wäre unehrlich, ihn als zeitlos darzustellen. Unten stehen die Punkte, die sich am ehesten zuerst ändern, und was jeden von ihnen falsch machen würde.
Der wichtigste Auslöser für eine Aktualisierung auf dieser Seite. Wenn Google die FAQ-Antwort umformuliert, die heute sagt, dass die Direktinstallation noch nicht erfasst ist, ändert sich die ganze erste Hälfte dieses Artikels.
Sieben Stores, vier Länder. Google kann Stores ergänzen oder das Verhalten am Tag selbst präzisieren. Eine Prüfung lohnt sich am 29. September, am Tag selbst und eine Woche danach.
Beide waren für einen weltweiten Start im August 2026 ohne veröffentlichten Tag geplant. Ihr Status kann sich ganz ohne Regeländerung ändern.
Sobald Google Länder oder Termine für 2027 nennt, braucht dieser Artikel eine Ländertabelle, die er heute zu Recht nicht hat.
Die APK- und AAB-Dokumentationen von Firebase entwickeln sich unabhängig voneinander, und die Anforderung von Play mit 12 Testern über 14 Tage steht auf einer Hilfeseite, die Google ohne Ankündigung überarbeitet.
Für diesen Artikel gewählter Aktualisierungstakt: wöchentlich bis zum 30. September 2026, dann am Tag des Inkrafttretens und rund eine Woche danach für Klarstellungen zur Umsetzung, danach monatlich, bis Google einen konkreten Zeitplan für 2027 veröffentlicht. Dieser Takt ist eine redaktionelle Entscheidung auf Basis dessen, wie oft Google dieses Programm 2026 überarbeitet hat, und kein offizieller Zeitplan von Google.
Wo PrimeTestLab hineinpasst und wo nicht
Zuerst die Grenze, denn das ist der ehrliche Teil. PrimeTestLab verifiziert nicht Ihre Identität, registriert nicht Ihre Paketnamen und macht aus einem Firebase-Test keinen geschlossenen Test bei Play. Das bleibt Ihre Aufgabe, und dieser Artikel ist unser gesamter Beitrag dazu. Was wir abdecken, ist die einzige Anforderung auf dieser Seite, die aus Kalenderzeit statt aus Papierkram besteht: 12 echte Tester, über 14 aufeinanderfolgende Tage angemeldet in einem geschlossenen Test-Track bei Play. Google stellt zwar APIs und eine OAuth-Delegation bereit, über die eine autorisierte Plattform einen Entwickler bei der Registrierung unterstützen kann, aber diesen Zugriff müssten Sie selbst erteilen, und die Verantwortung für Konto und App-Identität bleibt bei Ihnen.
Genau diese Unterscheidung hat die Form des Problems, für das dieser Artikel existiert. Ein Entwickler verteilt seine Builds vorbildlich: Firebase-Gruppen, saubere Release-Notes, engagierte Tester, echte Fehlerberichte. Dann öffnet er die Play Console, um den Produktionszugriff zu beantragen, und stellt fest, dass nichts davon gezählt hat. Verteilung ist ein gelöstes Problem. Das Anmeldefenster von 14 Tagen ist der Teil, den Sie nicht durch bessere Organisation verkürzen können.
Den geschlossenen Test selbst durchführen oder abgeben
Google entscheidet über Paketregistrierung, Identitätsverifizierung und Produktionszugriff. Keines der drei ist etwas, das wir für Sie übernehmen. Was ein betreuter Test wegnimmt, ist das Risiko bei Testersuche und Kontinuität, und genau an diesem Schritt bleiben die meisten Erstveröffentlicher tatsächlich hängen. Erfolgsquote über 7.400+ getestete Apps: 99.9%, in 120+ Ländern.
Drei Pläne, eine Zahlung
Starter
12 Tester $19.99 +5% ServicegebührGenau das Minimum von Google, für eine einzelne App, die die Hürde nehmen soll.
Professional
20 Tester $29.99 +5% ServicegebührPuffer über dem Minimum, damit ein einzelner Ausfall den Lauf nicht beendet.
Enterprise
25 Tester $27.99 +5% ServicegebührFür breitere Geräte- und Regionsabdeckung über die 14 Tage.
Jeder Plan setzt echte Tester auf echten Geräten für den vollen Zeitraum von 14 Tagen ein, der Test startet in der Regel in 4-6 Stunden, und wenn ein Test nichts bringt, erhalten Sie einen kostenlosen neuen Test oder eine vollständige Rückerstattung. Die Genehmigung durch Google versprechen wir nicht, denn das kann niemand.
Häufige Fragen
Können meine Freunde nach dem 30. September 2026 noch ein APK installieren, das ich ihnen per E-Mail schicke?
Ja, nach den aktuellen Regeln des ersten Rollouts von Google. Die Frist zum 30. September in Brasilien, Indonesien, Singapur und Thailand gilt für sieben teilnehmende App-Stores, und die FAQ von Google vom 15. Juli 2026 sagt ausdrücklich, dass die Direktinstallation noch nicht erfasst ist. Die weitergehende Anforderung soll 2027 weiterhin weltweit ausgeweitet werden: sehen Sie das also als Grenze einer ersten Phase und nicht als dauerhafte Ausnahme.
Blockiert Google am 30. September jede Direktinstallation in Brasilien, Indonesien, Singapur und Thailand?
Nein, und das ist die wichtigste Korrektur an älteren Berichten. Die anfängliche Durchsetzung beschränkt sich auf Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore und Xiaomi GetApps. Die Direktinstallation und App-Stores außerhalb dieser Liste liegen ausdrücklich außerhalb der ersten Phase. Für die Verteilung außerhalb von Play sagt Google, dass die Durchsetzung in den ausgewählten Regionen zunächst für die Formfaktoren Smartphone und Tablet gilt.
Kann ich APKs nach dem weltweiten Rollout weiterhin direkt installieren?
Für eine App, die ordentlich bei einem verifizierten Entwickler registriert ist, sagt Google, dass sich die gewohnte Installationserfahrung der Nutzer nicht ändern sollte. Für eine nicht verifizierte oder nicht registrierte App hat Google zwei Wege erhalten: ADB und einen erweiterten Ablauf, über den ein Nutzer die Installation bewusst wählen kann. Für diese weitergehende Phase hat Google kein genaues weltweites Datum angekündigt, nur 2027 und danach.
Brauche ich die Android-Entwicklerverifizierung, um ADB zu nutzen?
Nein. Google sagt, dass Entwickler und erfahrene Nutzer weiterhin ADB nutzen können, um nicht verifizierte Apps zu installieren, und dass die 24-Stunden-Wartezeit des erweiterten Ablaufs für ADB nicht gilt. ADB über USB setzt allerdings voraus, dass die Entwickleroptionen und das USB-Debugging auf dem Gerät aktiviert sind: es passt daher weit besser zu Entwicklern und technischen Testern als zu Gelegenheitsnutzern.
Zwingt mich der erweiterte Ablauf bei jedem APK zu 24 Stunden Wartezeit?
Nein. Google beschreibt die 24-Stunden-Verzögerung als Teil der einmaligen Einrichtung des erweiterten Ablaufs. Ist diese Einrichtung abgeschlossen, kann der Nutzer die Installation von Apps nicht verifizierter Entwickler für sieben Tage oder unbefristet zulassen. Google beschreibt die Einrichtung außerdem als einmalig pro Konto, sie wird auf ein neues Gerät übernommen.
Löscht Android eine bereits installierte, nicht verifizierte App?
Die geprüfte Dokumentation von Google sagt nicht, dass vorhandene Kopien automatisch deinstalliert oder am Start gehindert werden. Sie sagt aber, dass eine nicht registrierte App nach dem Inkrafttreten ohne den erweiterten Ablauf oder ADB nicht normal installiert oder aktualisiert werden kann und dass eine gewöhnliche Aktualisierung fehlschlägt. Korrekt beschreibt man das als Einschränkungen bei Installation und Aktualisierung, nicht als Löschung.
Umgeht Firebase App Distribution die Entwicklerverifizierung?
Nein. Firebase ist ein Dienst zur Verteilung von Test-Builds, und eine App bei Firebase zu registrieren ist nicht dasselbe wie die Android-Entwicklerverifizierung, die einen verifizierten Entwickler mit Paketnamen und Signaturschlüsseln verknüpft. Die APK-Verteilung über Firebase sollte außerhalb der anfänglichen Store-Durchsetzung im September bleiben, weil die FAQ von Google sagt, dass die Direktinstallation noch nicht erfasst ist. Das ist allerdings ein Schluss aus der Regel zur Direktinstallation und keine Ausnahme speziell für Firebase: bereiten Sie die Registrierung Ihrer Pakete für den Rollout 2027 trotzdem vor.
Zählen Tester aus Firebase App Distribution für die Anforderung von 12 Testern?
Nein. Google verlangt von betroffenen Konten mindestens 12 Tester, die über die letzten 14 Tage fortlaufend zu einem geschlossenen Test bei Google Play angemeldet waren, bevor der Produktionszugriff beantragt werden kann. Firebase App Distribution ist nützlich, um Fehler zu finden, aber diese Tester sind nicht zu einem geschlossenen Test-Track bei Play angemeldet und erfüllen die Anforderung nicht.
Zählt der interne Test bei Play für die 12 Tester?
Nein, der interne Test ersetzt den verlangten geschlossenen Test nicht. Google erlaubt bis zu 100 Tester in einem internen Test, aber die Anforderung für den Produktionszugriff nennt ausdrücklich, dass die zählenden Tester über 14 aufeinanderfolgende Tage zu einem geschlossenen Test angemeldet gewesen sein müssen. Der interne Test bleibt daneben für schnelle Qualitätssicherung nützlich.
Ich habe meine Identität bereits verifiziert. Ist damit jedes APK, das ich baue, automatisch in Ordnung?
Gehen Sie davon nicht aus. Zur Android-Entwicklerverifizierung gehört auch, den Paketnamen und seinen Signaturschlüssel oder seine Signaturschlüssel zu registrieren, und Google erlaubt es, mehrere Signaturschlüssel für ein Paket hinzuzufügen und zu verifizieren. Das ist vor allem dann wichtig, wenn QA- oder Debug-Builds und Release-Builds unterschiedliche Signaturzertifikate nutzen, ein völlig normaler Aufbau, den die Identitätsverifizierung allein nicht abdeckt.
Bedeutet die Verifizierung, dass mein direkt installiertes APK jetzt jede Richtlinie von Google Play einhalten muss?
Die Verifizierungsdokumentation von Google beschreibt eine Identitätsbestätigung und die Registrierung von Paketen, keine Ausweitung sämtlicher Veröffentlichungsrichtlinien von Play auf jede direkte Verteilung. Google unterscheidet außerdem zwischen der Prüfung, wer ein Entwickler ist, und der Sicherheitsprüfung der App-Inhalte. Eine Identität festzustellen ist nicht dasselbe wie das Freigeben dessen, was Sie ausgeliefert haben: behandeln Sie die Verteilung außerhalb von Play daher nicht wie eine Prüfung im Play Store.
Fazit
Zusammenfassung
Stand 13. August 2026 können Tester ein rohes APK, das Sie direkt teilen, weiterhin installieren. Die Durchsetzung ab dem 30. September 2026 in Brasilien, Indonesien, Singapur und Thailand gilt zunächst nur für sieben teilnehmende App-Stores, und die FAQ von Google vom 15. Juli sagt, dass die Direktinstallation noch nicht erfasst ist. Google plant eine weitergehende Durchsetzung auf zertifizierten Geräten ab Android 7 im Jahr 2027, ohne ein genaues weltweites Datum zu nennen. Sobald das greift, behalten Apps, die bei einem verifizierten Entwickler registriert sind, den gewohnten Weg der Direktinstallation, während nicht registrierte Apps weiterhin über ADB installiert werden können, wo keine 24-Stunden-Wartezeit gilt, oder über den erweiterten Ablauf von Google, dessen 24-Stunden-Verzögerung ein einmaliger Einrichtungsschritt ist. Firebase App Distribution bleibt ein starker QA-Kanal, führt aber keine Android-Entwicklerverifizierung durch, verhält sich bei APK und AAB unterschiedlich und ist nicht der geschlossene Test bei Google Play, der 12 angemeldete Tester über 14 aufeinanderfolgende Tage verlangt. Wenn genau dieser Testschritt Ihren Start blockiert, liefert PrimeTestLab 12 echte Tester ab $19.99 plus 5% Servicegebühr. Preispläne ansehen →
Primärquellen für diesen Artikel
Letzte Richtlinienprüfung: 13. August 2026. Die FAQ-Seite von Google zur Entwicklerverifizierung wurde zuletzt am 10. August 2026 aktualisiert, die dortige Antwort zum direkten Sideload datiert vom 15. Juli 2026, und die Android-Dokumentation von Firebase App Distribution wurde zuletzt am 11. August 2026 aktualisiert. Die Android-Entwicklerverifizierung wird aktiv ausgerollt: der Umfang zum 30. September, die Liste der teilnehmenden Stores, die Verfügbarkeit des erweiterten Ablaufs und der Zeitplan für 2027 sollten alle auf den Seiten von Google nachgeprüft werden, bevor Sie danach handeln. Für diesen Artikel ist eine erneute Prüfung wöchentlich bis zum 30. September 2026 vorgesehen, dann am Tag des Inkrafttretens und rund eine Woche danach, und anschließend monatlich, bis Google eine konkrete Geografie oder ein konkretes Datum für 2027 veröffentlicht.