Google Play Ziel-API-Level 36: Was sich am 31. August 2026 ändert

Google hebt die Ziel-API-Schwelle des Play Store einmal im Jahr an, und 2026 ist der API-36-Zyklus. Die Zahl ist nicht der verwirrende Teil. Verwirrend ist, dass "die Ziel-API-Level-Anforderung" in Wahrheit zwei Regeln unter einem Namen sind: Die eine regelt, was Sie hochladen dürfen, die andere, niedrigere regelt, wer das bereits Veröffentlichte noch installieren kann. Fast jede Seite, die zu dieser Frage rankt, vermischt beide, und genau so bauen Entwickler eine App neu, die gar nicht neu gebaut werden musste, oder winken eine Play-Console-Warnung durch, die wichtig war.

Dieser Beitrag trennt sie, nennt Ihnen die Zahlen je Geräteform und beantwortet dann die Frage, die im August tatsächlich in unserem Support landet: Was macht das mit einer App, die mitten in einem geschlossenen Test (closed testing) mit 12 Testern über 14 aufeinanderfolgende Tage steckt? PrimeTestLab übernimmt genau diese Testseite für Entwickler, wir sehen die zeitliche Kollision also ständig, und die Hinweise in jenem Abschnitt gelten unabhängig davon, ob Sie einen Dienst nutzen oder selbst Tester suchen. Jedes Datum und jedes Level unten wurde am 9. August 2026 gegen Googles eigene Seiten geprüft, und alles, was Google nicht wirklich dokumentiert hat, ist als solches gekennzeichnet statt mit einer selbstbewussten Vermutung gefüllt.

Die Regel in einem Satz

Ab dem 31. August 2026 muss eine normale App für Smartphone, Tablet, Foldable oder Android Auto auf Android 16, API-Level 36 oder höher abzielen, um bei Google Play eingereicht werden zu können, egal ob es sich um eine ganz neue App oder um das Update einer veröffentlichten App handelt. Dieser eine Satz deckt die meisten Leser ab. Die Ausnahmen und die eigene, niedrigere Schwelle für Apps, die Sie nicht anfassen, füllen den Rest dieses Beitrags.

Ein Name, zwei verschiedene Regeln

Google benutzt den Ausdruck "Ziel-API-Level-Anforderung" für zwei Dinge, die sich überhaupt nicht gleich verhalten. Sie auseinanderzuhalten ist das Wertvollste, was Sie aus dieser Seite mitnehmen können.

Eine App, die still auf API 35 liegt und kein Update mehr bekommt, ist am 31. August nach Regel 2 also konform und wird in dem Moment nicht konform, in dem Sie irgendetwas nach Regel 1 veröffentlichen wollen. Das ist kein Widerspruch, sondern Absicht: Google hebt die Latte für das, was in den Store hineinkommt, schneller an als für das, was darin bleibt.

Die drei Begriffe, die Google genau definiert

Die Richtlinie stützt sich auf drei Begriffe, und jeder hat eine feste Bedeutung, die entscheidet, unter welche Regel Sie fallen:

• Neue App: eine App, die "noch nicht bei Google Play veröffentlicht" ist. Der erste Upload eines Paketnamens.
• Bestehende App: eine App, die bereits bei Google Play veröffentlicht ist.
• App-Update: eine neue Version einer bestehenden App, die zur Überprüfung eingereicht wird und die aktuelle ersetzen soll. Ein Update wird nach der Einreichungsregel beurteilt, nicht nach der Verfügbarkeitsregel.

Anforderungen je Geräteform

"Android-App" ist nicht eine Zeile. Smartphones, Tablets, Foldables und Android Auto gehen auf API 36. Wear OS und Android Automotive OS bleiben bei API 35. Android TV und Android XR bleiben bei API 34. Die Schwellen für eine App, die Sie nicht aktualisieren, liegen noch niedriger, und der Schalter unten wechselt zwischen beiden Sätzen.

Android Auto ist nicht Android Automotive OS

Diese beiden Namen kosten Entwickler jedes Jahr echte Zeit. Android Auto projiziert eine App vom Smartphone auf den Bildschirm im Auto, die App ist also eine Smartphone-App und folgt der Smartphone-Regel: API 36. Android Automotive OS ist das Betriebssystem im Fahrzeug selbst und gehört zu den ausdrücklich genannten Ausnahmen mit niedrigerem Ziel: API 35. Wenn Sie eine Medien- oder Navigations-App für beide ausliefern, gilt für Sie der höhere der beiden Werte.

