Ablehnung bei Google Play
Seit Android 14 hat jeder Foreground Service (Dienst im Vordergrund) einen angegebenen Typ, und Google verlangt von Apps, die auf Android 14 oder höher abzielen, jeden Typ in der Play Console mit einer Beschreibung und einem Video zu begründen. Eine typische Web-Wrapper-App braucht überhaupt keinen Foreground Service. Taucht einer in deinem Bundle auf, finde heraus, woher er kommt, und entferne ihn dann oder gib ihn mit einem Video an, das zum Anwendungsfall passt.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Ein Foreground Service ist Arbeit, die eine App weiter erledigt, während der Nutzer woanders ist, sichtbar gemacht durch eine laufende Benachrichtigung: Musikwiedergabe, Navigation, eine Trainingsaufzeichnung, ein Anruf. Seit Android 14 muss jeder Foreground Service einen Typ angeben (location, mediaPlayback, dataSync, camera, microphone, health, phoneCall und einige weitere), und die App muss die passende Berechtigung FOREGROUND_SERVICE_* haben. Manche Typen brauchen zusätzlich die zugrunde liegende Laufzeitberechtigung, etwa den Standortzugriff für den Typ location.
Google Play setzt einen Prüfschritt obendrauf. Apps, die auf Android 14 oder höher abzielen und Foreground Services nutzen, füllen auf der Seite App-Inhalte die Erklärung zu Diensten im Vordergrund aus. Für jeden Typ beschreibst du die Funktion, die ihn nutzt, erklärst, welche Auswirkungen es für den Nutzer hätte, wenn das System die Aufgabe aufschiebt oder unterbricht, wählst den passenden Anwendungsfall aus einer Liste und verlinkst ein Video, das zeigt, mit welchen Schritten ein Nutzer die Funktion auslöst. Googles Anforderungen an Foreground Services beschreiben das Formular. Die Erwartung dahinter: Der Nutzer hat die Aufgabe gestartet oder bemerkt sie deutlich, und sie kann nicht einfach bis später warten.
Es gibt zwei typische Situationen. Vor dem Review wird der Upload oder das Release blockiert, bis du angibst, ob die App Berechtigungen für Foreground Services nutzt, und jeden verwendeten Typ deklarierst. Nach dem Review wird die Erklärung abgelehnt: Das Video zeigt die Funktion nicht, der gewählte Anwendungsfall passt nicht zu dem, was das Video zeigt, oder der Typ ist für das, was die App tut, nicht gerechtfertigt. Entwickler, die immer wieder dieselbe Art Video hochladen, berichten, dass sie in einer Schleife festhängen. Der Ausweg ist, den Widerspruch zwischen Funktion, Anwendungsfall und Video aufzulösen oder den Dienst zu entfernen.
| Typ und Berechtigung | Typische Quelle | Was du tust |
|---|---|---|
location / FOREGROUND_SERVICE_LOCATION | Der WebViewGold-GPSService für Tracking im Hintergrund (requireBackgroundLocation) | Nur für vom Nutzer gestartetes Tracking behalten, das zum Kern der App gehört; sonst die Blöcke wieder auskommentieren |
mediaPlayback / FOREGROUND_SERVICE_MEDIA_PLAYBACK | Eine Audio- oder Medienbibliothek | Nur behalten, wenn Audiowiedergabe bei ausgeschaltetem Bildschirm eine Kernfunktion ist |
dataSync / FOREGROUND_SERVICE_DATA_SYNC | Sync-, Backup- oder Upload-Bibliotheken | Meist entfernen; für Übertragungen, die der Nutzer anfordert, verweist Google auf vom Nutzer initiierte Datenübertragungsjobs (user-initiated data transfer jobs) |
camera, microphone, phoneCall | Videoanruf- oder Sprach-SDKs | Nur für echte Anruffunktionen |
health / FOREGROUND_SERVICE_HEALTH | Fitness-Tracking-Bibliotheken | Nur, während der Nutzer aktiv ein Training aufzeichnet |
specialUse | Selten, eigener Code | Braucht eine schriftliche Begründung und wird geprüft; keine Abkürzung um einen passenden Typ herum |
Großartige Möglichkeit, eine Web-App in eine native App zu verwandeln! Schnelle Umsetzung und ein toller Weg, Apps in die App Stores zu bringen, ohne eine komplett native App entwickeln zu müssen!
Eine Stunde für das Aufräumen und ein Video pro Typ, den du behältst.
Öffne in Android Studio AndroidManifest.xml, wechsle auf den Tab „Merged Manifest“ und suche nach foregroundServiceType und FOREGROUND_SERVICE. In der Play Console listet der App Bundle Explorer die Berechtigungen auf, die Google aus deinem Bundle ausgelesen hat.
Startet ein Nutzer ihn, und bemerkt der Nutzer ihn, während er läuft? Trifft beides für keine Funktion zu, die deine App wirklich anbietet, gehört der Dienst nicht in die App.
Für den Standortdienst von WebViewGold setzt du requireBackgroundLocation auf false und kommentierst die Blöcke FOREGROUND_SERVICE_LOCATION und GPSService aus (siehe die Android-Doku zur Geolocation). Bei einer Bibliothek entfernst du die Berechtigung und ihren Dienst mit den Regeln unten und testest dann die Funktion, die diese Bibliothek liefert; einen Dienst zu entfernen, den eine Bibliothek noch aufruft, kann sie abstürzen lassen.
Bildschirmaufnahme auf einem echten Gerät: App öffnen, bei Bedarf anmelden, auf das Bedienelement tippen, das die Funktion startet (zum Beispiel einen Button „Tracking starten“, der backgroundlocationon:// aufruft), die laufende Benachrichtigung zeigen, die App verlassen, damit sichtbar wird, dass die Aufgabe weiterläuft, und sie dann stoppen. Lade es als nicht gelistetes YouTube-Video hoch.
Öffne auf der Seite App-Inhalte die Erklärung zu Diensten im Vordergrund und beschreibe pro Typ die Funktion in ein oder zwei Sätzen, erkläre, was kaputtgeht, wenn die Aufgabe aufgeschoben oder unterbrochen wird, wähle den Anwendungsfall, der zum Video passt, und füge den Link ein.
Höherer Version Code, neues Bundle, und ersetze ältere Bundles auf den Test-Tracks. Ein Typ, den du entfernt hast, sollte keine Erklärung mehr brauchen, sobald kein aktives Bundle ihn mehr enthält. Der Guide zum Target API Level erklärt, warum ein Rebuild aus dem aktuellen Template auch hier wichtig ist.
Kopiere den genauen Klassennamen aus dem Tab „Merged Manifest“; der unten ist ein Platzhalter. Teste danach die Funktion der Bibliothek.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Einen Foreground-Service-Typ entfernen, den die App nicht nutzt -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" tools:node="remove" />
<application>
<!-- Platzhalter: den Klassennamen aus dem Tab Merged Manifest verwenden -->
<service android:name="com.example.somelibrary.SyncForegroundService" tools:node="remove" />
</application>
</manifest>Beschreibe eine konkrete Funktion in den Worten, die ein Nutzer verwenden würde, und lass das Video genau diese Schritte zeigen. Die Vorlage bleibt auf Englisch, weil die Reviewer von Google Englisch lesen.
Feature description: When a courier taps Start shift, [App name] starts a location foreground service that shares the courier's position with dispatch until the courier taps End shift. An ongoing notification is shown the whole time. Impact if deferred or interrupted: Dispatch loses the courier's position during the delivery, customers see wrong arrival times, and orders cannot be reassigned when a courier is delayed. The task cannot be postponed, because the position is only useful in real time. Use case: [the closest match from the list, for example user-initiated location sharing]. Video: [YouTube link], showing login with the test account from Sign-in details, Start shift, the ongoing notification, the app in the background with tracking active, and End shift. The same feature is declared in the Location permissions declaration.
Weil eine FOREGROUND_SERVICE-Berechtigung oder ein typisierter Dienst in deinem Bundle steckt, meist von einer Bibliothek oder einem Template-Block, den du nicht brauchst. Finde ihn im zusammengeführten Manifest und entferne ihn; bleibt nichts übrig, ist die Erklärung nicht mehr nötig.
Nein. OneSignal, Firebase Cloud Messaging und Pushwoosh stellen Benachrichtigungen über das System zu, ohne Foreground Service in deiner App, und geplante lokale Erinnerungen sind ebenfalls kein Anwendungsfall für einen Foreground Service.
specialUse ist für Aufgaben gedacht, die kein anderer Typ abdeckt, und Google prüft die schriftliche Begründung. Wer ihn für etwas nutzt, das eindeutig zu einem anderen Typ passt, etwa Standort oder Medienwiedergabe, provoziert eine Ablehnung.
Es beginnt mitten in der Funktion, überspringt die Nutzeraktion, die den Dienst startet, zeigt einen anderen Ablauf als den gewählten Anwendungsfall oder lässt sich nicht öffnen, weil der Link privat ist. Halte es kurz, linear und für jeden mit dem Link abrufbar.
Nein. Google verlangt für neue Apps und Updates ein aktuelles Target API Level, also zielt jede aktuelle App auf Android 14 oder höher ab und braucht die Erklärung, sobald sie Foreground Services nutzt.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.