Googles Play-Frist für API 36 ist abgelaufen, und die Berechtigungsfristen für 2027 stehen schon fest

Googles Play-Frist für API 36 ist abgelaufen, und die Berechtigungsfristen für 2027 stehen schon fest

Seit dem 31. August 2026 akzeptiert Google Play nur noch neue Apps und App-Updates, die auf Android 16 (API-Level 36) oder höher zielen. Apps für Wear OS, Android Automotive OS, Android TV und Android XR sind ausgenommen. Teams, die mehr Zeit brauchten, konnten eine Verlängerung bis zum 1. November 2026 beantragen. Dieses Datum ist verstrichen. Liegt Ihre targetSdkVersion noch unter 36, können Sie derzeit kein Update auf Play veröffentlichen, auch nicht den Hotfix, den Sie vielleicht nächste Woche brauchen.

Für bestehende Apps, die nicht aktualisiert werden, gilt eine separate Regel. Sie müssen mindestens Android 15 (API-Level 35) als Ziel haben, damit sie für neue Nutzer auf Geräten mit einer neueren Android-Version als dem Ziel der App verfügbar bleiben. Liegt die App darunter, wird sie nur noch Geräten mit derselben oder einer älteren Android-Version angezeigt. Eine App, die länger niemand angefasst hat, wird also nicht entfernt, sie wird nur immer schwerer zu finden.

Hinzu kommt: Am 29. Oktober 2026 hat Google eine Reihe von Richtlinienänderungen angekündigt, deren Stichtage sich über 2027 verteilen. Keine davon ist heute dringend. Aber jede davon führt zu Panik, wenn man sie erst zwei Wochen vor der Frist bemerkt.

Der Kalender für 2027

Die folgenden Termine stammen aus Googles Tabelle der Richtlinienfristen und von der Seite mit den Play-Richtlinien:

  • 27. Januar 2027: Kontakte. Die Richtlinie zur Kontaktberechtigung schränkt den umfassenden Zugriff auf die Kontakte der Nutzer ein. Apps, die keinen umfassenden Zugriff brauchen, müssen den Android Contact Picker verwenden.
  • 27. Januar 2027: präziser Standort. Apps, die auf Android 17 (API 37+) zielen, müssen für einmalige oder seltene Anfragen nach dem präzisen Standort die Android-Standortschaltfläche nutzen. Wer ACCESS_FINE_LOCATION behält, braucht in der Play Console eine Erklärung, warum die Standortschaltfläche oder der ungefähre Standort nicht ausreicht.
  • 27. Januar 2027: Abo-Rabatte. Abos mit dauerhaften, an Voraussetzungen geknüpften Rabatten, etwa Studierendentarife, müssen klar offenlegen, welche Kriterien gelten, wie die Prüfung funktioniert und was mit Preis und Leistungen passiert, wenn die Nutzer nicht mehr berechtigt sind.
  • 14. April 2027: AppFunctions. AppFunctions dürfen KI-Agenten weder täuschen noch manipulieren, deren Sicherheitskontrollen nicht umgehen und andere Apps nicht beeinträchtigen.
  • 25. August 2027: ACCESS_LOCAL_NETWORK. Der Zugriff auf das lokale Netzwerk ist auf Apps beschränkt, die ihn für ihre Kernfunktion brauchen und für die Geräteauswahl wie NsdManager nicht genügt. Apps, die auf Android 17 oder höher zielen, benötigen dafür eine Erklärung in der Play Console.
  • 25. August 2027: MANAGE_CONTACTS. Beschränkt auf Apps, deren Kernfunktion sie erfordert und für die System-Picker nicht ausreichen, mit einer Erklärung in der Play Console. Alle anderen müssen eng gefasste Plattform-Intents verwenden.

Warum der Wechsel des Ziel-API-Levels Teams immer wieder erwischt

In unseren nativen Android-Projekten ist das Anheben der targetSdkVersion selten der schwierige Teil. Eine Zahl in Gradle zu ändern dauert eine Minute. Die Arbeit steckt in allem, was diese Zahl aktiviert: neues Plattformverhalten, auf das sich Ihre App nun einlässt, Bibliotheken, die noch nicht nachgezogen haben, und Testgeräte, die die neue Version nicht abdecken. Wir haben erlebt, wie aus einer einzigen geänderten Zeile ein dreiwöchiger Sprint wurde, weil ein Zahlungs-SDK oder eine BLE-Bibliothek noch keine kompatible Version veröffentlicht hatte.

Das Muster, das wir am häufigsten sehen: Die App läuft, niemand ist ihr zugeteilt, und die Anforderung zum Ziel-API-Level erscheint als Warnung in der Play Console, die in einem gemeinsamen Postfach landet. Dann taucht ein echter Fehler auf, der Fix ist fertig, und der Upload wird abgelehnt. Jetzt führen Sie unter Druck eine Plattformmigration durch, während ein Produktionsproblem offen ist. In dieser Lage stecken diese Woche viele Teams.