Sind Sie betroffen? Drei Fragen genügen

Ob der 31. August Ihr Problem ist, hängt an drei Dingen: was Sie gerade vorhaben, welche Geräteform Sie ausliefern und worauf Ihr aktueller Build tatsächlich abzielt. Das Werkzeug unten wendet Googles veröffentlichte Schwellen auf diese Kombination an und sagt Ihnen, unter welche der beiden Regeln Sie fallen.

Wenn das Ergebnis Sie entwarnt, wollen Sie trotzdem die Checkliste vor der Frist am Ende, denn "meine Quellen setzen Ziel 36" und "das von Google bewertete Artefakt deklariert 36" sind nicht dieselbe Aussage. Die häufigste trügerische Sicherheit in diesem ganzen Zyklus ist ein Entwickler, der seine Gradle-Datei liest statt sein hochgeladenes Bundle.

Was wirklich passiert, wenn Sie den 31. August verpassen

Zwei verschiedene Dinge, je nachdem, unter welche Regel Sie fallen. Wenn Sie einen Build unterhalb der Schwelle hochladen wollen, erfüllt die Einreichung die Anforderung nicht. Wenn Sie eine veröffentlichte App unterhalb der Verfügbarkeitsschwelle einfach liegen lassen, ist sie für neue Nutzer nicht mehr auffindbar und installierbar, deren Gerät eine neuere Android-Version ausführt, als sie als Ziel hat. Keines der beiden Ergebnisse ist eine Löschung.

Wenn Sie hochladen wollen

Beachten Sie, woran diese Folge hängt: am Akt des Hochladens. Der Kalender allein tut einem bereits live stehenden Build nichts. Deshalb kann eine App am 1. September vollkommen konform und am 2. September blockiert sein, nur weil Sie sich entschieden haben, einen Bugfix zu veröffentlichen.

Wenn Sie eine veröffentlichte App unterhalb der Schwelle liegen lassen

Das ist der Fall, den Wettbewerber als "Ihre App verschwindet" beschreiben, und das ist auf eine Weise falsch, die wichtig ist. Googles Formulierung lautet, die App sei für eine bestimmte Nutzergruppe "nicht mehr auffindbar". Konkret:

• Neue Nutzer auf neueren Geräten verlieren den Zugang. Führt das Gerät einer Person eine höhere Android-Version aus als das Ziel Ihrer App, zeigt Google Play die App dieser Person nicht mehr an und installiert sie nicht mehr.
• Neue Nutzer auf älteren Geräten sind nicht betroffen. Ein Gerät mit demselben oder einem niedrigeren API-Level als das Ziel der App kann sie weiterhin erhalten.
• Bestehende Installationen sind nicht betroffen. Wer die App bereits installiert hat, kann sie weiterhin finden, neu installieren und auf unterstützten Android-Versionen nutzen.
• Deeplinks sagen die Wahrheit. Wer auf einem nicht berechtigten neueren Gerät Ihren Play-Store-Link öffnet, bekommt gemeldet, die App sei "für eine ältere Android-Version entwickelt".

Was nicht passiert

Jeden August erzeugt diese Richtlinie dieselben vier Ängste in Googles Support-Foren. Keine davon beschreibt, was auf der Seite zum Ziel-API-Level steht.

Zerstört das Ziel API 36 die Unterstützung älterer Geräte?

Nein, nicht von selbst. targetSdk gibt an, für welches Android-Verhalten Ihre App gebaut und getestet ist. minSdk entscheidet, auf welcher ältesten Android-Version sie sich installieren lässt. Das sind zwei getrennte Zahlen, und das Ziel auf 36 zu heben hebt das Minimum nicht mit an: Ihre App kann ältere Android-Versionen bis hinunter zu diesem Minimum weiter unterstützen, sofern Ihr Code und Ihre aktualisierten Abhängigkeiten kompatibel bleiben.

Das ist das Missverständnis, das in jedem Zyklus die meiste Aufregung erzeugt. Ein Entwickler liest "muss auf Android 16 abzielen", versteht "läuft nur noch auf Android 16" und folgert, Google habe gerade den Großteil seiner erreichbaren Geräte gestrichen. Schieben Sie das Minimum unten und sehen Sie, was sich wirklich ändert.

Die drei Zahlen, und welche Google Play kontrolliert

Was das bedeutet, wenn Ihre App gerade im geschlossenen Test ist

