Pour respecter la confidentialité des utilisateurs, les développeurs d'applications sont invités à ne demander que des autorisations de localisation approximatives. 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 vous oblige à identifier explicitement le fournisseur de position préféré.
L'API Google Play Services vous permet de travailler plus simplement avec la position grâce à l'introduction de Fused Location Provider (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 position optimal en fonction des critères et des règles de requête de localisation (puissance et précision) dont le véhicule a besoin.
Vous pouvez plutôt 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 position 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'autorisation approximatifs uniquement, le framework dégrade artificiellement la précision pour s'aligner sur les attentes. Cela n'a guère de sens pour les développeurs qui ciblent les téléphones Android, car la disponibilité globale est faible et l'obtention d'une position approximative est souvent plus lente.
Emplacement du réseau dans le secteur automobile
La NETWORK_PROVIDER utilisée sur les téléphones Android (avec les services mobiles Google) ne détermine plus la position uniquement en fonction des antennes-relais de téléphonie mobile à proximité, mais utilise également des points d'accès Wi-Fi ou même des 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 d'une consommation d'énergie et de batterie accrue. Par conséquent, la disponibilité de l'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 à partir de l'API Play au lieu de LM directement, car FLP effectue automatiquement la meilleure action en utilisant le fournisseur de position le plus à même de répondre aux critères/règles de requête de position (à savoir, la puissance et la précision).
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 sous le capot.
Fournisseur d'emplacement 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, le FLP mobile fusionne les informations provenant d'autres capteurs pour améliorer encore la qualité des positions. En revanche, l'implémentation actuelle de la FLP d'Automotive profite 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 inexact lorsqu'il le faut. 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 longtemps 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 cibler les utilisations mobiles et automobiles
Nous recommandons aux applications ciblant les appareils mobiles et automobiles qui ne nécessitent pas une qualité de précision plus élevée d'utiliser android.permission.ACCESS_COARSE_LOCATION
uniquement et de recourir à FLP lorsqu'il est disponible. Vous pouvez également utiliser GPS_PROVIDER directement avec les mêmes autorisations en dernier recours. Le framework dégrade la précision de la position GNSS sous-jacente pour s'aligner sur les attentes de l'API. Pour en savoir plus, consultez la section Précision.
De plus, ces applications doivent déclarer explicitement la fonctionnalité facultative android.hardware.location.network 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 différents secteurs et, par conséquent, une disponibilité maximale des applications, sans différence de code pour obtenir des positions en cas de besoin.