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

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

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

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

يمكنك بدلاً من ذلك اختيار طلب NETWORK_PROVIDER واستخدامه بشكل صريح في LM، بالإضافة إلى GPS_PROVIDER للمواضع الدقيقة، والذي يستخدم أذونات android.permission.ACCESS_FINE_LOCATION . في API 31، أصبح FUSED_PROVIDER ، الذي كان يمكن الوصول إليه سابقًا فقط من خلال GPS API، متاحًا الآن كموفر موقع لـ LM. يمكنك عرض تنفيذ أكثر بساطة لـ FLP، في FusedLocationProvider.java .

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

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

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

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

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

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

مزود موقع الشبكة

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

مزود الموقع المندمج

يقوم نظام FLP المحمول، بالإضافة إلى الاستخدام الذكي لموفري الشبكة ونظام تحديد المواقع العالمي (GPS) حسب الاقتضاء، بدمج المعلومات من أجهزة الاستشعار الأخرى لزيادة تحسين جودة المواقع. من ناحية أخرى، يستفيد التطبيق الحالي لـ FLP الخاص بالسيارات من الافتراضات المذكورة أعلاه ويستخدم 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" />

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