Wenn Sie ein neues privates Entwicklerkonto haben und den verpflichtenden geschlossenen Test mit 12 Testern über 14 aufeinanderfolgende Tage laufen lassen, fällt die Frist mitten in Ihr Fenster. Der sichere Zug ist, den API-36-Release vor dem 31. August in denselben geschlossenen Track zu bringen, alle Tester angemeldet zu lassen und sich von einer Frist nie zu einem Track-Wechsel oder einem Neustart mit anderen Testern drängen zu lassen.

Googles Seite zum Ziel-API-Level und Googles Seite zum geschlossenen Test werden von verschiedenen Teams für verschiedene Zwecke geschrieben, und keine der beiden nimmt Bezug auf die andere. Damit bleibt eine echte Lücke, und ehrlich ist, Ihnen genau zu zeigen, wo der dokumentierte Boden endet.

Was geprüft ist

• Ein betroffenes neues privates Konto "muss einen geschlossenen Test durchführen" mit mindestens 12 Testern, die über die letzten 14 Tage fortlaufend angemeldet waren, bevor es Produktionszugriff beantragen kann. Das gilt für private Konten, die nach dem 13. November 2023 erstellt wurden. Geprüft
• Googles Entwicklerdokumentation sagt, ein hochgeladenes APK müsse die Ziel-API-Anforderungen von Play erfüllen, und veröffentlicht keine Ausnahme für Test-Tracks. Diese Formulierung ist track-unabhängig, nicht testspezifisch: Ein neuer Upload in den geschlossenen Track nach der Frist sollte deshalb als API-36-pflichtig eingeplant werden. Das ist ein starker Schluss, keine dokumentierte Regel für Test-Tracks. Teilweise
• Googles eigene Hinweise ermutigen Entwickler ausdrücklich, die App im geschlossenen Test weiter zu aktualisieren, während sie Probleme beheben, und definieren den qualifizierenden Zeitraum über die durchgehende Anmeldung der Tester, nicht über ein eingefrorenes Artefakt. Geprüft
• Der interne Test ist auf 100 Tester begrenzt und ersetzt den qualifizierenden geschlossenen Test nicht. Geprüft

Was Google nicht dokumentiert hat

Weil die Antwort unbekannt ist, besteht die richtige Strategie nicht darin, sie vorherzusagen. Sie besteht darin, die Frage gegenstandslos zu machen, indem vor dem Stichtag ein konformer Release im Track liegt. Das ist in beiden Fällen sicher und kostet Sie nichts, falls das alte Artefakt ohnehin weitergelaufen wäre.

Die Reihenfolge, die in beiden Fällen sicher ist

1. Behalten Sie denselben geschlossenen Track und dieselbe Testergruppe

   Legen Sie keinen frischen Track für den API-36-Release an und entfernen Sie keine angemeldeten Tester. Die 14-tägige Kontinuität, die Google zählt, hängt daran, dass Tester angemeldet bleiben: Die Anmeldung ist also das Gut, das Sie schützen.

2. Bauen und testen Sie API 36 vor der Frist, nicht an der Frist

   Behandeln Sie die Umstellung als eigene Aufgabe mit eigener Testrunde. Einen Bruch im Edge-to-Edge-Layout am 30. August zu entdecken ist ein ganz anderer Tag, als ihn am 10. August zu entdecken.

3. Laden Sie ihn mit höherem versionCode in den bestehenden geschlossenen Track

   Jedes ersetzende Bundle braucht einen erhöhten versionCode. Google definiert den qualifizierenden Zeitraum über die durchgehende Anmeldung der Tester und ermutigt ausdrücklich dazu, während des Tests weiter Probleme zu beheben, veröffentlicht aber keine absolute Garantie für jeden Fall eines Release-Austauschs. Behalten Sie denselben Track und dieselben angemeldeten Tester und prüfen Sie danach den Zähler in der Play Console. Die vollständige Mechanik des Aktualisierens mitten im Test lohnt sich, wenn das Ihr erster Zyklus ist.

4. Prüfen Sie, ob der Release die Tester wirklich erreicht hat

   Ein veröffentlichter Release ist nicht dasselbe wie ein ausgelieferter. Prüfen Sie, dass der geschlossene Release live ist, dass der versionCode höher ist und dass die Tester auf der Anmeldeliste das Update sehen.

