אחזור מיקום משוער

כדי לכבד את פרטיות המשתמשים, מומלץ למפתחי אפליקציות לבקש רק הרשאות למיקום משוער. אפליקציות שצריכות מיקום משוער גס בדרך כלל משתמשות במיקום ברשת (FLP) כי הוא מהיר וצורך פחות חשמל.

בהשוואה למכשירים ניידים מבוססי Android, קביעת מיקום ברשת באפליקציות לרכב יכולה להיות מורכבת יותר. אפשר להשתמש בשני ממשקי API של Android:

• ‫LocationManager API או LM מחייבים אתכם לציין במפורש את ספק המיקום המועדף.

• ‫Google Play Services API מציע דרך פשוטה יותר לעבוד עם מיקום באמצעות ההגדרה Fused Location Provider‏ (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 Mobile Services) השתנה. בעבר, המיקום נקבע רק על סמך מגדלי תקשורת סלולרית בקרבת מקום, אבל עכשיו המיקום נקבע גם על סמך נקודות גישה ל-Wi-Fi או אפילו משואות Bluetooth (BT). יכול להיות שיהיה צורך בחיבור נתונים כדי להשתמש ב-NETWORK_PROVIDER.

באפליקציות לרכב, אילוצי המכשיר שונים. מערכת GNSS פועלת בדרך כלל, ולכן לא חלים קנסות על שימוש מוגבר בחשמל ובסוללה. כתוצאה מכך, זמן הפעולה התקינה של מערכת ה-IVI לא נפגע. אנחנו משתדלים לצמצם את כמות הנתונים שמועברת לשרתים שלנו.

לכן, הרבה אפליקציות משתמשות ב-FLP מ-Play API במקום ב-LM ישירות, כי FLP מבצע באופן אוטומטי את הפעולה החכמה באמצעות ספק המיקום שיכול לספק את הקריטריונים או המדיניות של בקשת המיקום בצורה הטובה ביותר (כלומר, צריכת חשמל ודיוק) מתחת לפני השטח.

בניגוד למכשירים ניידים, רכבים כמעט אף פעם לא קופצים ממקום אחד למקום אחר. ברוב המקרים, מיקום הרכב ידוע מתחת לפני השטח.

ספק מיקום ברשת

ברוב כלי הרכב לא מוטמעים ממשקי ה-API הנדרשים לטלפוניה כדי לקבל את המידע הדרוש על מזהה התא (Cell ID) (ועוצמת האות). כתוצאה מכך, ומכיוון שאנחנו מצמצמים את השימוש בנתונים, לא מסופקת הטמעה פונקציונלית נוספת של NLP.

ספק מיקום משולב

בנוסף לשימוש חכם בספקי רשת ו-GPS לפי הצורך, ה-FLP לנייד משלב מידע מחיישנים אחרים כדי לשפר עוד יותר את איכות המיקומים. לעומת זאת, בהטמעה הנוכחית של FLP ב-Automotive נעשה שימוש בהנחות שצוינו למעלה, ו-GPS_PROVIDER משמש כמקור בסיסי כל הזמן. הוא משנה את המיקומים מ-GNSS, ומוסיף שגיאות כדי שהמיקום יהיה פחות מדויק כשצריך. לדוגמה, כשמיקומים גסים מסופקים ללקוח.

לכן, במקרים נדירים מאוד, יכול להיות שיעבור יותר זמן מהרגיל עד שהמיקום הראשון יהיה זמין. לדוגמה, בפעם הראשונה שמשתמשים ברכב או, ליתר דיוק, במערכת המשנה למיקום שלו, או אחרי שהרכב נגרר.

עיצוב אפליקציות לשימוש בנייד ובמכוניות

מומלץ שאפליקציות שמיועדות למכשירים ניידים ולמכשירי רכב שלא נדרשת בהן בקשה מדויקת באיכות גבוהה יותר android.permission.ACCESS_COARSE_LOCATION בלבד, יחזרו לשימוש ב-FLP כשהיא זמינה. לחלופין, כמוצא אחרון, אפשר להשתמש ב-GPS_PROVIDER ישירות עם אותן הרשאות. המסגרת מפחיתה את רמת הדיוק של מיקום ה-GNSS הבסיסי כדי להתאים לצפי של ה-API. מידע נוסף זמין במאמר בנושא דיוק.

בנוסף, האפליקציות האלה צריכות להצהיר במפורש על התכונה android.hardware.location.network optional במניפסט שלהן. לדוגמה:

<uses-feature android:name="android.hardware.location.network" android:required="false" />

הגישה הזו מבטיחה תאימות מקסימלית למכשירים בתחומים שונים, ולכן זמינות מקסימלית של האפליקציה ללא הבדלים בקוד כדי לקבל מיקומים כשצריך.