الحصول على الموقع الجغرافي التقريبي

وللحفاظ على خصوصية المستخدم، ننصح مطوّري التطبيقات بطلب البيانات التقريبية أذونات تحديد الموقع الجغرافي: عادةً ما تحتاج التطبيقات التي تحتاج إلى موضع تقريبي استخدام موقع الشبكة (FLP) لأنه سريع ويستهلك طاقة أقل.

بالمقارنة مع الأجهزة الجوّالة التي تعمل بنظام التشغيل Android، تبيّن أنّ الموقع الجغرافي للشبكة في تطبيقات السيارات يمكن أن يكون أكثر صعوبة. يمكنك استخدام واجهتَي برمجة تطبيقات Android:

تستخدم العديد من تطبيقات السيارات FLP من خلال واجهة برمجة تطبيقات "خدمات Google Play" (GPS) بدلاً من LM. يختار FLP مزود الموقع الجغرافي الأمثل بناءً على طلب الموقع المعايير والسياسات (القوة والدقة) التي تحتاجها المركبة.

يمكنك بدلاً من ذلك أن تختار طلب واستخدام NETWORK_PROVIDER في "LM" وكذلك GPS_PROVIDER للمواضع الدقيقة التي تستخدم android.permission.ACCESS_FINE_LOCATION الأذونات. في واجهة برمجة التطبيقات 31، FUSED_PROVIDER يمكن الوصول إليها من قبل فقط عبر واجهة برمجة تطبيقات GPS، متوفّر كموفِّر موقع جغرافي لتطبيق "LM". يمكنك عرض صفحة تنفيذ FLP، في FusedLocationProvider.java

في حين أنّه من الممكن استخدام GPS_PROVIDER مع حقوق الأذونات التقريبية فقط، يقلل إطار العمل بشكل مصطنع الدقة لتتوافق مع التوقعات، غير منطقي بالنسبة إلى المطوّرين الذين يستهدفون هواتف Android يكون مدى التوفّر ضعيفًا وغالبًا ما يبطئ للحصول على ترتيب تقريبي.

موقع الشبكة في السيارات

يحتوي NETWORK_PROVIDER المستخدَم على هواتف Android (مع خدمات Google للأجهزة الجوّالة) على من تحديد الموقع الذي يعتمد فقط على أبراج الاتصالات القريبة إلى أيضًا نقاط وصول Wi-Fi أو حتى إشارات البلوتوث (BT). استخدام قد يتطلب NETWORK_PROVIDER اتصالاً بالبيانات.

بالنسبة إلى تطبيقات السيارات، تختلف قيود الأجهزة. ونظرًا لأن GNSS قيد التشغيل عادةً، ولن يتم فرض عقوبات بسبب زيادة استخدام الطاقة والبطارية. نتيجة لذلك، أُنشئت مكتبة مات بلوت ليب في فإن مدة تشغيل IVI لم تتعرض للخطر. ونسعى جاهدين لتقليل تبادل البيانات مع خوادمنا.

لذلك، تستخدم العديد من التطبيقات "FLP" من Play API بدلاً من LM مباشرةً كـ FLP. ينفذ الشيء الذكي تلقائيًا باستخدام موفر خدمة الموقع الجغرافي بأفضل استيفاء معايير/سياسات طلب الموقع الجغرافي (لا سيّما القوة والدقة) بموجب غطاء المحرك.

على عكس الأجهزة الجوّالة، نادرًا ما تبدو المركبات تقفز من مكان إلى آخر. البعض في أغلب الأحيان، تكون معلومات موضع المركبة معروفة تحت غطاء المحرك.

موفِّر الموقع الجغرافي للشبكة

لا تستخدم معظم المركبات واجهات برمجة التطبيقات للاتصال الهاتفي المطلوبة للحصول على المعلومات المطلوبة. معرف الهاتف الخلوي (وقوة الإشارة). ونتيجة لذلك، ولأننا نتخذ أقل قدر من البيانات استخدامه، لا يتم توفير تنفيذ وظيفي إضافي لـ NLP.

موفِّر الموقع الجغرافي المدمج

FLP، بالإضافة إلى الاستخدام الذكي لمزودي الشبكات ونظام تحديد المواقع العالمي (GPS) يعمل على دمج المعلومات من المستشعرات الأخرى لتعزيز وجودة المواقع. عملية التنفيذ الحالية لخطّ FLP في السيارات على ومن ناحية أخرى الاستفادة من الافتراضات والاستخدامات المذكورة أعلاه GPS_PROVIDER كمصدر أساسي طوال الوقت يتحايل على المواقف من GNSS، إضافة بعض الأخطاء لتكون أكثر دقة عند الحاجة. على سبيل المثال: عند توفير مواقع تقريبية للعميل.

وبناءً على ذلك، في حالات قليلة جدًا، قد يكون هناك وقت أطول من المعتاد الإعلان عن الموضع الأول ليكون متاحًا. على سبيل المثال، في المرة الأولى التي يمكنك فيها قيادة مركبة أو لنكون أكثر دقة، يتم استخدام نظامها الفرعي للموقع أو بعد سحبها.

تصميم تطبيقات لاستهداف استخدامات الأجهزة المحمولة والسيارات

نقترح أن تستهدف التطبيقات التي تستهدف الأجهزة الجوّالة والسيارات التي لا تستهدف تتطلب دقة أعلى في الجودة android.permission.ACCESS_COARSE_LOCATION فقط والرجوع إلى استخدام FLP متى توفر. بدلاً من ذلك، استخدِم GPS_PROVIDER مباشرةً كحلّ بديل. باستخدام الأذونات نفسها. يقلل هذا الإطار من دقة موضع GNSS المتوافق مع توقعات واجهة برمجة التطبيقات. لمزيد من المعلومات، يُرجى الاطّلاع على الدقة.

بالإضافة إلى ذلك، يجب أن تعلن هذه التطبيقات صراحةً android.hardware.location.network اختيارية في ملف البيان. مثلاً:

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

ويضمن هذا المنهج أقصى قدر من التوافق مع الأجهزة على مستوى المجالات، وبالتالي، يتمثل الحد الأقصى لتوافر التطبيق بدون اختلافات في الرموز في الحصول على المناصب عند الحاجة.