Nein: es setzt nie zurück
Ein gewöhnliches Update lässt die Anmeldezeit Ihrer Tester weiterlaufenGoogle veröffentlicht keine Regel, nach der ein neuer Release den geschlossenen Test neu startet. Die Anforderung betrifft jeden einzelnen Tester, der 14 Tage fortlaufend angemeldet bleibt, mit mindestens 12 solchen Testern zum Zeitpunkt Ihres Antrags. Ihr Versionscode und die Anzahl der hochgeladenen Builds gehören nicht dazu.
Tester verlassen den Test, sodass weniger als 12 auf 14 lückenlose Tage kommen.
Ein Tester, der sich abmeldet und wieder beitritt, beginnt seine eigenen 14 Tage von vorn, und ein Ersatztester beginnt bei Tag eins. Wenn dadurch weniger als 12 Tester mit 14 lückenlosen Tagen übrig bleiben, muss Ihr Antrag warten. Die Ursache ist nicht das Update.
Kurze Antwort
Nein. Ein Update derselben App in ihrem laufenden Track des geschlossenen Tests startet die Anmeldezeit Ihrer Tester nicht von selbst neu. Für private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, braucht die App mindestens 12 Tester, die jeweils über die letzten 14 aufeinanderfolgenden Tage angemeldet geblieben sind, wenn Sie den Produktionszugriff beantragen. Ein Tester, der sich abmeldet, beginnt seine eigenen 14 Tage von vorn. Google empfiehlt, auf Feedback zu reagieren, veröffentlicht aber keine erforderliche Anzahl an Releases. Wenn Tester einen neuen Build nicht sehen, prüfen Sie die Veröffentlichung, die Rollout-Berechtigung und die Aktualisierung auf dem Gerät.
Es ist eine der häufigsten Ängste im geschlossenen Test (closed testing): Sie sind mitten im 14-Tage-Fenster, entdecken einen Bug und erstarren, aus Angst, dass ein Fix-Upload Ihren Fortschritt löscht und Sie die zwei Wochen von vorn beginnen müssen. Das passiert nicht. Die 14-Tage-Anforderung beobachtet Ihre Tester, nicht Ihre Builds. Dieser Leitfaden trennt, was das Fenster des geschlossenen Tests unterbricht und was nicht, gibt Ihnen zwei interaktive Tools, um jede Aktion selbst zu prüfen, und erklärt, was Sie prüfen sollten, wenn Tester einen neuen Build nicht sehen. Zuletzt mit Googles Hilfeseiten abgeglichen am 16. Oktober 2026.
In diesem Leitfaden
Setzt ein App-Update den 14-Tage-Zähler des geschlossenen Tests zurück?
Nein. Das ist die häufigste Sorge von Entwicklern im Testfenster, und die Antwort ist beruhigend: Ein neues App Bundle in Ihren bestehenden Track des geschlossenen Tests hochzuladen, startet die Anmeldezeit Ihrer Tester nicht von selbst neu.
Die 14-Tage-Anforderung hängt an Ihren Testern, nicht an Ihrem Build. Google misst sie pro Tester: Wenn Sie den Produktionszugriff beantragen, müssen mindestens 12 Tester jeweils über die letzten 14 Tage fortlaufend angemeldet gewesen sein. Die Versionsnummer Ihrer App, wie oft Sie ein neues AAB hochladen und was Sie in den Release Notes ändern, sind nicht Teil dieser Anforderung.
Genau diese Frage taucht in der Google Play Developer Community immer wieder auf. Googles Play Console-Hilfe definiert die Anforderung rein über angemeldete Tester und Zeit, nie über Build-Uploads. Ein Google Product Expert hat im Januar 2024 in einer akzeptierten Community-Antwort die praktische Antwort direkt gegeben: Ein Update während des Tests muss unter Umständen überprüft werden, setzt die 14 Tage aber nicht zurück. Das ist die Lesart eines Experten, kein Satz aus der Richtlinie selbst.
Unsicher bei einer bestimmten Aktion? Nutzen Sie den Checker unten: Wählen Sie, was Sie vorhaben, und er sagt Ihnen, ob es die 14 Tage Ihrer Tester berührt.
Welche Aktion bereitet Ihnen Sorgen?
Basierend auf Googles veröffentlichter Play Console-Anforderung (angemeldete Tester × fortlaufende Tage) plus weit berichteter Entwicklererfahrung. Die zwei community-markierten Risiken sind entsprechend gekennzeichnet.
Was setzt den 14-Tage-Timer wirklich zurück?
Das fortlaufende 14-Tage-Fenster versteht man am besten als Konsistenzprüfung, nicht als passiven Kalendercountdown. Google will sehen, dass Sie mindestens 12 angemeldete Tester ohne Unterbrechung gehalten haben. Es gibt nur zwei bestätigte Auslöser, die diese Kontinuität brechen:
Angemeldete Zahl fällt unter 12
Wenn ein Tester geht und Sie auf 11 qualifizierte Tester fallen, können Sie erst beantragen, wenn ein zwölfter Tester 14 lückenlose Tage hat, und ein Ersatztester beginnt bei Tag eins. Deshalb ist es riskant, mit genau 12 zu arbeiten.
Tester melden sich formell ab
Ein Tester meldet sich ab, indem er den Testlink im Web öffnet und den Test verlässt. Das ist etwas anderes als Deinstallieren. Die eigenen 14 Tage dieses Testers stoppen, und wenn er wieder beitritt, beginnen sie von vorn. Ihren Antrag verzögert das nur, wenn dadurch weniger als 12 qualifizierte Tester übrig bleiben.
Einen neuen Build hochzuladen steht nicht auf dieser Liste. Ebenso wenig ein Tippfehler im Store-Listing, Feedback eines Testers oder ein Crash auf dem Gerät eines Testers: letzteres ist der ganze Sinn des Tests. Der Simulator unten macht den Unterschied klar: drücken Sie den Update-Button so oft Sie wollen und nichts bewegt sich; verlieren Sie Tester unter 12 und die Serie bricht zusammen.
Was den Zähler NICHT zurücksetzt
Neues AAB auf denselben Track hochladen
Release Notes oder Store-Listing bearbeiten
Ein Tester sendet Feedback
Ihre App stürzt auf dem Gerät eines Testers ab
versionCode oder Versionsname erhöhen
Ein Tester deinstalliert ohne Abmeldung
Wie pushe ich ein Update in einen geschlossenen Test?
Ein Update zu pushen ist derselbe Ablauf wie bei Ihrem allerersten Release, mit einem wichtigen Unterschied: Sie erstellen den neuen Release auf dem selben Test-Track des geschlossenen Tests, in den Ihre Tester bereits angemeldet sind. Sie starten keinen neuen Test, Sie fügen dem laufenden Test einen Build hinzu, und genau deshalb läuft der 14-Tage-Zähler weiter. Hier die zwei Schritte in der Play Console.
Neuen Release auf Ihrem Track des geschlossenen Tests erstellen Test and release > Testing > Closed testing > Manage track
Öffnen Sie den Track des geschlossenen Tests, den Sie laufen lassen, klicken Sie auf Create new release und laden Sie Ihr aktualisiertes App Bundle (AAB) hoch. Behalten Sie denselben Paketnamen und dieselbe Signatur-Einrichtung bei und geben Sie dem Build einen höheren versionCode: Nur den versionName zu ändern, ist kein Upgrade. Fügen Sie kurze Release Notes hinzu, was sich geändert hat, und speichern Sie. Bleiben Sie auf demselben Track: Das hält die 14 Tage Ihrer Tester am Laufen.
Update prüfen und ausrollen Review release > Start roll-out
Gehen Sie über Next und Review release und starten Sie dann den Roll-out auf Ihren Track des geschlossenen Tests. Öffnen Sie anschließend die Publishing overview: Wenn Änderungen warten, wählen Sie Send changes for review, und wenn die verwaltete Veröffentlichung aktiv ist, veröffentlichen Sie die genehmigten Änderungen selbst. Ein eingereichtes Update kann In review anzeigen, bevor Tester es erhalten, und Google merkt an, dass eine veröffentlichte Änderung mehrere Stunden brauchen kann, bis sie Tester erreicht. Bestehende Tester aktualisieren normalerweise direkt, ohne Neuinstallation und ohne zweite Anmeldung.
Das startet die Anmeldezeit Ihrer Tester nicht neu. Weil Sie auf denselben Track des geschlossenen Tests veröffentlichen, für den Ihre Tester bereits angemeldet sind, laufen ihre 14 Tage unter dem neuen Build weiter. Sie fügen einen Build hinzu, Sie starten keinen neuen Test. Wenn Tester den neuen Build trotzdem nicht sehen, gehen Sie die Prüfungen im nächsten Abschnitt durch.
Warum erhalten Tester den neuen Build nicht?
Prüfen Sie zuerst, ob der vorgesehene Build im Test-Track des Testers veröffentlicht ist, dann das Konto des Testers und die installierte Version, und erst danach das Smartphone. Das ist eine Reihenfolge der Prüfungen, keine Rangliste der häufigsten Ursachen. Fertig sind Sie, wenn ein berechtigter Tester den vorgesehenen Build installiert und die Änderung erneut getestet hat; ein neues Datum im Store-Eintrag reicht nicht.
Mein Update ist noch in der Überprüfung
Ein eingereichtes Update muss unter Umständen überprüft werden, bevor dieser Build die Tester erreicht. Öffnen Sie in der Play Console die Publishing overview (Veröffentlichungsübersicht) und handeln Sie nach dem, was dort steht:
- Changes not yet sent (noch nicht gesendete Änderungen): Prüfen Sie die Liste und wählen Sie Send changes for review.
- In review (in Überprüfung): Bestätigen Sie, dass es die richtige App, der richtige Track und die richtige Version ist, und folgen Sie allen Hinweisen in der Console. Laden Sie keinen weiteren Build hoch, nur um den Status aufzufrischen; Google rechnet die Überprüfungszeit ab der zuletzt eingereichten Änderung.
- Changes ready to publish (zur Veröffentlichung bereite Änderungen): Die verwaltete Veröffentlichung (Managed publishing) ist aktiv, also veröffentlichen Sie die genehmigten Änderungen selbst.
Ein Release, der auf die Überprüfung wartet, und Tester, die angemeldet bleiben, sind zwei getrennte Zustände. Google dokumentiert nicht, dass die Überprüfung eines gewöhnlichen Updates die Anmeldezeit Ihrer Tester pausiert oder zurücksetzt.
Nur manche Tester können aktualisieren
Ein veröffentlichtes Update erreicht nur die Tester, für die es ausgerollt wird und die dafür berechtigt sind. Prüfen Sie Folgendes der Reihe nach:
- Gestaffelter Rollout: Updates in Test-Tracks, auch im geschlossenen Test, können einen Rollout-Prozentsatz nutzen, und dieser steigt nicht von selbst. Öffnen Sie unter Closed testing > Releases die Option Manage rollout, um den Prozentsatz zu sehen und ob der Rollout angehalten ist.
- Konto: Die Adresse auf Ihrer Liste oder in Ihrer Google Group, das Konto, das sich angemeldet hat, und das im Play Store angemeldete Konto müssen identisch sein.
- Interner Test: Ein Tester, der noch für Ihren internen Test angemeldet ist, ist für Builds des geschlossenen Tests nicht berechtigt, bis er den internen Test verlässt und sich für den geschlossenen anmeldet. Das ist eine Reparatur der Anmeldung, kein routinemäßiger Update-Schritt.
- Versionscode: Google Play installiert den höchsten kompatiblen versionCode, für den der Tester berechtigt ist. Nur den versionName zu ändern, ist kein Upgrade.
- Gerät: Der Build muss das Gerät des Testers unterstützen, und Ihre Vertriebseinstellungen müssen es einschließen.
Der Release ist verfügbar, aber auf dem Smartphone ist noch der alte Build
Nutzen Sie den Update-Weg des Play Store selbst, bevor Sie die Anmeldung des Testers anfassen:
- Öffnen Sie den Play-Eintrag der App über Ihren Testlink und tippen Sie auf Aktualisieren, falls die Schaltfläche angezeigt wird, oder gehen Sie zu Ihrem Profil > Apps und Gerät verwalten > Updates verfügbar.
- Prüfen Sie die automatische Aktualisierung: Sie kann ausgeschaltet, auf WLAN beschränkt oder für genau diese App deaktiviert sein.
- Prüfen Sie die Verbindung und den freien Speicherplatz, schließen Sie dann den Play Store und öffnen Sie ihn erneut.
- Leeren Sie erst danach den Cache des Play Store (App-Info > Speicher und Cache > Cache leeren). Das Leeren des Cache kann keinen Release veröffentlichen, der sich noch in der Überprüfung befindet.
Bitten Sie Tester nicht, den Test zu verlassen und wieder beizutreten, um ein Update zu bekommen. Das Verlassen unterbricht die 14 lückenlosen Tage dieses Testers. Die App zu deinstallieren, die Daten der Google Play-Dienste zu löschen oder das Smartphone zurückzusetzen, gehört ebenfalls nicht zu einem normalen Update.
Was ist der Unterschied zwischen eingeladenen und angemeldeten Testern?
Über diese Unterscheidung stolpern mehr Erstveröffentlicher als über jede andere, und sie ist der Schlüssel dazu, warum Builds für den Zähler irrelevant sind. Googles System führt Tester durch einen Trichter, und nur die späteren Stufen zählen.
Eingeladen
Sie haben eine E-Mail-Adresse zu Ihrer Testerliste oder Google Group hinzugefügt. Mehr ist noch nicht passiert.
Angemeldet
Sie haben Ihren Link zum Teilen geöffnet, sich mit ihrem Google-Konto angemeldet und „Betatester werden“ gewählt. Das ist der Status, den der 14-Tage-Zähler misst.
Installiert und aktiv
Sie haben die App heruntergeladen und nutzen sie weiter. Das ändert die Rohzahl nicht, aber genau das gewichtet Google für Engagement beim Produktionszugriff.
Wie Googles Dokumentation klarstellt, reicht es nicht, eine E-Mail-Adresse hinzuzufügen. Jeder Tester muss den Link zum Teilen öffnen, sich authentifizieren und ausdrücklich Tester werden, bevor er zählt. Deshalb startet ein gewöhnliches App-Update Ihren Fortschritt auch nicht neu: Ihre Tester bleiben angemeldet, also zählen ihre Tage über neue Builds hinweg weiter. Den vollständigen Ablauf finden Sie in unserem Leitfaden, wie Sie Tester korrekt einladen.
Tipp aus Tausenden betreuten Tests: Führen Sie Ihre Tester über eine Google Group statt über eine statische E-Mail-Liste. Google dokumentiert, dass das Hochladen einer CSV-Datei die bisherige Testerliste überschreibt. Mit einer Group vermeiden Sie also, beim Anpassen versehentlich aktive Tester zu löschen. Eine Group ist allerdings keine Garantie: Die Mitgliedschaft steuert weiterhin den Zugriff, wer also jemanden aus der Group entfernt oder eine andere Group verknüpft, ändert, wer berechtigt ist.
Wie lautet die exakte Google-Anforderungsformulierung?
Googles offizielle Play Console-Hilfeseite „Anforderungen an App-Tests für neue private Entwicklerkonten“ formuliert es präzise:
„Wenn Sie ein neu erstelltes privates Entwicklerkonto haben, müssen Sie einen geschlossenen Test für Ihre App mit mindestens 12 Testern durchführen, die mindestens während der letzten 14 Tage fortlaufend angemeldet waren.“
Google Play Console Help · Antwort 14151465Und separat, im Moment, in dem Sie Produktionszugriff beantragen:
„Mindestens 12 Tester müssen an Ihrem geschlossenen Test teilnehmen, wenn Sie den Produktionszugriff beantragen. Diese Tester müssen außerdem über die letzten 14 Tage fortlaufend angemeldet gewesen sein.“
Google Play Console Help · Antwort 14151465Google stellt in eigenen Worten auch klar, dass die Tage aufeinanderfolgen müssen: es zählt keine Tester, die sich angemeldet, weniger als 14 Tage getestet und sich dann abgemeldet haben, und selbst wenn sie sich wieder anmelden, müssen die 14 Tage aufeinanderfolgen, um zu zählen. Diese eine Klausel widerlegt den Mythos „14 Tage sind kumulativ“ allein, und genauso wichtig: sie sagt nichts über Ihre Builds.
Drei Fakten zum Merken
Sind Updates während des Tests gut oder schlecht?
Hier dreht sich Entwicklerangst in Chance. Updates während Ihres geschlossenen Tests zu pushen gilt weithin als positives Engagement-Signal. Es lohnt sich, zu trennen, was Google offiziell sagt und was die Entwickler-Community geschlossen hat, weil sich beides überschneidet, ohne identisch zu sein:
Weiter iterieren und fixen
Die Play Console-Hilfe ermutigt zu laufender Iteration: nutzen Sie den geschlossenen Test weiter, während Sie von Nutzern gemeldete Probleme und Bugs beheben, und Ihre App im geschlossenen Test zu aktualisieren, bevor Sie in die Produktion gehen, ist „eine gute Möglichkeit, schlechte Bewertungen und Rezensionen zu minimieren.“
Wenn Sie Produktionszugriff beantragen, fragt der Fragebogen, welches Engagement Sie erhalten haben und was Sie mit dem Feedback der Tester gemacht haben.
Aktiv schlägt eingefroren
Praktiker gehen weiter: Eine App, die 14 Tage lang ohne jede Aktivität auf Version 1.0 steht, wirkt wie abgehaktes Testen, während eine App, die als Reaktion auf Feedback Fixes veröffentlicht, nach echter Entwicklung aussieht. Manche Entwickler veröffentlichen zwei oder drei kleine Updates, um Reaktionsfähigkeit zu zeigen, aber Google veröffentlicht keine solche Quote (siehe den Abschnitt zur Anzahl der Releases weiter unten).
Das ist Community-Meinung und eine vernünftige Schlussfolgerung, keine veröffentlichte Google-Regel. Google hat keine numerische Anforderung „X Updates veröffentlichen“ festgelegt.
Das Fazit: Updaten ist sicher und erwünscht, und die Engagement-Story, die Sie damit bauen, kann Ihnen helfen, den Fragebogen zum Produktionszugriff zu beantworten. Das einzige echte Risiko kommt von dem, was Sie ausliefern, nicht vom Akt des Auslieferns: das führt zum einen echten Vorbehalt.
Brauche ich während des geschlossenen Tests zwei oder drei Releases?
Googles veröffentlichte Hinweise zum geschlossenen Test legen keine Mindestanzahl an Releases fest. Google empfiehlt, auf das Feedback der Tester zu reagieren und die Probleme zu beheben, die der Test aufdeckt, und im Antrag auf Produktionszugriff sollen Sie alle vorgenommenen Änderungen beschreiben. Eine Anzahl von Uploads ist nicht Teil der Anforderung.
- Mindestens 12 Tester 14 Tage ohne Unterbrechung angemeldet halten (veröffentlichte Anforderung)
Schützen Sie die lückenlose Anmeldung jedes Testers vom ersten Tag an. - Auf Feedback reagieren und die Probleme beheben, die der Test aufdeckt (Hinweis von Google)
Halten Sie kurz fest: das Feedback, den Fix und den erneuten Test. - Auf jeden Fall zwei oder drei Releases veröffentlichen (Community-Folklore, keine veröffentlichte Quote)
Erfinden Sie keine Änderungen, und erwarten Sie nicht, dass eine bestimmte Anzahl an Releases die Genehmigung bringt.
Woher der Rat stammt: Die früheste ausdrückliche Fassung, die wir gefunden haben, ist die Vermutung eines Entwicklers in einer Diskussion vom Oktober 2024, dass zwei oder drei Updates Google feedbackgetriebene Arbeit zeigen könnten. Innerhalb weniger Wochen wurde sie in Community-Threads wiederholt und tauchte später in Anleitungen auf, als wäre sie eine Empfehlung von Google. Die ursprüngliche Quelle ist unbekannt, und Entwickler berichten von Ablehnungen sowohl mit als auch ohne mehrere Updates. Eine Anzahl an Releases beweist für sich genommen also nichts.
Wenn der Test ein echtes Problem aufdeckt, beheben Sie es, veröffentlichen Sie den Build und bitten Sie die Tester, erneut zu testen. Wenn nicht, sagen Sie das ehrlich, wenn Sie den Fragebogen zum Produktionszugriff beantworten. Kosmetische Builds hochzuladen, während ein Update in der Überprüfung ist, kann Ihre App außerdem in der Warteschlange der Überprüfung zurückwerfen, weil Google die Überprüfungszeit ab der zuletzt eingereichten Änderung rechnet.
Kann ein schlechtes Update meinen Zähler indirekt zurücksetzen?
Ja: und das ist der eine Vorbehalt, der zählt. Während der Akt des Updatens den Timer nie direkt zurücksetzt, können die Folgen eines kaputten Updates das tun. Folgen Sie der Kette:
Die Regel ist also einfach: updaten Sie frei, aber prüfen Sie jeden Build auf Basisstabilität, bevor Sie ihn auf Ihren Track des geschlossenen Tests pushen. Und laufen Sie nie mit genau 12 Testern, weil eine einzige Abmeldung nach einem schlechten Build Sie versenken kann. Ein Puffer an Testern über 12 absorbiert dieses Risiko.
Lesen Sie die Kette sorgfältig: Das Update startet die Anmeldezeit von niemandem neu. Die Verzögerung entsteht durch den Verlust qualifizierter Tester; der kaputte Build ist nur das, was die Abmeldungen ausgelöst hat. Halten Sie Ihre Builds stabil und halten Sie einen Puffer, dann wird auch das indirekte Risiko deutlich kleiner.
Müssen Tester nach einem Update neu installieren oder sich neu anmelden?
Nein. Bestehende Tester, die sich angemeldet und Ihre App installiert haben, aktualisieren sie normalerweise direkt über Google Play. Sie müssen sich nicht erneut anmelden, und Sie müssen den Link nicht erneut senden.
Updates werden normalerweise direkt installiert
Googles Play Console-Hilfe stellt in Offenen, geschlossenen oder internen Test einrichten (Antwort 9845334) klar: „Sobald Ihre Tester Ihre App installiert haben, werden sie innerhalb weniger Minuten automatisch auf die Testversion aktualisiert.“ Tester bleiben über jeden Build angemeldet: keine Neuinstallation, kein zweiter Klick auf den Link zum Teilen.
Ein Timing-Hinweis von derselben Google-Seite: wenn Sie zusätzliche Änderungen veröffentlichen, „stehen sie Testern möglicherweise mehrere Stunden nicht zur Verfügung“, bevor das automatische On-Device-Update greift. Aber der angemeldete Status der Tester, den der 14-Tage-Zähler misst, bleibt über jedes neue AAB erhalten. Genau deshalb setzt ein Build-Update den Zähler nicht zurück: die Tester sind nie gegangen.
Wichtige Ausnahme Neue Berechtigungen können das stille Update unterbrechen
Eine Art Build rollt nicht immer still aus: ein Update, das eine neue gefährliche (sensible) Berechtigung hinzufügt, etwa ACCESS_FINE_LOCATION, Kamera oder Mikrofon. Je nach Berechtigung und Target-API-Level kann Google Play eine Aktualisieren-Aufforderung zeigen, die der Tester manuell tippen und bestätigen muss, statt sie im Hintergrund zu installieren, und wer sie ignoriert, bleibt auf dem alten Build. Selbst wenn es still installiert, wird die neue Berechtigung erst zur Laufzeit gewährt, sodass eine berechtigungsgeschützte Funktion kaputt wirken kann, bis der Tester sie erlaubt.
Im geschlossenen Test ist das eine stille Falle: Wenn Sie mitten im Test ein Update mit vielen Berechtigungen veröffentlichen, bleiben manche Tester womöglich auf dem alten Build oder finden eine Funktion blockiert, bis sie die Berechtigung erteilen. Eine neue Hochrisiko-Berechtigung kann außerdem eine Berechtigungserklärung in der Play Console erfordern, bevor der Build überhaupt veröffentlicht werden kann. Die Zustimmung zur Laufzeit auf dem Smartphone und die Erklärung in der Console sind getrennte Prüfungen.
Bevor Sie mitten im Test ausrollen: vergleichen Sie die Berechtigungen Ihres neuen Manifests mit dem Live-Build. Hat sich der Berechtigungssatz geändert, bitten Sie Ihre Tester, den Play Store zu öffnen und manuell zu aktualisieren (und die neue Aufforderung zu gewähren), und planen Sie eine mögliche Erklärung-Überprüfung ein.
Häufige Mythen zum geschlossenen Test, entlarvt
Der meiste Panik ums Updaten läuft auf eine Handvoll Mythen hinaus. Hier die fünf, die Entwickler am meisten Schlaf kosten, mit dem, was wirklich gilt:
Mythos 1„Einen neuen Release zu erstellen setzt den Zähler zurück.“
Mythos 2„Deinstallieren ist dasselbe wie Abmelden.“
Mythos 3„Die 14 Tage sind kumulativ.“
Mythos 4„Genau 12 Tester reichen.“
Mythos 5„Tester müssen die App jeden einzelnen Tag nutzen.“
Was setzt den Zähler zurück und was nicht
Hier die ganze Frage auf einem Bildschirm. Speichern, screenshotten oder an alle im Team schicken, die weiter fragen. Alles, was an Ihren Build gebunden ist, ist sicher; nur was an Ihre Testerzahl gebunden ist, ist es nicht.
| Aktion | Setzt den 14-Tage-Zähler zurück? |
|---|---|
| Neues AAB auf denselben Track des geschlossenen Tests hochladen | Nein |
| Release Notes oder Store-Listing-Metadaten bearbeiten | Nein |
| Ein Tester sendet Feedback | Nein |
| Ihre App stürzt auf dem Gerät eines Testers ab | Nein |
| Ein Tester deinstalliert (ohne Abmeldung) | Nein* |
| Angemeldete Testerzahl fällt unter 12 | Ja |
| Ein Tester meldet sich formell über den Web-Link ab | Ja** |
| Kaputten Build pushen, der Abmeldungen unter 12 treibt | Indirekt |
| Track des geschlossenen Tests pausieren | Gemeldetes Risiko |
| Testerliste überschreiben und aktive Tester auslassen | Gemeldetes Risiko |
* Keine Abmeldung, aber ein Tester ohne installierte App testet sie nicht. ** Nur wenn dadurch weniger als 12 qualifizierte Tester übrig bleiben. „Ja“ bedeutet hier, dass sich Ihr frühestmöglicher Antragstermin verschiebt: Tester, die geblieben sind, behalten ihre Tage, aber ein Ersatztester beginnt bei Tag eins. Google dokumentiert, dass ein CSV-Upload die bisherige Liste überschreibt und dass das Pausieren eines Tests dessen Updates stoppt; wie die Tage danach gezählt werden, ist nicht dokumentiert. Behandeln Sie die letzten zwei Zeilen also als „nicht riskieren“.
Wie sich die Anforderung im Laufe der Zeit geändert hat
Wenn Sie ältere Tutorials lesen, liegt hier der Grund, warum die Zahlen nicht passen. Die Dauer war immer 14 fortlaufende Tage; nur die Testerzahl hat sich bewegt.
Vor November 2023 gab es keinen erforderlichen geschlossenen Test, um in die Produktion zu gelangen. Sie konnten ohne Tester-Rekrutierung veröffentlichen.
Google kündigte die Anforderung am 9. November 2023 an. Private Konten, die nach dem 13. November 2023 erstellt wurden, mussten einen geschlossenen Test mit 20 angemeldeten Testern über 14 fortlaufende Tage durchführen. Organisationskonten waren ausgenommen.
Am 11. Dezember 2024 fiel das Minimum von 20 auf 12, die 14-Tage-Dauer blieb unverändert. Organisationskonten bleiben ausgenommen.
Jeder Leitfaden, der Ihnen noch rät, 20 Tester zu rekrutieren, ist veraltet. Den Wechsel behandeln wir ausführlich unter was sich von 20 zu 12 Testern geändert hat.
Richtlinienänderungen 2026, die Sie kennen sollten
Der geschlossene Test existiert nicht im Vakuum. Einige Fristen 2026 können mit Ihrem Launch-Zeitplan kollidieren: keine ändert, wie der 14-Tage-Zähler funktioniert, aber sie können mit Ihrem Fenster kollidieren, wenn Sie den Kalender nicht im Blick haben:
Fristen 2026, die Ihren Zeitplan kreuzen
Daten laut Google Play Console Help (Target API Level) und Android Developers Blog (Developer Verification). Der Verifizierungszeitplan ist gestaffelt und kann sich 2026-2027 erweitern: prüfen Sie die offiziellen Seiten, bevor Sie danach planen. Unser Leitfaden zu den Veröffentlichungsanforderungen 2026 führt die volle Liste.
Wie PrimeTestLab Ihren Zähler am Laufen hält
Der schwerste Teil des geschlossenen Tests ist nicht, die Regeln zu verstehen; es ist, 12 oder mehr echte Menschen 14 ununterbrochene Tage angemeldet und engagiert zu halten, während Sie iterieren. Genau dafür ist PrimeTestLab gebaut. Wir stellen Tester auf echten Geräten bereit, die angemeldet sind, und führen Sie durch die Play Console-Einrichtung, damit der Zähler sauber startet und weiterläuft, während Sie Fixes ausliefern. Den vollen Service für den geschlossenen Test bei Google Play finden Sie dort. Wir halten eine Erfolgsquote von 99.9% bei über 12.100+ Apps, mit Teststart in 4-6 Stunden.
Sie fügen unsere Tester in der Play Console hinzu, teilen Ihre Test-URL, und die 14 Tage beginnen. Danach können Sie Updates veröffentlichen, wenn Sie sie brauchen; die Tester bleiben angemeldet, während Sie weiterentwickeln.
Ein Plan über dem Minimum von 12 Testern gibt Ihnen zusätzliche Tester, die am selben Tag starten. So bringt Sie eine einzelne Abmeldung, auch eine durch einen schlechten Build, nicht unter 12. Ein Puffer hilft nur, wenn diese Tester sich früh anmelden: Ein später Ersatztester beginnt seine eigenen 14 Tage. Die Preise gelten pro App, plus 5% Servicegebühr (mindestens $1.50) an der Kasse.
Häufig gestellte Fragen
Kann ich meine App im geschlossenen Test aktualisieren, ohne die 14 Tage neu zu starten?
Ja. Ein gewöhnliches Update derselben App in ihrem laufenden geschlossenen Track startet die Anmeldezeit der Tester nicht von selbst neu. Halten Sie Ihre bestehenden Tester berechtigt und angemeldet. Der neue Build muss unter Umständen trotzdem überprüft und veröffentlicht werden, bevor Tester ihn installieren können. Prüfen Sie die Auslieferung also getrennt von der Testanforderung.
Was setzt den Zähler des geschlossenen Tests als Einziges zurück?
Google veröffentlicht keine Reset-Checkliste, die jede Aktion in der Console abdeckt. Die Anforderung betrifft die fortlaufende Anmeldung jedes einzelnen Testers. Ein Tester, der sich abmeldet und wieder beitritt, beginnt seine eigenen 14 Tage von vorn, und wenn Sie genug qualifizierte Tester verlieren, kann sich Ihr Antrag verzögern. Ein neuer Ersatztester beginnt bei Tag eins. Ein gewöhnliches Build-Update ist ein anderes Ereignis.
Was ist der Unterschied zwischen eingeladenen und angemeldeten Testern?
Eingeladen heißt, das Konto steht auf Ihrer Testerliste oder ist in Ihrer Google Group. Angemeldet heißt, der Tester hat den Testlink mit diesem Konto geöffnet und ist dem Test beigetreten. Eine Adresse nur einzutragen, schließt die Anmeldung nicht ab. Bitten Sie Tester, das Konto zu bestätigen, dann die App zu installieren, sie zu nutzen und aussagekräftiges Feedback zu senden.
Müssen sich Tester nach einem Update erneut anmelden?
Normalerweise nicht. Bestehende berechtigte Tester erhalten ein gewöhnliches Update über Google Play, ohne demselben Test erneut beizutreten. Lassen Sie ihre Anmeldung unangetastet und bitten Sie sie dann, den Eintrag und den installierten Build zu prüfen. Die automatische Installation hängt davon ab, dass der Release verfügbar ist, und von den Geräteeinstellungen. Versprechen Sie also nicht jedem Tester das Update innerhalb von Minuten.
Ist Deinstallieren dasselbe wie Abmelden?
Nein. Deinstallieren entfernt die App von einem Smartphone; die Abmeldung ändert die Teilnahme am Test. Weder die heutige Zahl der Installationen noch die heutige Einladungsliste belegt eine fortlaufende Anmeldung. Ein Tester, der deinstalliert hat, kann diese Installation auch nicht testen. Bestätigen Sie also, dass er noch im Test ist, und bitten Sie ihn, die App neu zu installieren und weiter zu testen.
Will Google, dass ich während des Tests Updates pushe?
Google empfiehlt, auf das Feedback der Tester zu reagieren und Probleme zu beheben, und im Antrag auf Produktionszugriff wird gefragt, was Sie nach dem Test geändert haben. Eine erforderliche Anzahl an Releases veröffentlicht Google nicht. Veröffentlichen Sie nützliche Fixes, wenn Sie sie brauchen, halten Sie fest, was sich geändert hat, und testen Sie es erneut. Veröffentlichen Sie keine kosmetischen Releases, nur um eine angebliche Regel von zwei oder drei Updates zu erfüllen.
Wie viele Tester brauche ich wirklich für den geschlossenen Test?
Für private Konten, die nach dem 13. November 2023 erstellt wurden, liegt das Minimum bei 12 Testern, die zum Zeitpunkt Ihres Antrags jeweils über die letzten 14 aufeinanderfolgenden Tage angemeldet geblieben sind. Wenn Sie früh zusätzliche Tester gewinnen, haben Sie einen Puffer. Spät hinzugefügte Ersatztester übernehmen nicht die Tage der Tester, die gegangen sind, und keine Testerzahl garantiert den Produktionszugriff.
Muss ich zwei oder drei Updates veröffentlichen, um durchzukommen?
Googles veröffentlichte Hinweise legen keine solche Quote fest. Gefragt wird nach dem Test, dem Feedback, den Änderungen und der Veröffentlichungsreife. Wenn der Test ein echtes Problem aufdeckt, beheben Sie es und dokumentieren Sie den erneuten Test. Wenn nicht, beschreiben Sie den Test ehrlich. Eine Anzahl an Releases allein beweist weder sinnvolles Testen noch garantiert sie, dass der Produktionszugriff gewährt wird.
Mein Release ist verfügbar, warum hat mein Tester trotzdem noch die alte Version?
Prüfen Sie das Google-Konto des Testers, seine Anmeldung im Track, den Rollout-Prozentsatz und den versionCode. Lassen Sie ihn dann den Play-Eintrag öffnen und nach einem Update suchen. Die automatische Aktualisierung kann ausgeschaltet sein oder durch Gerätebedingungen verzögert werden. Bestätigen Sie, dass der Build tatsächlich installiert wurde; das Update-Datum im Eintrag reicht nicht.
Pausiert „In review“ meinen 14-tägigen Test?
Ein Update in der Überprüfung wartet darauf, dass Google diesen Build bearbeitet. Google dokumentiert nicht, dass die Überprüfung eines gewöhnlichen Updates die bestehende Anmeldezeit Ihrer Tester pausiert. Prüfen Sie, ob der laufende Test weiterhin verfügbar ist und die Anmeldungen intakt sind. Eine weitere Einreichung kann die Überprüfung des Release verzögern, und diese ist von der Anforderung an den fortlaufenden Test getrennt.
Sollten Tester den Test verlassen und wieder beitreten, um das Update zu erhalten?
Nein. Den geschlossenen Test zu verlassen und wieder beizutreten, behebt kein Update-Problem und unterbricht die aufeinanderfolgenden Anmeldetage dieses Testers. Prüfen Sie zuerst die Veröffentlichung, das Konto des Testers, den Rollout und den versionCode, und versuchen Sie dann den normalen Update-Weg im Play Store. Reparieren Sie eine tatsächlich falsche Anmeldung separat und im Wissen, was das für die 14 Tage dieses Testers bedeutet.
Fazit
Zusammenfassung
Ihre App während des 14-tägigen geschlossenen Tests zu aktualisieren ist sicher, normal und erwünscht. Google misst die lückenlose Anmeldung jedes einzelnen Testers, also startet ein gewöhnliches Update im selben geschlossenen Track die 14 Tage Ihrer Tester nicht neu. Die echten Risiken sind, qualifizierte Tester zu verlieren, formelle Abmeldungen von Testern oder einen Build so kaputt auszuliefern, dass Tester aussteigen. Liefern Sie echte Fixes, reagieren Sie auf Feedback und schützen Sie Ihre Testerzahl mit einem früh gewonnenen Puffer. Wenn Sie Hilfe dabei möchten, 12 oder mehr Tester angemeldet zu halten, stellt PrimeTestLab 12 bis 25 echte Tester ab $19.99 plus 5% Servicegebühr (mindestens $1.50) bereit, mit Teststart in 4-6 Stunden. Wenn der Produktionszugriff nach dem vollständigen Test nicht gewährt wird, wählen Sie zwischen einem kostenlosen neuen Test oder einer vollständigen Rückerstattung. Preispläne ansehen →