Meine ehrliche Meinung: Behandeln Sie die jährliche Anhebung des Ziel-API-Levels wie eine Abhängigkeit, für die Sie selbst verantwortlich sind, und nicht wie eine lästige Pflicht von Google. Setzen Sie sie jedes Frühjahr auf die Roadmap, wenn die neue Anforderung angekündigt wird, und erledigen Sie sie, solange nichts brennt.

Die Berechtigungsänderungen wiegen schwerer, als sie aussehen

Die Regeln für 2027 folgen einer gemeinsamen Idee. Umfassende Berechtigungen werden durch System-Picker und -Schaltflächen ersetzt, und wer die umfassende Variante behalten will, muss sich in der Play Console rechtfertigen.

Am deutlichsten sehen wir das bei Healthcare- und IoT-Apps. IoT-Apps fordern den Zugriff auf das lokale Netzwerk oft früh an, weil die Geräteerkennung der erste Bildschirm ist, und dabei ist es leicht, mehr anzufordern als nötig. Wenn ein auf NsdManager basierender Picker Ihren Erkennungsablauf abdeckt, ist die Regel vom August 2027 meist nur Papierkram, den Sie vermeiden können. Wenn nicht, beginnen Sie jetzt aufzuschreiben, warum die Kernfunktion die Berechtigung braucht, denn genau danach fragt die Erklärung.

Bei Kontakten ist es ähnlich. Viele Apps fordern vollen Kontaktzugriff für einen einzigen Bildschirm „Freund einladen“ an. Der Contact Picker deckt diesen Fall ab, und der Umstieg vor Januar entfernt eine Berechtigung, der Nutzer ohnehin misstrauen. Auch aus Sicherheitssicht ist das eine gute Nachricht. In unseren Pentests sind zu weit gefasste Berechtigungen ein wiederkehrender Befund: Daten, die die App nie gebraucht hat, liegen in einem lokalen Cache und stehen jedem zur Verfügung, der auf dem Gerät Fuß fasst. Weniger Zugriff bedeutet weniger, das abfließen kann.

Die Regel zur Standortschaltfläche gilt erst, wenn Sie auf Android 17 zielen. Wenn Sie aber eine Filialsuche oder ein Checkout-Feld „Meinen Standort verwenden“ ausliefern, planen Sie die UI-Änderung jetzt. Eine Schaltfläche mit einem Tipp ist ein anderer Ablauf als ein Berechtigungsdialog zur Laufzeit, und das Design-Team wird mitreden wollen.

Die Regeln zu Abos und AppFunctions nicht überspringen

Die Offenlegungsregel für Abos übersieht man leicht, weil sie im Bereich Produkt und Recht liegt und nicht im Code. Wenn Sie einen Studierendentarif oder einen anderen an Voraussetzungen geknüpften Tarif anbieten, muss jemand den Prüfprozess und den Preis nach Wegfall der Berechtigung direkt auf der Paywall festhalten. Bei unseren Web- und Backend-Projekten für Unternehmenskunden bedeutet eine solche Anforderung meist eine Änderung sowohl der App-Texte als auch des Servers, der entscheidet, wer noch berechtigt ist. Beziehen Sie das Backend-Team also früh ein.

AppFunctions ist Neuland. Die Richtlinie ist kurz: KI-Agenten nicht austricksen, ihre Sicherheitskontrollen nicht umgehen, andere Apps nicht beeinträchtigen. Wenn Sie App-Aktionen für Agenten bereitstellen, prüfen Sie sie wie eine öffentliche API. Kontrollieren Sie, was jede Funktion ohne Bestätigung des Nutzers tun kann, und gehen Sie davon aus, dass sie irgendwann mit Eingaben aufgerufen wird, mit denen Sie nicht gerechnet haben.

Was diese Woche zu tun ist

  1. Prüfen Sie noch heute Ihr Ziel-API-Level. Liegt es unter 36, blockiert das Upgrade jetzt jeden Release. Branch anlegen, anheben, die komplette Testsuite auf einem Android-16-Gerät laufen lassen und jede Bibliothek aktualisieren, die bricht.
  2. Prüfen Sie Ihr Manifest. Listen Sie jede Verwendung von READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION und ACCESS_LOCAL_NETWORK auf und notieren Sie daneben, ob ein Picker oder eine Schaltfläche sie ersetzen könnte.
  3. Tragen Sie die Termine für 2027 in einen gemeinsamen Kalender ein, jeweils mit einer verantwortlichen Person, nicht nur mit einer Slack-Erinnerung.
  4. Weisen Sie jemandem das Play-Console-Postfach zu. Der meiste Ärger, den wir sehen, beginnt mit einer Warnung, die niemand gelesen hat.

Wenn Sie sehen möchten, wie wir solche Plattformmigrationen bisher gemeistert haben: In unserem Portfolio finden Sie einige Beispiele, und unsere Entwicklungsleistungen umfassen sowohl natives Android als auch die Backends dahinter.

Kommt Ihnen eine festhängende targetSdkVersion oder ein Berechtigungs-Audit, das Sie ständig aufschieben, bekannt vor, sprechen Sie uns an.

androidexpert-analysisgoogle-playmobile-developmenttarget-api-leveltech-news