Vorschau: Missbrauch von Geräten und Netzwerken

Richtlinienvorschau (gültig ab dem 31. Mai 2024)

In diesem Artikel erhalten Sie eine Vorschau auf die Änderungen der Richtlinienaktualisierungen im Oktober 2023.

Wir fügen unserer Richtlinie zum Missbrauch von Geräten und Netzwerken ein neues Beispiel hinzu, um zu verdeutlichen, dass Apps mit Full-Screen-Intent-Berechtigung Nutzer nicht zu Interaktionen mit störender Werbung oder Benachrichtigungen zwingen dürfen.

Hier finden Sie den aktuellen Artikel „Missbrauch von Geräten und Netzwerken“.

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 Berechtigung für Full-Screen Intent eingesetzt wird, um Nutzer zu zwingen, mit störender Werbung oder entsprechenden Benachrichtigungen zu interagieren

 

Verwendung von Diensten im Vordergrund 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.

 

Vom Nutzer initiierte Datenübertragungsvorgänge 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.

 

Anforderungen für Flag Secure 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.

 

Apps, die Android-Container auf dem Gerät ausführen 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 REQUIRE_SECURE_ENV ist ein Flag, das im Manifest einer App deklariert werden kann, um anzugeben, dass die App nicht in Android-Containern auf dem Gerät ausgeführt werden darf. Aus Sicherheits- und Datenschutzgründen müssen Apps, die Android-Container auf dem Gerät zur Verfügung stellen, alle Apps berücksichtigen, die dieses Flag deklarieren und: 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). Weitere Informationen zu dieser Richtlinie finden Sie in der Hilfe.