5. Prüfen Sie den Richtlinienstatus nach der Verarbeitung erneut

   Geben Sie dem Bundle Zeit zur Verarbeitung und öffnen Sie dann den Richtlinienstatus der App erneut. Bleibt die Ziel-API-Warnung bestehen, arbeiten Sie die Diagnoseliste ab, statt willkürlich Releases zu löschen.

6. Beantragen Sie die Verlängerung nur, wenn die Umstellung wirklich nicht rechtzeitig fertig wird

   Sie verschafft Ihnen Zeit bis zum 1. November 2026 und wird pro betroffener App beantragt. Sie ist kein Grund, die technische Arbeit zu pausieren.

So beantragen Sie die Verlängerung bis zum 1. November 2026

Betroffene Entwickler können eine Verlängerung beantragen, die die Verteilung bis zum 1. November 2026 aufrechterhält. Sie wird pro App beantragt, aus der Richtlinienwarnung dieser App in der Play Console heraus. Google beschreibt sie weder als automatisch noch als sicher noch als dauerhafte Ausnahme: Migrieren Sie deshalb weiter, solange der Antrag offen ist.

Google Play Console · echter Screenshot Zum Vergrößern klicken

1. Öffnen Sie die betroffene App in der Play Console

   Der Zugang zur Verlängerung hängt an der App, nicht am Konto. Wenn Sie mehrere Apps veröffentlichen, rechnen Sie damit, das für jede betroffene zu wiederholen.

   Geprüft
2. Gehen Sie zu Policy status

   Nur Apps, die Google als nicht konform ansieht, tragen erwartungsgemäß das Ziel-API-Problem. Ist die App bereits konform, gibt es hier nichts zu verlängern und kein Formular zu finden.

   Geprüft
3. Öffnen Sie die Ziel-API-Warnung oder die Problemdetails

   Der im Screenshot oben sichtbare Problemtitel lautet App must target Android 16 (API level 36) or higher. Die Formulierung kann je nach App und Rollout-Stand abweichen: Nehmen Sie sie als das, was ein echtes Konto gesehen hat, nicht als garantiert allgemeingültigen String.

   Geprüft
4. Folgen Sie dem Verlängerungslink im Problem oder in den Benachrichtigungen

   Google leitet einen Teil der betroffenen Entwickler über die App-Benachrichtigung statt über das Problemfeld. Sehen Sie beides nach, bevor Sie schließen, die Option gebe es bei Ihnen nicht.

   Geprüft
5. Senden Sie die angeforderten Angaben

   Google veröffentlicht die genauen Fragen nicht auf seiner öffentlichen Hilfeseite: Behandeln Sie jede Liste der "gestellten Fragen" als ungeprüft. Antworten Sie aus Ihrem echten Umstellungsplan heraus.

   Teilweise
6. Behandeln Sie den 1. November 2026 als harte Grenze

   Die Verlängerung verschiebt das Datum, sie hebt die Anforderung nicht auf. Was Sie bis zum 31. August nicht geschafft haben, muss bis zum 1. November fertig sein.

   Geprüft
7. Migrieren Sie weiter, solange der Antrag offen ist

   Nichts in Googles Formulierung verspricht eine Genehmigung. Mit einer Verlängerung zu planen, die Sie nicht erhalten haben, ist die teuerste Annahme, die dieser Zyklus zu bieten hat.

   Teilweise

Eine letzte Unterscheidung lohnt sich: Google hängt den Verlängerungshinweis an die API-36-Anforderung, und der Fließtext beschreibt die Verlängerung meist so, dass sie die Verteilung einer bestehenden App erhält. Er geht nicht mit derselben Genauigkeit jede Kombination aus neuer App, Update und bestehender App durch. Bevor Sie annehmen, eine Verlängerung decke einen bestimmten geplanten Upload ab, lesen Sie, was die Warnung Ihrer eigenen App abzudecken angibt.

So stellen Sie eine App auf API 36 um

Vier Schritte: das API-36-SDK installieren, compileSdk und targetSdk auf 36 heben, die Abhängigkeiten aktualisieren, die dabei brechen, und die Verhaltensänderungen von Android 16 testen. Die Zahl zu ändern ist eine Zeile. Nachzuweisen, dass die App noch funktioniert, ist die eigentliche Umstellung.

Schritt 1: das Android-16-SDK installieren

Öffnen Sie Android Studio, gehen Sie in den SDK Manager und installieren Sie die Android-SDK-Plattform für API-Level 36 zusammen mit den aktuellen Build Tools 36.x.x. Ohne installierte Plattform erzeugt das Anheben von compileSdk nur einen Build-Fehler, der scheinbar nichts mit Ihrer Änderung zu tun hat.

