Refus Google Play
Depuis Android 14, chaque service de premier plan a un type déclaré, et Google demande aux apps qui ciblent Android 14 ou plus récent de justifier chaque type dans la Play Console avec une description et une vidéo. Une app web encapsulée typique n'a besoin d'aucun service de premier plan. S'il en apparaît un dans votre bundle, trouvez d'où il vient, puis retirez-le ou déclarez-le avec une vidéo qui correspond au cas d'usage.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Un service de premier plan est un travail qu'une app poursuit pendant que l'utilisateur est ailleurs, avec une notification permanente qui le rend visible : lecture de musique, navigation, enregistrement d'une séance de sport, appel. Depuis Android 14, chaque service de premier plan doit déclarer un type (location, mediaPlayback, dataSync, camera, microphone, health, phoneCall et quelques autres) et l'app doit détenir l'autorisation FOREGROUND_SERVICE_* correspondante. Certains types exigent aussi l'autorisation d'exécution sous-jacente, comme l'accès à la localisation pour le type location.
Google Play ajoute une étape d'examen par-dessus. Les apps qui ciblent Android 14 ou plus récent et utilisent des services de premier plan remplissent la déclaration de service de premier plan sur la page Contenu de l'application. Pour chaque type, vous décrivez la fonctionnalité qui l'utilise, expliquez l'impact pour l'utilisateur si le système différait ou interrompait la tâche, choisissez le cas d'usage correspondant dans une liste et ajoutez le lien d'une vidéo montrant les étapes qu'un utilisateur suit pour déclencher la fonctionnalité. Les exigences de Google sur les services de premier plan décrivent le formulaire. L'attente derrière tout cela : l'utilisateur a lancé la tâche ou la remarque clairement, et elle ne peut pas simplement attendre plus tard.
Il y a deux situations typiques. Avant l'examen, l'import ou la version est bloqué tant que vous n'avez pas indiqué si l'app utilise des autorisations de services de premier plan et déclaré chaque type qu'elle utilise. Après l'examen, la déclaration est refusée : la vidéo ne montre pas la fonctionnalité, le cas d'usage choisi ne correspond pas à ce que montre la vidéo, ou le type n'est pas justifié pour ce que fait l'app. Les développeurs qui importent sans cesse le même genre de vidéo racontent qu'ils tournent en boucle. La sortie consiste à corriger le décalage entre fonctionnalité, cas d'usage et vidéo, ou à retirer le service.
| Type et autorisation | Source typique | Que faire |
|---|---|---|
location / FOREGROUND_SERVICE_LOCATION | Le GPSService de WebViewGold pour le suivi en arrière-plan (requireBackgroundLocation) | Ne le gardez que pour un suivi lancé par l'utilisateur et essentiel à l'app ; sinon, recommentez les blocs |
mediaPlayback / FOREGROUND_SERVICE_MEDIA_PLAYBACK | Une bibliothèque audio ou multimédia | Ne le gardez que si la lecture audio écran éteint est une fonctionnalité principale |
dataSync / FOREGROUND_SERVICE_DATA_SYNC | Bibliothèques de synchronisation, de sauvegarde ou d'import | En général à retirer ; pour les transferts demandés par l'utilisateur, Google renvoie vers les tâches de transfert de données lancées par l'utilisateur |
camera, microphone, phoneCall | SDK d'appel vidéo ou vocal | Uniquement pour de vraies fonctionnalités d'appel |
health / FOREGROUND_SERVICE_HEALTH | Bibliothèques de suivi sportif | Uniquement pendant que l'utilisateur enregistre activement une séance |
specialUse | Rare, code sur mesure | Exige une justification écrite et fait l'objet d'un examen ; ce n'est pas un raccourci pour éviter un type qui convient |
Excellente façon de convertir son app web en app native ! Un délai très court, et un super moyen de mettre ses apps dans les stores sans devoir développer une app native complète !
Une heure pour le ménage et une vidéo par type que vous conservez.
Dans Android Studio, ouvrez AndroidManifest.xml, passez à l'onglet Merged Manifest et cherchez foregroundServiceType et FOREGROUND_SERVICE. Dans la Play Console, l'explorateur d'app bundles liste les autorisations que Google a extraites de votre bundle.
Est-ce qu'un utilisateur le lance, et est-ce que l'utilisateur le remarque pendant qu'il tourne ? Si aucune des deux n'est vraie pour une fonctionnalité que votre app propose réellement, le service n'a rien à faire dans l'app.
Pour le service de localisation de WebViewGold, mettez requireBackgroundLocation sur false et commentez les blocs FOREGROUND_SERVICE_LOCATION et GPSService (voir la documentation sur la géolocalisation pour Android). Pour une bibliothèque, retirez l'autorisation et son service avec les règles ci-dessous, puis testez la fonctionnalité fournie par cette bibliothèque ; retirer un service qu'une bibliothèque appelle encore peut la faire planter.
Faites un enregistrement d'écran sur un vrai appareil : ouvrez l'app, connectez-vous si nécessaire, touchez la commande qui démarre la fonctionnalité (par exemple un bouton Démarrer le suivi qui appelle backgroundlocationon://), montrez la notification permanente, quittez l'app pour que la tâche continue visiblement, puis arrêtez-la. Importez-la comme vidéo YouTube non répertoriée.
Sur la page Contenu de l'application, ouvrez la déclaration de service de premier plan et, pour chaque type, décrivez la fonctionnalité en une ou deux phrases, expliquez ce qui casse si la tâche est différée ou interrompue, choisissez le cas d'usage qui correspond à la vidéo et collez le lien.
Code de version plus élevé, nouveau bundle, et remplacez les anciens bundles sur les canaux de test. Un type que vous avez retiré ne devrait plus avoir besoin d'être déclaré dès qu'aucun bundle actif ne le contient. Le guide sur le niveau d'API cible explique pourquoi recompiler à partir du modèle actuel compte ici aussi.
Copiez le nom de classe exact depuis l'onglet Merged Manifest ; celui ci-dessous est un exemple fictif. Testez ensuite la fonctionnalité de la bibliothèque.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Retirer un type de service de premier plan que l'app n'utilise pas -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" tools:node="remove" />
<application>
<!-- Exemple fictif : utilisez le nom de classe affiché dans l'onglet Merged Manifest -->
<service android:name="com.example.somelibrary.SyncForegroundService" tools:node="remove" />
</application>
</manifest>Décrivez une fonctionnalité concrète, avec les mots qu'emploierait un utilisateur, et faites en sorte que la vidéo montre exactement ces étapes. Le modèle reste en anglais, car les examinateurs de Google lisent l'anglais.
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.
Parce qu'une autorisation FOREGROUND_SERVICE ou un service typé se trouve dans votre bundle, en général apporté par une bibliothèque ou un bloc du modèle dont vous n'avez pas besoin. Trouvez-le dans le manifeste fusionné et retirez-le ; s'il ne reste rien, la déclaration n'est plus nécessaire.
Non. OneSignal, Firebase Cloud Messaging et Pushwoosh délivrent les notifications via le système, sans service de premier plan dans votre app, et les rappels locaux programmés ne sont pas non plus un cas d'usage de service de premier plan.
specialUse est destiné aux tâches qu'aucun autre type ne couvre, et Google examine la justification écrite. L'utiliser pour quelque chose qui correspond clairement à un autre type, comme location ou mediaPlayback, appelle un refus.
Elle commence au milieu de la fonctionnalité, saute l'action de l'utilisateur qui démarre le service, montre un autre parcours que le cas d'usage choisi, ou ne s'ouvre pas parce que le lien est privé. Gardez-la courte, linéaire et visible par toute personne disposant du lien.
Non. Google exige un niveau d'API cible récent pour les nouvelles apps et les mises à jour, donc chaque app actuelle cible Android 14 ou plus récent et a besoin de la déclaration dès qu'elle utilise des services de premier plan.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.