Pour respecter la confidentialité des utilisateurs, les développeurs d'applications sont invités à ne demander que des les autorisations d'accéder à la position. Les applications qui nécessitent une position approximative utiliser l'emplacement réseau (FLP), car il est rapide et consomme moins d'énergie.
Par rapport aux appareils mobiles Android, la localisation réseau dans les applications automobiles peut s'avérer plus difficile. Vous pouvez utiliser deux API Android:
Avec l'API LocationManager, vous devez identifier explicitement les préférences fournisseur de services de localisation.
L'API des services Google Play offre une méthode plus simple pour : Utiliser la localisation grâce à l'introduction de Fused Location Provider (FLP).
De nombreuses applications automobiles utilisent le FLP de l'API des services Google Play (GPS) au lieu de LM. FLP sélectionne le fournisseur de localisation le plus adapté en fonction de la demande de localisation les critères et règles (puissance et précision) requis par le véhicule.
Vous pouvez 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, FUSED_PROVIDER,
auparavant accessibles uniquement via l'API GPS, est désormais
comme fournisseur de géolocalisation. Vous pouvez consulter un modèle plus simple
l'implémentation de FLP,
FusedLocationProvider.java
Bien qu'il soit possible d'utiliser GPS_PROVIDER avec des droits d'autorisation approximatifs uniquement,
le framework dégrade artificiellement la justesse pour s'aligner sur les attentes,
n'a pas d'intérêt pour les développeurs
ciblant les téléphones Android, car
la disponibilité est faible et souvent plus lente pour obtenir une position approximative.
Emplacement du réseau dans le secteur automobile
L'NETWORK_PROVIDER utilisé sur les téléphones Android (avec les services Google Mobile) présente
est passé de déterminer la position uniquement en fonction des antennes-relais situées à proximité.
utilisent également des points d'accès Wi-Fi
ou même des balises Bluetooth (BT). Utilisation de
NETWORK_PROVIDER peut nécessiter une connexion de données.
Pour les applications automobiles, les contraintes liées aux appareils diffèrent. Comme le GNSS est normalement activé, aucune pénalité n'est engagée en raison d'une utilisation accrue de la puissance et de la batterie. En tant que résultat, le temps d’activité d’IVI n’est pas compromis. Nous nous efforçons de réduire au maximum les échanges de données. avec nos serveurs.
De nombreuses applications utilisent donc FLP à partir de l'API Play au lieu de LM directement en tant que FLP. réalise automatiquement l'activité intelligente en utilisant le fournisseur de localisation le plus à même respecter les critères/règles de demande de localisation (à savoir la puissance et la précision) sous sous le capot.
Contrairement aux appareils mobiles, les véhicules semblent rarement sauter d'un endroit à un autre une autre. La position du véhicule est connue sous le capot la plupart du temps.
Fournisseur de géolocalisation
La plupart des véhicules n'implémentent pas les API de téléphonie requises pour obtenir les informations nécessaires en fonction de l'ID de la cellule GSM (et de l'intensité du signal). Par conséquent, et comme nous minimisons les données aucune implémentation fonctionnelle supplémentaire du TLN n'est fournie.
Fused Location Provider
Le FLP du mobile, en plus d'utiliser intelligemment
les fournisseurs de réseau et de GPS
les informations provenant d'autres capteurs sont fusionnées pour améliorer
la qualité des emplacements. L'implémentation actuelle du programme FLP d'Automotive
tire parti des hypothèses mentionnées ci-dessus et utilise
GPS_PROVIDER en tant que source sous-jacente à tout moment. Cela fausse les positions
à partir du GNSS, en ajoutant quelques erreurs
pour être plus imprécis si nécessaire. Par exemple :
lorsque des emplacements approximatifs sont fournis à un client.
Par conséquent, dans de très rares cas, la durée d'exécution de l'événement soit disponible en première position. 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é.
Concevez des applications pour cibler les usages mobiles et automobiles
Nous recommandons que les applications ciblant les appareils mobiles et les appareils automobiles qui ne
nécessitent une requête de plus grande précision
android.permission.ACCESS_COARSE_LOCATION
uniquement et utiliser FLP
le cas échéant. Vous pouvez également utiliser directement GPS_PROVIDER en dernier recours
avec les mêmes autorisations. Le framework dégrade la précision de l'infrastructure sous-jacente
Position du GNSS pour qu'elle s'aligne sur les attentes des API. Pour en savoir plus, consultez la section Précision.
De plus, ces applications doivent déclarer explicitement
android.hardware.location.network
fonctionnalité facultative dans son 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. Vous bénéficiez ainsi d'une disponibilité maximale de l'application sans aucune différence de code pour obtenir en fonction des besoins.