כדי לכבד את פרטיות המשתמש, מפתחי אפליקציות מוזמנים לבקש הרשאות מיקום גסות בלבד. אפליקציות שצריכות מיקום גס משוער משתמשות בדרך כלל במיקום הרשת (FLP) מכיוון שהוא מהיר וצורך פחות חשמל.
בהשוואה למכשירים ניידים מבוססי אנדרואיד, מיקום הרשת באפליקציות רכב יכול להיות מאתגר יותר. אתה יכול להשתמש בשני ממשקי API של אנדרואיד:
LocationManager API דורש ממך לזהות במפורש את ספק המיקום המועדף.
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 עם זכויות הרשאות גסות בלבד, המסגרת פוגעת באופן מלאכותי ברמת הדיוק כדי להתיישר עם הציפיות, אבל זה לא הגיוני למפתחים שמתמקדים בטלפונים אנדרואיד מכיוון שהזמינות הכללית גרועה ולעיתים איטית יותר להשיג מיקום גס.
מיקום רשת ברכב
ה- NETWORK_PROVIDER המשמש בטלפונים אנדרואיד (עם שירותי Google Mobile) השתנה מקביעת מיקום על סמך מגדלים סלולריים סמוכים בלבד לשימוש גם בנקודות גישה ל-Wi-Fi או אפילו במשואות Bluetooth (BT). שימוש ב- NETWORK_PROVIDER עשוי לדרוש חיבור נתונים.
עבור אפליקציות רכב, אילוצי המכשיר שונים. מכיוון ש-GNSS פועל בדרך כלל, לא נגרמות עונשים עקב שימוש מוגבר בחשמל ובסוללה. כתוצאה מכך, זמן הפעולה של IVI אינו נפגע. אנו שואפים למזער נתונים שהוחלפו עם השרתים שלנו.
לכן, הרבה אפליקציות משתמשות ב-FLP מ-Play API במקום ב-LM ישירות מכיוון ש-FLP עושה את הדבר החכם באופן אוטומטי על ידי שימוש בספק המיקום המסוגל ביותר לעמוד בקריטריונים/מדיניות של בקשת מיקום (כלומר כוח ודיוק) מתחת למכסה המנוע.
בניגוד למכשירים ניידים, נראה כי רכבים כמעט ולא קופצים ממקום אחד לאחר. מיקום הרכב ידוע מתחת למכסה המנוע רוב הזמן.
ספק מיקום רשת
רוב הרכבים אינם מיישמים ממשקי 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" />
גישה זו מבטיחה תאימות מרבית למכשירים על פני אנכיים, ולכן, זמינות מקסימלית של אפליקציות ללא הבדלי קוד לקבלת מיקומים בעת הצורך.