קבלת מיקום משוער

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

• לפי הדרישות של LocationManager API, צריך להשתמש requestLocationUpdates כדי לזהות במפורש את ספק המיקום המועדף.

• Google Play Services API מציע דרך פשוטה יותר עבודה עם מיקום ב- 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 לנייד) קובע את המיקום לפי אנטנות סלולריות סמוכות, נקודות גישה ל-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 ישירות עם אותן ההרשאות. ה-framework פוגע את הדיוק של המיקום הבסיסי ב-GNSS כדי להתאים לציפיות של ה-API. שפת תרגום מידע נוסף זמין בקטע דיוק בקטע בקשת הרשאות מיקום.

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

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

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