כדי לכבד את פרטיות המשתמשים, מומלץ למפתחי אפליקציות לבקש רק הרשאות למיקום משוער. אפליקציות שצריכות מיקום משוער בקירוב בדרך כלל משתמשות במיקום רשת משולב (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, שהייתה זמינה בעבר רק דרך ה-API של שירותי Google Play, זמינה כספק מיקום ל-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.
ספק מיקום משולב
ה-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" />
הגישה הזו עוזרת להשיג תאימות טובה יותר למכשירים בגורמי צורה שונים, ולכן זמינות מקסימלית של האפליקציה ללא הבדלים בקוד לקבלת מיקומים כשצריך.