Obtenir la position approximative

Pour respecter la confidentialité des utilisateurs, les développeurs d'applications sont encouragés à ne demander que des autorisations d'accès à la position approximative. Les applications qui ont besoin d'une position approximative utilisent généralement la position du réseau (FLP), car elle est rapide et consomme moins d'énergie.

Par rapport aux appareils mobiles Android, la position du réseau dans les applications automobiles peut être plus difficile à obtenir. Vous pouvez utiliser deux API Android :

  • L'API LocationManager (LM) vous oblige à identifier explicitement le fournisseur de localisation préféré.

  • L'API services Google Play offre un moyen plus simple de travailler avec la localisation grâce à l'introduction du Fused Location Provider (FLP).

De nombreuses applications automobiles utilisent le FLP des services Google Play (GPS) au lieu de LM. Le FLP sélectionne le fournisseur de localisation optimal en fonction des critères et des règles de la requête de localisation (alimentation et précision) nécessaires au véhicule.

Vous pouvez également choisir de demander et d'utiliser explicitement NETWORK_PROVIDER dans LM, ainsi que GPS_PROVIDER pour les positions précises, qui utilise android.permission.ACCESS_FINE_LOCATION autorisations. Dans l'API 31, le FUSED_PROVIDER, auparavant accessible uniquement via l'API GPS, est désormais disponible en tant que fournisseur de localisation pour LM. Vous pouvez consulter une implémentation plus simple du FLP dans FusedLocationProvider.java.

Bien qu'il soit possible d'utiliser GPS_PROVIDER avec des droits d'autorisation approximatifs uniquement, le framework dégrade artificiellement la précision pour répondre aux attentes. Cela n'a que peu de sens pour les développeurs ciblant les téléphones Android, car la disponibilité globale est faible et il est souvent plus lent d'obtenir une position approximative.

Position du réseau dans les applications automobiles

Le NETWORK_PROVIDER utilisé sur les téléphones Android (avec les services mobiles Google) ne détermine plus la position uniquement en fonction des antennes-relais à proximité, mais utilise également les points d'accès Wi-Fi, voire les balises Bluetooth. L'utilisation de NETWORK_PROVIDER peut nécessiter une connexion de données.

Pour les applications automobiles, les contraintes liées aux appareils sont différentes. Comme le GNSS est normalement activé, aucune pénalité n'est appliquée en raison de l'augmentation de la consommation d'énergie et de la batterie. Par conséquent, le temps d'activité de l'IVI n'est pas compromis. Nous nous efforçons de minimiser les données échangées avec nos serveurs.

De nombreuses applications utilisent donc le FLP de l'API Play au lieu de LM directement, car le FLP effectue automatiquement l'opération intelligente en utilisant le fournisseur de localisation le plus à même de répondre aux critères/règles de la requête de localisation (à savoir, l'alimentation et la précision) en arrière-plan.

Contrairement aux appareils mobiles, les véhicules semblent rarement sauter d'un endroit à un autre. La position du véhicule est connue en arrière-plan la plupart du temps.

Fournisseur de localisation du réseau

La plupart des véhicules n'implémentent pas les API de téléphonie requises pour obtenir les informations nécessaires sur un ID de cellule (et la puissance du signal). Par conséquent, et parce que nous minimisons l'utilisation des données, aucune implémentation fonctionnelle supplémentaire du NLP n'est fournie.

Fused Location Provider

Le FLP mobile, en plus d'utiliser intelligemment les fournisseurs de réseau et de GPS, fusionne les informations provenant d'autres capteurs pour améliorer encore la qualité des positions. L'implémentation actuelle du FLP automobile, quant à elle, tire parti des hypothèses susmentionnées et utilise GPS_PROVIDER comme source sous-jacente en permanence. Il falsifie les positions du GNSS, en ajoutant des erreurs pour être plus imprécis si nécessaire. Par exemple, lorsque des positions approximatives sont fournies à un client.

Par conséquent, dans de très rares cas, la première position peut être disponible plus tard que d'habitude. Par exemple, la toute première fois qu'un véhicule, ou plus précisément son sous-système de localisation, est utilisé ou après avoir été remorqué.

Concevoir des applications pour les utilisations mobiles et automobiles

Nous recommandons aux applications ciblant les appareils mobiles et automobiles qui ne nécessitent pas une précision de meilleure qualité de demander android.permission.ACCESS_COARSE_LOCATION uniquement et de revenir à l'utilisation du FLP lorsqu'il est disponible. Vous pouvez également, en dernier recours, utiliser GPS_PROVIDER directement avec les mêmes autorisations. Le framework dégrade la précision de la position GNSS sous-jacente pour répondre aux attentes de l'API. Pour en savoir plus, consultez la section Précision.

De plus, ces applications doivent déclarer explicitement la android.hardware.location.network fonctionnalité facultative dans leur fichier manifeste. Exemple :

<uses-feature android:name="android.hardware.location.network" android:required="false" />

Cette approche garantit une compatibilité maximale avec les appareils de tous les secteurs et, par conséquent, une disponibilité maximale des applications sans aucune différence de code pour obtenir des positions si nécessaire.