Refus Google Play
La plupart des apps web qui demandent la localisation n'en ont besoin que pendant que l'utilisateur regarde l'écran. Si c'est votre cas, la solution consiste à retirer la localisation en arrière-plan du build, pas à argumenter avec Google. Si le suivi app fermée est vraiment votre fonctionnalité principale, ce guide montre ce que la déclaration, l'information dans l'app et la vidéo de 30 secondes doivent montrer.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
La localisation en arrière-plan signifie que votre app reçoit la position alors qu'elle n'est pas visible : l'écran est éteint, une autre app est ouverte ou votre app a été balayée hors de l'écran. Google ne l'autorise que si elle fait partie de la fonctionnalité principale de l'app, c'est-à-dire que l'app serait cassée sans elle, et qu'elle apporte à l'utilisateur un bénéfice clair, comme la sécurité, la santé et le sport, ou une tâche que l'utilisateur est en train d'accomplir. Le confort, la personnalisation, l'analytics et la publicité ne sont pas admissibles, et les demandes faites uniquement pour la publicité ou l'analytics sont refusées. L'utilisateur doit raisonnablement s'attendre au suivi, et la même expérience ne doit pas être possible au premier plan.
Les apps qui la conservent remplissent une déclaration dans la Play Console (Contenu de l'application → Autorisations sensibles de l'application → Autorisations de localisation). Elle nomme une seule fonctionnalité basée sur la localisation, explique pourquoi cette fonctionnalité a besoin de l'accès en arrière-plan et renvoie vers une vidéo de 30 secondes maximum. Il vous faut aussi une information bien visible dans l'app avant la demande d'autorisation, et l'examinateur doit pouvoir atteindre la fonctionnalité. Les détails figurent sur la page d'aide de Google sur la localisation en arrière-plan.
Soit la Play Console bloque la version tant que la déclaration de localisation n'est pas remplie, soit la déclaration elle-même est refusée. Les motifs que liste Google correspondent à ce que les examinateurs voient dans les apps encapsulées : la fonctionnalité n'est pas claire ou plusieurs fonctionnalités ont été déclarées, la fonctionnalité n'a pas pu être vérifiée (souvent à cause de la connexion), l'information dans l'app manque ou est incomplète, la politique de confidentialité ne mentionne pas la localisation en arrière-plan, ou la fonctionnalité n'est tout simplement pas admissible. Quand l'autorisation n'est pas nécessaire, la notification vous demande de la retirer de tous les canaux, y compris les tests fermés et ouverts.
| Fonctionnalité | Verdict | Ce qu'il faut utiliser |
|---|---|---|
| Recherche de magasins, liste « près de moi », bouton d'enregistrement | Premier plan uniquement | Géolocalisation HTML5 pendant que l'écran est ouvert |
| Client qui suit un livreur sur une carte | Premier plan uniquement ; Google cite le suivi de livraison côté client comme un échec typique | Carte en direct pendant que l'écran est ouvert, push pour les changements de statut |
| Livreur ou technicien qui partage sa position pendant son service | Peut être admissible si c'est le cœur de l'app | Un suivi que l'utilisateur démarre et arrête, avec une notification permanente |
| Enregistrement d'une course à pied ou à vélo écran éteint | Peut être admissible (sport) | Un suivi démarré pour la séance et arrêté à sa fin |
| Alerte de sécurité quand un proche quitte une zone | Peut être admissible (sécurité) | Une seule fonctionnalité clairement déclarée, avec une information dans l'app |
| Actualités locales, météo ou offres par région | Pas admissible | Localisation au premier plan ou approximative, ou un choix de ville |
| Ciblage publicitaire, analytics, attribution | Jamais | Supprimez-la |
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 !
requireLocation active la localisation tout court ; requireBackgroundLocation ajoute le suivi en arrière-plan sous Android et ne prend effet que si requireLocation vaut true. Voir la documentation sur la géolocalisation pour Android.
Le suivi en arrière-plan nécessite aussi l'autorisation FOREGROUND_SERVICE_LOCATION et le bloc GPSService dans AndroidManifest.xml, que vous décommentez pour activer la fonctionnalité. S'ils sont actifs, la Play Console voit un service de localisation.
backgroundlocationon:// et backgroundlocationoff:// démarrent et arrêtent le suivi depuis votre app web. Les appeler depuis une action de l'utilisateur est ce qui rend le suivi déclenché par l'utilisateur.
Une bibliothèque de cartes, d'analytics ou de geofencing peut ajouter ACCESS_BACKGROUND_LOCATION au manifeste fusionné sans vous prévenir. L'onglet Merged Manifest d'Android Studio montre laquelle.
Environ trente minutes, plus le temps d'examen.
Mettez requireBackgroundLocation sur false dans Config.java. Gardez requireLocation sur true si votre app web utilise l'API de géolocalisation pendant qu'elle est ouverte ; mettez-la aussi sur false si l'app n'utilise pas du tout la localisation.
Commentez (ou supprimez) l'autorisation FOREGROUND_SERVICE_LOCATION et le bloc GPSService dans AndroidManifest.xml, et retirez toute entrée ACCESS_BACKGROUND_LOCATION. Si une bibliothèque l'ajoute, supprimez-la avec tools:node="remove" comme le montre le guide sur les autorisations.
Supprimez les appels à backgroundlocationon:// de votre app web, ainsi que tout texte dans l'app ou sur la fiche du store qui promet un suivi app fermée.
Demandez la localisation depuis l'écran de la fonctionnalité après une courte explication, comme le décrit le guide sur l'information bien visible. La localisation au premier plan via l'API HTML5 continue de fonctionner exactement comme avant pendant que l'app est ouverte.
Générez un nouveau bundle avec un code de version plus élevé dans Android Studio ou le Cloud Builder, vérifiez dans l'explorateur d'app bundles que l'autorisation en arrière-plan a disparu, et remplacez aussi les anciens builds sur les canaux de tests internes, fermés et ouverts.
Si la Play Console affiche encore la déclaration des autorisations de localisation, mettez-la à jour pour indiquer que l'app n'accède plus à la localisation en arrière-plan, puis envoyez les modifications pour examen.
Uniquement si le suivi app fermée est la raison d'être de votre app. Toutes ces conditions doivent être remplies en même temps.
backgroundlocationon://) et Arrêter (backgroundlocationoff://). Le suivi ne démarre jamais en silence.Une fonctionnalité, un objectif, l'utilisateur aux commandes. Remplacez l'exemple par votre propre fonctionnalité, mais gardez la structure. Le modèle reste en anglais, car les examinateurs de Google lisent l'anglais.
Feature: Shift tracking for couriers. What it does: While a courier is on shift, [App name] shares the courier's location with the dispatch team every [30 seconds], so customers receive accurate arrival times and dispatchers can reassign orders when a courier is delayed. Why it needs background access: Couriers drive with the phone locked or with a navigation app in the foreground. If location stopped while [App name] is not visible, dispatch would lose the courier for the whole drive, which defeats the core purpose of the app. How the user controls it: The courier taps Start shift. The app shows an in-app disclosure and the Android permission prompt, then an ongoing notification while tracking runs. Tapping End shift stops tracking immediately. No location is collected outside a shift. Video: [YouTube link], [28] seconds, showing the disclosure, the permission prompt, the start of a shift, the app in the background with tracking active, and the end of the shift. Test account: see Sign-in details, instruction set 'Courier'.
requireBackgroundLocation, les blocs du manifeste et les appels à backgroundlocationon:// concordent avec cette décision.Seulement si la fonctionnalité est admissible. La vidéo prouve comment fonctionne une fonctionnalité admissible ; elle ne peut pas transformer une recherche de magasins ou un fil personnalisé en usage principal en arrière-plan.
Non. L'API de géolocalisation HTML5 fonctionne pendant que l'app est ouverte tant que requireLocation vaut true et que les autorisations de localisation au premier plan restent dans le manifeste. Seul le suivi app fermée disparaît.
Non. Le client regarde la carte pendant que l'écran est ouvert, ce qui est un usage au premier plan, et Google cite le suivi de livraison côté client comme un échec typique. Envoyez plutôt des notifications push pour les changements de statut.
S'il continue de collecter la position pendant que l'utilisateur est ailleurs, Google lui applique les exigences de la localisation en arrière-plan. Un service de premier plan n'est acceptable que comme prolongement d'une action lancée par l'utilisateur, et il doit s'arrêter dès que cette tâche est terminée.
En général, un ancien bundle sur un canal de test la contient encore, ou la déclaration n'a pas été mise à jour. Remplacez chaque bundle actif et mettez à jour la déclaration, puis envoyez les modifications pour examen.
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.