Pour respecter la confidentialité des utilisateurs, les développeurs d'applications sont encouragés à demander uniquement des autorisations de localisation grossières. Les applications qui nécessitent une position approximative approximative utilisent généralement la localisation réseau (FLP), car elle est rapide et consomme moins d'énergie.
Par rapport aux appareils mobiles basés sur Android, la localisation réseau dans les applications automobiles peut s'avérer plus difficile. Vous pouvez utiliser deux API Android :
L'API LocationManager vous oblige à identifier explicitement le fournisseur de localisation préféré.
L'API des services Google Play offre un moyen plus simplifié de travailler avec la localisation avec l'introduction du fournisseur de localisation fusionné (FLP).
De nombreuses applications automobiles utilisent FLP à partir de l'API Google Play Services (GPS) au lieu de LM. FLP sélectionne le fournisseur de localisation optimal en fonction des critères de demande de localisation et des politiques (puissance et précision) nécessaires au véhicule.
Vous pouvez plutôt choisir de demander et d'utiliser explicitement NETWORK_PROVIDER dans LM, ainsi que GPS_PROVIDER pour les positions fines, qui utilise les autorisations android.permission.ACCESS_FINE_LOCATION . 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 voir une implémentation plus simple de FLP, dans FusedLocationProvider.java .
Bien qu'il soit possible d'utiliser GPS_PROVIDER uniquement avec des droits d'autorisation grossiers, le framework dégrade artificiellement la précision pour s'aligner sur les attentes. Cela n'a pas de sens pour les développeurs ciblant les téléphones Android, car la disponibilité globale est faible et souvent plus lente pour obtenir une position grossière.
Localisation du réseau dans l'automobile
Le NETWORK_PROVIDER utilisé sur les téléphones Android (avec les services mobiles Google) est passé de la détermination de l'emplacement basée uniquement sur les tours de téléphonie cellulaire à proximité à l'utilisation également de points d'accès Wi-Fi ou même de balises Bluetooth (BT). L'utilisation de NETWORK_PROVIDER peut nécessiter une connexion de données.
Pour les applications automobiles, les contraintes des appareils diffèrent. Étant donné que le GNSS est normalement activé, aucune pénalité n'est encourue en raison de l'augmentation de la puissance et de l'utilisation de la batterie. En conséquence, la disponibilité d’IVI n’est pas compromise. Nous nous efforçons de minimiser les données échangées avec nos serveurs.
De nombreuses applications utilisent donc FLP depuis l'API Play au lieu de LM directement, car FLP fait automatiquement la chose intelligente en utilisant le fournisseur de localisation le plus à même de satisfaire les critères/politiques de demande de localisation (à savoir la puissance et la précision) sous le capot.
Contrairement aux appareils mobiles, les véhicules semblent rarement sauter d’un endroit à un autre. La position du véhicule est connue sous le capot la plupart du temps.
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 identifiant de cellule (et la force 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.
Fournisseur de localisation fusionné
Le FLP mobile, en plus d'utiliser intelligemment les fournisseurs de réseau et de GPS, le cas échéant, fusionne les informations provenant d'autres capteurs pour améliorer encore la qualité des emplacements. D'autre part, la mise en œuvre actuelle du FLP de l'automobile tire parti des hypothèses susmentionnées et utilise à tout moment GPS_PROVIDER comme source sous-jacente. Il truque les positions du GNSS, ajoutant quelques erreurs pour être plus inexact si nécessaire. Par exemple, lorsque des emplacements grossiers sont fournis à un client.
Ainsi, dans de très rares cas, le délai avant que le premier poste soit disponible peut être plus long que d’habitude. Par exemple, lors de la toute première utilisation d'un véhicule ou, plus précisément, de son sous-système de localisation ou après avoir été remorqué.
Concevoir des applications pour cibler les usages mobiles et automobiles
Nous recommandons aux applications ciblant les appareils mobiles et automobiles qui ne nécessitent pas une qualité de précision supérieure de demander uniquement android.permission.ACCESS_COARSE_LOCATION et de recourir à FLP lorsqu'il est disponible. Alternativement, en dernier recours, utilisez GPS_PROVIDER directement avec les mêmes autorisations. Le cadre dégrade la précision de la position GNSS sous-jacente pour s'aligner sur les attentes de l'API. Pour en savoir plus, voir Précision .
De plus, ces applications doivent déclarer explicitement la fonctionnalité android.hardware.location.network facultative dans leur manifeste. Par 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 des applications sans différences de code pour obtenir des positions en cas de besoin.