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