כדי לכבד את פרטיות המשתמשים, מפתחי אפליקציות מומלצים לבקש רק הרשאות מיקום כלליות. אפליקציות שזקוקות למיקום משוער גס בדרך כלל משתמשות במיקום הרשת (FLP) כי הוא מהיר וצורך פחות חשמל.
בהשוואה למכשירים ניידים מבוססי Android, יכול להיות שיהיה קשה יותר לקבל מיקום ברשת באפליקציות לכלי רכב. אפשר להשתמש בשני ממשקי API של Android:
ב-LocationManager API צריך לזהות במפורש את ספק המיקום המועדף.
Google Play Services API מציע דרך פשוטה יותר לעבוד עם מיקום, עם ההשקה של Fused Location Provider (FLP).
אפליקציות רבות לכלי רכב משתמשות ב-FLP מ-Google Play Services API (GPS) במקום ב-LM. FLP בוחרת את ספק המיקום האופטימלי על סמך הקריטריונים והמדיניות של בקשות המיקום (עוצמה ודיוק) שנדרשים לרכב.
במקום זאת, אפשר לבקש באופן מפורש את הערך NETWORK_PROVIDER ב-LM ולהשתמש בו, וגם את הערך GPS_PROVIDER למיקומי כוונון עדינים, תוך שימוש בהרשאות android.permission.ACCESS_FINE_LOCATION. ב-API 31, ה-FUSED_PROVIDER, שקודם היה אפשר לגשת אליו רק דרך ה-GPS API, זמין עכשיו כספק מיקום ל-LM. אפשר לראות הטמעה פשוטה יותר של FLP במאמר FusedLocationProvider.java.
אפשר להשתמש ב-GPS_PROVIDER עם הרשאות גסות בלבד, אבל המסגרת גורמת לירידה מלאכותית ברמת הדיוק כדי להתאים לציפיות. לא כדאי למפתחים לטרגט לטלפונים עם Android כי הזמינות הכוללת נמוכה, ולרוב זמן האחזור של מיקום משוער ארוך יותר.
מיקום ברשת ברכב
ה-NETWORK_PROVIDER שמשמש בטלפונים עם Android (עם Google Mobile Services) השתנה מקביעה של מיקום על סמך אנטנות סלולריות בקרבת מקום בלבד, לשימוש גם בנקודות גישה ל-Wi-Fi או אפילו בסמנים של Bluetooth (BT). יכול להיות שצריך חיבור נתונים כדי להשתמש ב-NETWORK_PROVIDER.
באפליקציות לכלי רכב, האילוצים על המכשירים משתנים. מכיוון ש-GNSS פועל בדרך כלל, לא נצברות קנסות בגלל צריכת חשמל וסוללה מוגברת. כתוצאה מכך, זמן הפעולה התקינה של IVI לא נפגע. אנחנו שואפים למזער את כמות הנתונים שמתחלפים עם השרתים שלנו.
לכן, הרבה אפליקציות משתמשות ב-FLP מ-Play API במקום ב-LM ישירות, כי FLP מבצע באופן אוטומטי את הדבר החכם על ידי שימוש בספק המיקום שהכי מתאים לעמוד בקריטריונים או בכללי המדיניות של בקשות המיקום (כלומר, עוצמה ודיוק).
בניגוד למכשירים ניידים, לעתים רחוקות נראית קפיצה של כלי רכב ממקום אחד למקום אחר. מיקום הרכב ידוע ברוב הזמן מתחת למכסה המנוע.
ספק מיקום ברשת
רוב כלי הרכב לא מטמיעים את ממשקי ה-API הנדרשים של הטלפון כדי לקבל את המידע הנדרש על מזהה תא (ועוצמת האות). כתוצאה מכך, וגם כי אנחנו מפחיתים את השימוש בנתונים, אנחנו לא מספקים הטמעה פונקציונלית נוספת של NLP.
ספק מיקום משולב
בנוסף לשימוש חכם בספקי רשתות ו-GPS לפי הצורך, FLP לנייד משלב מידע מחישנים אחרים כדי לשפר עוד יותר את איכות המיקומים. לעומת זאת, ההטמעה הנוכחית של 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" />
הגישה הזו מבטיחה תאימות מקסימלית למכשירים בתחומים שונים, וכתוצאה מכך זמינות מקסימלית של האפליקציה ללא הבדלים בקוד לקבלת מיקומי מודעות לפי הצורך.