כדי לכבד את פרטיות המשתמשים, מומלץ למפתחי אפליקציות לשלוח בקשות להצעת מחיר בסכום משוער בלבד הרשאות מיקום. אפליקציות שנדרש להן מיקום משוער משוער בדרך כלל להשתמש במיקום הרשת (FLP) כי הוא מהיר וצורך פחות חשמל.
בהשוואה למכשירים ניידים מבוססי Android, מיקום הרשת באפליקציות לכלי רכב יכול להיות מאתגר יותר. אפשר להשתמש בשני ממשקי API של Android:
LocationManager API מחייב לציין באופן מפורש את המועדף ספק המיקום.
עם Google Play Services API אתם יכולים: לעבוד עם מיקום באמצעות מבוא ל-Fused Location Provider (FLP).
אפליקציות רבות לכלי רכב משתמשות ב-FLP מ-API של Google Play Services (GPS) במקום LM. מערכת FLP בוחרת את ספק המיקום האופטימלי על סמך בקשת המיקום קריטריונים ומדיניות (הספק ודיוק) הנדרשים לרכב.
אפשר במקום זאת לבקש במפורש להשתמש
NETWORK_PROVIDER ב-LM, וגם
GPS_PROVIDER למיקומים מדויקים, שמתחילה ב-
android.permission.ACCESS_FINE_LOCATION
הרשאות. ב-API 31, FUSED_PROVIDER
היה זמין בעבר רק דרך ממשק API של GPS,
בתור ספק מיקום ל-LM. אפשר להציג
של FLP,
FusedLocationProvider.java
אמנם ניתן להשתמש ב-GPS_PROVIDER עם הרשאות הרשאה גסות בלבד, אבל
היא פוחתת באופן מלאכותי את רמת הדיוק בהתאם לציפיות,
הוא לא הגיוני למפתחים שמטרגטים טלפונים עם Android,
הזמינות נמוכה ולרוב איטית יותר כדי להשיג מיקום גס.
מיקום הרשת בכלי רכב
לNETWORK_PROVIDER שבשימוש בטלפונים עם Android (עם שירותי Google Mobile) יש
השתנה מקביעת מיקום רק על סמך מגדלי תקשורת קרובים
להשתמש גם בנקודות גישה ל-Wi-Fi או אפילו במשואות Bluetooth (BT). שימוש ב-
יכול להיות שיידרש חיבור לחבילת הגלישה כדי להשתמש ב-NETWORK_PROVIDER.
באפליקציות לכלי רכב, מגבלות המכשיר שונות. מכיוון ש-GNSS בדרך כלל פועל, לא יחולו סנקציות בגלל שימוש מוגבר בסוללה ובסוללה. בתור זמן הפעולה התקינה של IVI אינו נפגע. אנחנו שואפים לצמצם את השימוש בנתונים את השרתים שלנו.
לכן הרבה אפליקציות משתמשות ב-FLP מ-Play API במקום ב-LM ישירות כ-FLP עושה באופן אוטומטי את הדבר החכם באמצעות ספק המיקום שיכול לעמוד בקריטריונים/מדיניות של בקשת מיקום (בעיקר כוח ודיוק) במסגרת ממש את הכובע.
בניגוד למכשירים ניידים, רק לעיתים רחוקות כלי רכב עוברים ממקום אחד אל אחר. מיקום הרכב ידוע מתחת למכסה הקדמי בדרך כלל.
ספק מיקום ברשת
ברוב כלי הרכב אין ממשקי API שנדרשים בתחום הטלפוניה כדי לקבל את המידע הנדרש. לפי מזהה תא (ועוצמת האות). כתוצאה מכך, ובגלל שאנחנו מצמצמים את היקף הנתונים לשימוש, לא מסופקת יישום פונקציונלי נוסף של NLP.
ספק מיקום משולב
ה-FLP בנייד, בנוסף לשימוש חכם בספקי רשתות ו-GPS בתור
מתאימה, ממזגת מידע מחיישנים אחרים כדי לשפר עוד יותר את
איכות המיקומים. היישום הנוכחי של טופס ה-FLP של Automotive
והצד השני מנצל את ההנחות והשימושים שהוזכרו למעלה
GPS_PROVIDER כמקור בסיסי כל הזמן. הוא מזעזע את המיקומים
מ-GNSS, ומוסיפים כמה שגיאות כדי שיהיו יותר לא מדויקות במקרה הצורך. לדוגמה,
כאשר מיקומים משוערים ניתנים ללקוח.
לכן, במקרים מעטים מאוד, משך הזמן עד המיקום הראשון יהיה זמין. לדוגמה, בפעם הראשונה שבה נתקלתם ברכב, כדי לדייק יותר, נעשה שימוש במערכת המשנה של המיקום שלה או לאחר גרירה.
עיצוב אפליקציות כך שיטרגטו שימושים בניידים ובכלי רכב
מומלץ שאפליקציות יטרגטו מכשירים ניידים וגם מכשירים לרכב שלא
דורשת איכות גבוהה יותר של בקשה לקבלת דיוק
android.permission.ACCESS_COARSE_LOCATION
בלבד ולחזור להשתמש ב-FLP
כשזה אפשרי. לחלופין, כתחליף אחרון, יש להשתמש ישירות ב-GPS_PROVIDER
עם אותן הרשאות. המסגרת פוחתת את הדיוק של
המיקום ב-GNSS בהתאם לציפיות של ה-API. למידע נוסף, ראו דיוק.
בנוסף, האפליקציות האלה צריכות להצהיר במפורש על
android.hardware.location.network
מאפיין אופציונלי במניפסט.
לדוגמה:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
הגישה הזו מבטיחה תאימות מקסימלית למכשירים מהענפים השונים וגם כלומר, בזמינות מקסימלית של האפליקציה ללא הבדלים בקוד במיקומי המודעות הרצויים.