Pour respecter la confidentialité des utilisateurs, les développeurs d'applications sont encouragés à ne demander que des autorisations de localisation approximative. Les applications qui ont besoin d'une position approximative utilisent généralement la localisation réseau (FLP), car elle est rapide et consomme moins d'énergie.
Par rapport aux appareils mobiles Android, la localisation réseau dans les applications automobiles peut être plus difficile. Vous pouvez utiliser deux API Android :
L'API LocationManager ou LM vous oblige à identifier explicitement le fournisseur de localisation préféré.
L'API Google Play Services vous permet de travailler plus facilement avec la localisation grâce à l'introduction de Fused Location Provider (FLP).
De nombreuses applications automobiles utilisent FLP à partir de l'API des services Google Play (GPS) au lieu de LM. FLP sélectionne le fournisseur de localisation optimal en fonction des critères et des règles de la demande de localisation (puissance 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 les autorisations android.permission.ACCESS_FINE_LOCATION. Dans l'API 31, FUSED_PROVIDER, qui n'était auparavant accessible que via l'API GPS, est désormais disponible en tant que fournisseur de localisation pour LM. Vous pouvez consulter une implémentation plus simple de FLP dans FusedLocationProvider.java.
Bien qu'il soit possible d'utiliser GPS_PROVIDER avec des droits d'accès approximatifs uniquement, le framework dégrade artificiellement la précision pour répondre aux attentes. Cela n'a donc 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.
Emplacement du réseau dans le secteur automobile
Le NETWORK_PROVIDER utilisé sur les téléphones Android (avec les services mobiles Google) a changé. Il 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 (BT). 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 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 FLP à partir de l'API Play au lieu de LM directement, car FLP effectue automatiquement la bonne chose en utilisant le fournisseur de localisation le mieux à même de répondre aux critères/règles de demande de localisation (à savoir la puissance et la précision) en coulisses.
Contrairement aux appareils mobiles, les véhicules semblent rarement sauter d'un endroit à un autre. La position du véhicule est généralement connue en interne.
Fournisseur de localisation 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 l'intensité 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
En plus d'utiliser intelligemment les fournisseurs de réseau et de GPS selon les besoins, le FLP mobile fusionne les informations provenant d'autres capteurs pour améliorer encore la qualité des positions. L'implémentation actuelle de la FPL Automotive, en revanche, tire parti des hypothèses susmentionnées et utilise GPS_PROVIDER comme source sous-jacente en permanence. Il modifie les positions GNSS en ajoutant des erreurs pour les rendre moins précises 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 un remorquage.
Concevoir des applications pour les appareils mobiles et automobiles
Nous recommandons aux applications ciblant les appareils mobiles et automobiles qui ne nécessitent pas un niveau de précision plus élevé de demander android.permission.ACCESS_COARSE_LOCATION
uniquement et de revenir à l'utilisation de FLP lorsque cela est possible. Vous pouvez également, en dernier recours, utiliser directement GPS_PROVIDER avec les mêmes autorisations. Le framework dégrade la précision de la position GNSS sous-jacente pour l'aligner sur les attentes de l'API. Pour en savoir plus, consultez Précision.
De plus, ces applications doivent déclarer explicitement la fonctionnalité android.hardware.location.network 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 verticaux et, par conséquent, une disponibilité maximale de l'application sans différence de code pour obtenir les positions si nécessaire.