Schritt 2: die Level in Ihrem Build anheben

Wählen Sie Ihren Stack. Dateipfad und genaue Zeilen ändern sich, das Ziel nicht: Das Manifest in Ihrem hochgeladenen Bundle muss Ziel 36 deklarieren.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Schritt 3: Abhängigkeiten und Framework-Werkzeuge aktualisieren

Beim Anheben des Compile-Levels geben alte Abhängigkeiten nach. Rechnen Sie damit, das Android Gradle Plugin, Gradle selbst, Kotlin, die AndroidX-Bibliotheken, die Google Play-Dienste und jedes Werbe- oder Analytics-SDK mit nativem Code anzufassen. Dieser Beitrag veröffentlicht bewusst nicht "die richtigen Versionen", weil kompatible Versionen wöchentlich wechseln und eine hier festgeschriebene Liste binnen zwei Wochen in die Irre führen würde. Nehmen Sie sie aus den aktuellen Versionshinweisen Ihres eigenen Frameworks, an dem Tag, an dem Sie umstellen.

Schritt 4: bauen, hochladen und das Artefakt prüfen

• Erzeugen Sie ein signiertes Android App Bundle und erhöhen Sie den versionCode.
• Testen Sie das Release-Artefakt, nicht nur einen Debug-Build. Minifizierung und Ressourcen-Shrinking brechen Dinge, die Debug-Builds verdecken.
• Laden Sie in den vorgesehenen Track hoch und prüfen Sie in der Play Console, dass das Artefakt Ziel-API-Level 36 meldet.
• Sehen Sie nach der Verarbeitung jeden aktiven Track durch und öffnen Sie den Richtlinienstatus erneut.

Android-16-Verhalten, das Sie vor dem API-36-Release testen sollten

Ziel API 36 schaltet die Verhaltensweisen von Android 16 für Ihre App auf Android-16-Geräten frei. Vorrangig zu testen sind Edge-to-Edge-Darstellung, Predictive Back, freie Ausrichtung auf großen Displays, Gesundheitsberechtigungen, Planung mit fester Rate und das Textlayout. Haken Sie unten an, was zutrifft, und Sie erhalten die Testliste Ihrer App statt einer allgemeinen.

Edge-to-Edge und Predictive Back: die größte Reichweite

Edge-to-Edge hat eine große Reichweite, weil es von Ihrer App keine exotische API verlangt. Auf Android 16 kann eine App mit Ziel API 36 das bisherige Abmelde-Attribut nicht mehr nutzen: Inhalt, der davon ausging, dass die Systemleisten ihm Platz lassen, läuft jetzt darunter. Das Symptom ist kosmetisch, bis zu dem Moment, in dem eine wichtige Schaltfläche unter der Gestenleiste liegt und nicht mehr antippbar ist.

Predictive Back hat eine ähnlich große Reichweite. Wenn Ihre App eine alte Zurück-Behandlung registriert, greift dieser Pfad womöglich schlicht nicht mehr wie früher, sobald Predictive Back für Ziel 36 standardmäßig aktiv ist. Testen Sie Zurück aus jeder Navigationstiefe: Modals, WebViews, Formulare mit ungespeicherten Eingaben und den letzten Bildschirm vor dem Beenden.

Was kein universeller Bruch bei Ziel 36 ist

Und was ist mit der 16-KB-Seitengrößen-Anforderung?

Andere Anforderung, anderes Datum, dieselben Apps. Bei der Ziel-API-Frist geht es um das Level, das Ihr Manifest deklariert. Bei der 16-KB-Anforderung geht es darum, ob Ihre nativen Bibliotheken auf Geräten mit 16-KB-Speicherseiten laufen. Googles aktuelle Hinweise nennen den 1. Februar 2027 als das Datum, ab dem betroffene App-Updates ohne 16-KB-Unterstützung nicht mehr veröffentlicht werden können.

• Wen es betrifft: Googles Anforderung gilt für Apps, die auf 64-Bit-Google-Play-Geräten auf API 35 oder höher abzielen. Innerhalb dieser Gruppe brauchen am ehesten die Apps echte Neubau- und Ausrichtungsarbeit, die native .so-Bibliotheken bündeln, direkt oder über ein SDK. Ist Ihre App reines Kotlin oder Java, ist sie meist bereits kompatibel, aber Testen ist besser als Annehmen.
• Was es nicht ist: Es gehört nicht zur Ziel-API-Frist vom 31. August 2026, und das eine zu erfüllen erfüllt nicht das andere.
• Warum beides zusammenfällt: Wer diesen Monat sein Ziel-Level anhebt, baut ohnehin neu, und genau dabei taucht die Seitengrößen-Prüfung auf. Dieses Timing ist der Grund für die Verwechslung.

