Haftungsausschluss: Richtlinienzusammenfassungen dienen lediglich der Übersicht. Zur Einhaltung aller Vorschriften und Bestimmungen lesen Sie immer die vollständige Richtlinie. Bei einem Konflikt hat die vollständige Richtlinie Vorrang.
Apps (oder Drittanbieter-SDKs in Ihren Apps), die das Gerät des Nutzers, andere Geräte, Netzwerke, APIs oder Dienste, andere Apps auf dem Gerät, Google-Dienste oder das Netz eines autorisierten Mobilfunkanbieters stören oder in unerlaubter Weise darauf zugreifen, sind von Google Play untersagt. Dies umfasst eine Reihe von schädlichen, risikoreichen oder störenden Verhaltensweisen, wie z. B. die Durchführung eigener Updates außerhalb des Play Store, das Herunterladen nicht autorisierter ausführbarer Codes, das Ausnutzen von Sicherheitslücken, die Erleichterung von Hackerangriffen und das Entwickeln von Spiel-Cheats, die sich auf andere Apps auswirken. Der Schutz der Geräteintegrität des Nutzers und des gesamten Ökosystems ist von höchster Bedeutung. Bitte lesen Sie die vollständige Richtlinie, um sicherzustellen, dass Sie alle Vorgaben erfüllen.
Apps, die das Gerät des Nutzers, andere Geräte oder Computer, Server, Netzwerke, APIs oder Dienste, etwa andere Apps auf dem Gerät, Google-Dienste oder das Netz eines autorisierten Mobilfunkanbieters, stören, unterbrechen, beschädigen oder in unerlaubter Weise darauf zugreifen, sind nicht zulässig.
Apps bei Google Play müssen den Kernanforderungen zur Systemoptimierung von Android entsprechen, die in den Qualitätsrichtlinien für Apps bei Google Play dokumentiert sind.
Eine App, die über Google Play vertrieben wurde, darf sich ausschließlich anhand des Updatemechanismus von Google Play modifizieren, ersetzen oder aktualisieren lassen. Außerdem darf die App keinen ausführbaren Code (z. B. DEX-, JAR- oder SO-Dateien) von einer anderen Quelle als Google Play herunterladen. Diese Einschränkung gilt nicht für Code, der in einer virtuellen Maschine oder einem Interpreter ausgeführt wird, bei denen indirekter Zugriff auf Android-APIs besteht, wie etwa bei JavaScript in einer Webansicht oder einem Browser.
Apps oder Drittanbietercode (z. B. SDKs) mit interpretierten Sprachen (JavaScript, Python, Lua etc.), die zur Laufzeit geladen werden und beispielsweise nicht mit der App verpackt sind, dürfen bzw. darf keine potenziellen Verstöße gegen Google Play-Richtlinien ermöglichen.
Code, mit dem Sicherheitslücken eingeführt oder ausgenutzt werden, ist nicht zulässig. Informieren Sie sich im Programm zur Verbesserung der App-Sicherheit über die aktuellen Sicherheitsprobleme, die Entwicklern gemeldet wurden.
Beispiele für häufige Verstöße gegen die Richtlinie zum Missbrauch von Geräten und Netzwerken:
- Apps, die andere Apps bei der Schaltung von Werbung blockieren oder stören
- Schummel-Apps, die den Spielverlauf anderer Apps beeinflussen
- Apps, die das Hacken von Diensten, Software oder Hardware oder das Umgehen von Sicherheitsvorkehrungen ermöglichen oder eine entsprechende Anleitung geben
- Apps, die auf Dienste oder APIs in einer Weise zugreifen oder diese nutzen, die gegen die Nutzungsbedingungen verstößt
- Apps, die nicht für die Zulassungsliste infrage kommen und versuchen, die Verwaltung des Energieverbrauchs des Systems zu umgehen
- Apps, die Proxydienste für den Zugriff auf Inhalte Dritter zu Verfügung stellen – Proxydienste dürfen nur von Apps angeboten werden, in denen diese Funktion klar und deutlich den Hauptzweck für Nutzer darstellt
- Apps oder Drittanbietercode (z. B. SDKs), die ausführbaren Code wie DEX-Dateien oder nativen Code von einer anderen Quelle als Google Play herunterladen
- Apps, bei denen ohne vorherige Zustimmung des Nutzers andere Apps auf einem Gerät installiert werden
- Apps, die die Verteilung oder Installation von schädlicher Software ermöglichen oder entsprechende Links enthalten
- Apps oder Drittanbietercode (z. B. SDKs) mit eingebettetem WebView mit JavaScript-Schnittstelle, über die nicht vertrauenswürdige Webinhalte (z. B. HTTP-URLs) oder nicht verifizierte URLs aus nicht vertrauenswürdigen Quellen geladen werden (z. B. URLs, die über nicht vertrauenswürdige Intents aufgerufen werden)
- Apps, bei denen die Full-Screen-Intent-Berechtigung eingesetzt wird, um Nutzer zu zwingen, mit störender Werbung oder entsprechenden Benachrichtigungen zu interagieren
- Apps, die die Schutzmechanismen der Android-Sandbox umgehen, um Informationen zur Nutzeraktivität oder Nutzeridentität aus anderen Apps zu gewinnen
Wichtige Hinweise
| Richtig | Falsch |
| Die App und alle integrierten SDKs müssen die Anforderungen an Systemoptimierungen der grundlegenden Qualitätskriterien für Apps von Android erfüllen. | Ohne ausdrückliche Nutzereinwilligung andere Apps auf einem Gerät installieren. |
Die FLAG_SECURE-Einstellung einhalten. Bei Containern auf dem Gerät muss REQUIRE_SECURE_ENV beachtet werden. |
Proxy-Dienste für Dritte bereitstellen, es sei denn, dies ist der primäre, für Nutzer sichtbare Kernzweck der App. |
| Vom Nutzer initiierte Datenübermittlungsvorgänge nur für vom Nutzer initiierte Netzwerkdatenübermittlungen verwenden, die nur so lange ausgeführt werden, wie es erforderlich ist. | Drittanbieter-SDKs in der App verwenden, die ausführbaren Code (z. B. DEX- oder SO-Dateien) aus Quellen außerhalb von Google Play herunterladen, außer in virtuellen Maschinen oder Interpreter-Umgebungen. |
| Sich im Programm zur Verbesserung der App-Sicherheit über die aktuellen Sicherheitsprobleme informieren, die Entwicklern gemeldet wurden. | Das systemeigene Energiemanagement umgehen, es sei denn, dies ist zulässig. |
| Die Richtlinie zur Verwendung von Diensten im Vordergrund einhalten. | Andere Apps bei der Schaltung von Werbung blockieren oder stören. |
Die Berechtigung FULL-SCREEN INTENT verwenden, um Nutzer zur Interaktion mit störender Werbung und entsprechenden Benachrichtigungen zu zwingen. |
Verwendung von Diensten im Vordergrund
Die Richtlinie zur Berechtigung für Dienste im Vordergrund sorgt für Transparenz, Datenschutz und optimale Geräteleistung. Für Apps, die auf Android 14 oder höher ausgerichtet sind, müssen Sie im Manifest und in der Play Console zulässige Arten von Diensten im Vordergrund angeben. Sie müssen Beschreibungen, Informationen zu den Auswirkungen auf Nutzer und ein Demovideo einreichen, um die Verwendung der Dienste basierend auf Aktionen zu begründen, die von Nutzern initiiert und wahrgenommen werden. Bitte lesen Sie die vollständige Richtlinie, um sicherzustellen, dass Sie alle Vorgaben erfüllen.
Durch die Berechtigung für Dienste im Vordergrund wird sichergestellt, dass die für Nutzer sichtbaren Dienste im Vordergrund ordnungsgemäß verwendet werden. Für Apps, die für Android 14 und höher bestimmt sind, müssen Sie für jeden in der App verwendeten Dienst im Vordergrund einen gültigen Typ spezifizieren und die diesem Typ entsprechende Berechtigung für Dienste im Vordergrund deklarieren. Wenn beispielsweise der Anwendungsfall Ihrer App die Standortbestimmung erfordert, müssen Sie im Manifest der App die Berechtigung FOREGROUND_SERVICE_LOCATION deklarieren.
Für Apps darf eine Berechtigung für Dienste im Vordergrund nur in folgenden Anwendungsfällen deklariert werden:
- Wenn durch die Verwendung eine Funktion bereitgestellt wird, die für den Nutzer von Vorteil und für die Hauptfunktion der App relevant ist.
- Wenn die Verwendung durch den Nutzer initiiert wird oder durch den Nutzer wahrnehmbar ist. Beispiele hierfür sind Audio durch das Abspielen eines Songs, das Streamen von Medien auf ein anderes Gerät, eine klare und verständliche Nutzerbenachrichtigung oder eine Anfrage des Nutzers zum Hochladen eines Fotos in die Cloud.
- Wenn die Verwendung durch den Nutzer beendet oder angehalten werden kann.
- Wenn die Verwendung durch das System nicht unterbrochen oder aufgeschoben werden kann, sodass weder die Nutzerfreundlichkeit beeinträchtigt noch eine verwendete Funktion in ihrer vom Nutzer erwarteten Ausführung gestört wird. Beispielsweise muss ein Telefonanruf sofort beginnen und darf nicht vom System aufgeschoben werden.
- Wenn die Verwendung nur so lange erfolgt, wie es für die Durchführung einer Aufgabe erforderlich ist.
Die folgenden Anwendungsfälle für Dienste im Vordergrund sind von den oben genannten Kriterien ausgeschlossen:
- Typen systemExempted oder shortService;
- Typ „dataSync“ – nur bei Verwendung von Play Asset Delivery-Funktionen
Die Verwendung von Diensten im Vordergrund wird hier näher erklärt.
Wichtige Hinweise
| Das sollten Sie tun | Das sollten Sie nicht tun |
| Dienste im Vordergrund (foreground service, FGS) nur so lange ausführen, wie es nötig ist, um eine Aufgabe abzuschließen. | FGS verwenden, wenn die systemseitige Verwaltung der Aufgabe die Nutzerfreundlichkeit Ihrer App nicht beeinträchtigt. Ziehen Sie stattdessen Alternativen wie WorkManager in Betracht. |
| FGS müssen eine für den Nutzer nützliche Kernfunktion der App bereitstellen, vom Nutzer initiiert werden, Nutzer müssen über eine Benachrichtigung über ihre Ausführung informiert werden oder sie müssen anderweitig für sie wahrnehmbar sein (z. B. durch das Abspielen von Musik). | Ungültige oder unzutreffende FGS-Typen im Manifest Ihrer App deklarieren. |
| Ein Erklärungsformular in der Play Console einreichen, wenn die App auf Android 14 oder höher ausgerichtet ist, und den Anwendungsfall für jede verwendete FGS-Berechtigung beschreiben. Dabei muss der richtige FGS-Typ ausgewählt werden. |
Vom Nutzer initiierte Datenübertragungsvorgänge
Damit Nutzer die Kontrolle behalten und lang andauernde Aktivitäten im Hintergrund vermieden werden, hat Google Play strenge Richtlinien für Apps, die die API für vom Nutzer initiierte Datenübermittlungsvorgänge verwenden. Die Übermittlung von Daten muss direkt vom Nutzer angefordert werden. So wird sichergestellt, dass die App Datenübermittlungen nicht selbständig initiiert, sondern Befehle ausführt. Es sind ausschließlich Übermittlungen von Netzwerkdaten zulässig und die Dauer ist auf die Zeit beschränkt, die für den Abschluss der angeforderten Aktion benötigt wird. Bitte lesen Sie die vollständige Richtlinie, um sicherzustellen, dass Sie alle Vorgaben erfüllen.
Apps dürfen nur in folgenden Fällen die API für vom Nutzer initiierte Datenübertragungsvorgänge nutzen:
- Wenn die Verwendung vom Nutzer initiiert wird.
- Wenn Daten über ein Netzwerk übertragen werden sollen.
- Wenn die Verwendung nur so lange erfolgt, wie es für die Durchführung einer Datenübertragung erforderlich ist.
Hier wird die Verwendung von Data Transfer APIs, die vom Nutzer initiiert sind, näher erklärt.
Wichtige Hinweise
| Das sollten Sie tun | Das sollten Sie nicht tun |
| Übertragungen durch Nutzer starten lassen | Übertragungen automatisch starten |
| Nur für die Übertragung von Netzwerkdaten verwenden | API für Aktionen außerhalb des Netzwerks verwenden |
| Beenden, wenn die Übertragung abgeschlossen ist | Länger ausführen als notwendig |
Anforderungen für Flag Secure
FLAG_SECURE ist ein in der App deklariertes Anzeige-Flag, das angibt, dass sensible Daten auf der Benutzeroberfläche nur auf einer sicheren Oberfläche angezeigt werden sollten, um das Erfassen von Screenshots und das Anzeigen auf nicht sicheren Displays zu verhindern. Entwickler nutzen dieses Flag, wenn Inhalte nicht außerhalb der App / des Geräts angezeigt werden sollen. Google Play verlangt, dass alle Apps die deklarierten „FLAG_SECURE“-Flags anderer Apps respektieren und diese aus Sicherheits- und Datenschutzgründen nicht umgehen. Bitte lesen Sie die vollständige Richtlinie, um sicherzustellen, dass Sie alle Vorgaben erfüllen.
FLAG_SECURE ist ein Anzeige-Flag, das im Code einer App deklariert wird, um anzugeben, dass die Benutzeroberfläche sensible Daten enthält, die nur auf einer sicheren Oberfläche und nur während der Verwendung der App angezeigt werden sollen. Dieses Flag soll verhindern, dass die Daten in Screenshots erscheinen oder auf nicht sicheren Displays angezeigt werden. Entwickler deklarieren dieses Flag, wenn der Inhalt der App nicht außerhalb der App oder des Geräts des Nutzers angezeigt oder anderweitig übertragen werden soll.
Aus Sicherheits- und Datenschutzgründen müssen alle auf Google Play bereitgestellten Apps die FLAG_SECURE-Deklaration anderer Apps berücksichtigen. Das bedeutet, dass Apps keine Möglichkeiten zur Umgehung der FLAG_SECURE-Einstellungen in anderen Apps erleichtern oder schaffen dürfen.
Apps, die als Bedienungshilfe zulässig sind, sind von dieser Anforderung ausgenommen, solange sie keine durch FLAG_SECURE geschützten Inhalte speichern, übertragen oder im Cache speichern, sodass außerhalb des Geräts des Nutzers auf diese zugegriffen werden kann. Wichtige Hinweise
| Das sollten Sie tun | Das sollten Sie nicht tun |
FLAG_SECURE für sensible Daten in der Benutzeroberfläche deklarieren, von der keine Screenshots gemacht werden dürfen |
Einstellungen für |
FLAG_SECURE-Erklärungen für Sicherheit und Datenschutz in anderen Apps respektieren |
Mit FLAG_SECURE geschützte Inhalte außerhalb des Geräts übertragen, speichern oder im Cache speichern, auch nicht, wenn es sich um Bedienungshilfen handelt |
Apps, die Android-Container auf dem Gerät ausführen
Zur Vermeidung von Bedenken im Hinblick auf den Datenschutz und die Sicherheit können Entwickler das „REQUIRE_SECURE_ENV“-Flag in ihrem App-Manifest nutzen, wenn On-Device-Android-Container-Apps nicht alle Sicherheitsfunktionen von Android-Betriebssystemen haben. Das Flag zeigt an, dass die App nicht in einer simulierten Umgebung ausgeführt werden darf. Für derartige Container-Apps gilt das Flag dahingehend, dass sie keine Apps laden dürfen, in denen es aktiviert ist, und sie dürfen diese Sicherheitsmaßnahme auch nicht umgehen. Bitte lesen Sie die vollständige Richtlinie, um sicherzustellen, dass Sie alle Vorgaben erfüllen.
Apps, die Android-Container auf dem Gerät ausführen, stellen Umgebungen zur Verfügung, die ein ganzes Android-Betriebssystem oder Teile davon simulieren. Diese Umgebungen spiegeln möglicherweise nicht das gesamte Spektrum der Android-Sicherheitsfunktionen wider. Aus diesem Grund können Entwickler ein Manifest-Flag für eine sichere Umgebung hinzufügen, um den Android-Containern auf dem Gerät zu signalisieren, dass sie nicht in ihrer simulierten Android-Umgebung agieren dürfen.
Manifest-Flag für sichere Umgebung
- Manifeste der Apps, die in den Android-Container auf dem Gerät geladen werden sollen, auf dieses Flag überprüfen.
- Die Apps, die dieses Flag deklariert haben, nicht in ihren Android-Container auf dem Gerät laden.
- Nicht als Proxy fungieren, indem APIs auf dem Gerät abgefangen oder aufgerufen werden, sodass es scheint, als seien sie im Container installiert.
- Das Umgehen des Flags nicht erleichtern und keine Workarounds erstellen (z. B. eine ältere Version einer App laden, um das Flag „REQUIRE_SECURE_ENV“ der aktuellen App zu umgehen).
Wichtige Hinweise
| Das sollten Sie tun | Das sollten Sie nicht tun |
Wenn Ihre App On‑Device-Container bereitstellt: Prüfen, ob das Manifest anderer Apps das Flag REQUIRE_SECURE_ENV enthält und diese Apps dann nicht laden. |
Das Flag ignorieren. Sie dürfen Apps, die das Flag REQUIRE_SECURE_ENV deklarieren, nicht in Ihren Container laden. |
| Keine Workarounds verwenden. Sie dürfen das Flag nicht umgehen, indem Sie beispielsweise ältere Versionen einer App laden. | Sicherheitsmaßnahmen umgehen. Sie dürfen keine Workarounds erstellen, um die Sicherheitseinstellungen von Apps zu überschreiben. |
| Keinen Proxy für APIs verwenden. Ihre App darf nicht als Proxy fungieren, indem sie APIs außerhalb des Containers abfängt oder aufruft. | Den Anschein erwecken lassen, dass Apps in einer sicheren Umgebung ausgeführt werden, wenn dies nicht der Fall ist. |
| Die Richtlinienanforderungen für On‑Device-Android-Container lesen. |