כדי לכבד את פרטיות המשתמשים, מומלץ למפתחי אפליקציות לבקש רק הרשאות למיקום משוער. באפליקציות שצריכות מיקום משוער גס, בדרך כלל נעשה שימוש במיקום ברשת (FLP) כי הוא מהיר וצורכת פחות חשמל.
בהשוואה למכשירים ניידים מבוססי Android, קביעת מיקום ברשת באפליקציות לרכב יכולה להיות מורכבת יותר. אפשר להשתמש בשני ממשקי API של Android:
LocationManager API או LM מחייבים אתכם לציין במפורש את ספק המיקום המועדף.
Google Play Services API מציע דרך פשוטה יותר לעבוד עם מיקום באמצעות ההשקה של ספק מיקום משולב (FLP).
הרבה אפליקציות לרכב משתמשות ב-FLP מ-Google Play Services (GPS) API במקום ב-LM. ה-FLP בוחר את ספק המיקום האופטימלי על סמך הקריטריונים והמדיניות (הספק והדיוק) שנדרשים לרכב.
במקום זאת, אפשר לבקש במפורש להשתמש ב-NETWORK_PROVIDER ב-LM, וגם ב-GPS_PROVIDER למיקומים מדויקים, שמשתמש בהרשאות android.permission.ACCESS_FINE_LOCATION. ב-API 31, FUSED_PROVIDER, שבעבר הייתה גישה אליו רק דרך GPS API, זמין עכשיו כספק מיקום ל-LM. אפשר לראות הטמעה פשוטה יותר של FLP בכתובת FusedLocationProvider.java.
אפשר להשתמש ב-GPS_PROVIDER רק עם הרשאות מיקום גסות, אבל המסגרת מפחיתה באופן מלאכותי את הדיוק כדי להתאים לציפיות. לכן, אין טעם להשתמש ב-GPS_PROVIDER למפתחים שמטרגטים טלפונים עם Android, כי הזמינות הכוללת נמוכה ולעתים קרובות לוקח יותר זמן לקבל מיקום גס.
מיקום ברשת בכלי רכב
ה-NETWORK_PROVIDER שמשמש בטלפונים עם Android (עם שירותי Google לנייד) השתנה. בעבר, המיקום נקבע רק על סמך אנטנות סלולריות בקרבת מקום, אבל עכשיו המיקום נקבע גם על סמך נקודות גישה ל-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. מידע נוסף זמין במאמר בנושא דיוק.
בנוסף, האפליקציות האלה צריכות להצהיר במפורש על התכונה optional android.hardware.location.network במניפסט שלהן.
לדוגמה:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
הגישה הזו מבטיחה תאימות מקסימלית למכשירים בתחומים שונים, ולכן זמינות מקסימלית של האפליקציה ללא הבדלים בקוד כדי לקבל מיקומים כשצריך.