Wenn Ihre App native Bibliotheken bündelt, behandeln Sie die Seitengrößen-Prüfung als eigene Aufgabe mit eigener Testrunde statt als etwas, das Sie in letzter Minute in den API-36-Release schieben. Die beiden Änderungen berühren verschiedene Teile des Builds, und sie gleichzeitig zu debuggen ist der sicherste Weg, aus einer einwöchigen Umstellung eine dreiwöchige zu machen.

Sie haben API 36 hochgeladen und die Warnung steht noch

Meist eines von drei Dingen: Das Bundle ist noch nicht fertig verarbeitet und der Richtlinienstatus nicht aktualisiert, ein älteres Artefakt liegt noch auf einem anderen aktiven Track, oder das hochgeladene Artefakt deklariert gar nicht 36, auch wenn Ihr Projekt es tut. Arbeiten Sie die Liste ab und fangen Sie nicht an, Releases zu löschen.

Der Problemtitel, den Entwickler aktuell melden, lautet Your app must target Android 16 (API level 36) or higher. Google hat keinen kanonischen vollständigen Fehlertext für jeden Upload-Weg veröffentlicht: Behandeln Sie jede online gefundene Formulierung, auch diese, als beobachtet und nicht als offiziell. Sie bleibt englisch, weil sie so erfasst wurde.

Eine Gewohnheit löst das meiste davon dauerhaft: Lesen Sie nach jedem Upload das Ziel-API-Level am Artefakt in der Play Console zurück und notieren Sie es neben dem versionCode. Das kostet zehn Sekunden und nimmt die ganze Kategorie "ich bin sicher, das habe ich behoben" aus Ihrer Woche.

Die Checkliste vor der Frist

Vierzehn Punkte, in der Reihenfolge, in der sie tatsächlich anfallen. Die letzten vier werden gern übersprungen, und genau sie entscheiden, ob die Warnung verschwindet.

Wo PrimeTestLab in diese Frist hineinpasst

Damit die Grenze klar ist: Wir stellen Ihren Code nicht um. targetSdk anzuheben, Abhängigkeiten zu aktualisieren und die Verhaltensänderungen von Android 16 zu beheben, ist Ihr Build, und dieser Beitrag ist unser gesamter Beitrag dazu. Was wir abdecken, ist die andere Hälfte der Kollision: die 12 echten Tester, über 14 aufeinanderfolgende Tage angemeldet, die ein neues privates Konto braucht, bevor es überhaupt in die Produktion kommt.

Das Problem ist der Zeitplan. Wer im August 2026 zum ersten Mal veröffentlicht, soll zwei zusammenhanglose schwierige Dinge im selben Fenster erledigen: einen API-36-Release ausliefern und zwei Wochen am Stück einen qualifizierenden geschlossenen Test zusammenhalten. Der Release ist eine lösbare Ingenieursaufgabe. Zwölf echte Menschen zu finden, die vierzehn Tage lang auf echten Geräten angemeldet bleiben, ist der Teil, der still einen Monat frisst.

Den geschlossenen Test selbst machen oder abgeben

Die Reihenfolge für diesen Monat

Wenn Sie beide Probleme gleichzeitig haben, führen Sie sie parallel statt nacheinander. Starten Sie den geschlossenen Test jetzt, denn seine 14 Tage sind Kalenderzeit, die Sie nicht komprimieren können, und machen Sie die API-36-Umstellung daneben. Schieben Sie den konformen Release in denselben geschlossenen Track, sobald er fertig ist, mit höherem versionCode und denselben weiterhin angemeldeten Testern. So hören die Frist und das Testfenster auf, sich um dieselben zwei Wochen zu streiten.

Häufige Fragen

Fazit

Richtlinien-Stand geprüft am 9. August 2026. Google aktualisiert diese Seiten ohne Ankündigung: Sehen Sie in den Primärquellen oben nach, bevor Sie auf ein Datum hin handeln. Für diesen Beitrag ist eine erneute Prüfung direkt nach dem 31. August und noch einmal nach dem 1. November 2026 vorgesehen.