للحفاظ على خصوصية المستخدمين، ننصح مطوّري التطبيقات بطلب أذونات الموقع الجغرافي التقريبي فقط. تستخدم التطبيقات التي تحتاج إلى تحديد موقع جغرافي تقريبي عادةً الموقع الجغرافي للشبكة (FLP) لأنّه سريع ويستهلك قدرًا أقل من الطاقة.
مقارنةً بأجهزة Android الجوّالة، قد يكون تحديد الموقع الجغرافي للشبكة في تطبيقات السيارات أكثر صعوبة. يمكنك استخدام واجهتَي برمجة تطبيقات Android:
تتطلّب منك واجهة برمجة التطبيقات LocationManager أو LM تحديد موفِّر الموقع الجغرافي المفضّل بشكل صريح.
توفر واجهة برمجة تطبيقات "خدمات Google Play" طريقة أكثر بساطة للتعامل مع الموقع الجغرافي من خلال طرح موفِّر الموقع المدمج (FLP).
تستخدم العديد من تطبيقات السيارات 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 أو حتى أجهزة إرسال Bluetooth (BT). قد يتطلّب استخدام NETWORK_PROVIDER اتصالاً بالبيانات.
بالنسبة إلى تطبيقات السيارات، تختلف قيود الأجهزة. بما أنّ نظام GNSS يكون مفعّلاً عادةً، لا يتم فرض أي عقوبات بسبب زيادة استخدام الطاقة والبطارية. نتيجةً لذلك، لا يتأثر وقت تشغيل نظام المعلومات والترفيه داخل السيارة (IVI). نسعى جاهدين إلى تقليل البيانات التي يتم تبادلها مع خوادمنا.
لذلك، تستخدم الكثير من التطبيقات FLP من واجهة برمجة تطبيقات Play بدلاً من LM مباشرةً لأنّ FLP ينفّذ العملية الذكية تلقائيًا من خلال استخدام موفِّر الموقع الجغرافي الأفضل قدرةً على استيفاء معايير/سياسات طلب الموقع الجغرافي (أي الطاقة والدقة) في الخلفية.
على عكس الأجهزة الجوّالة، نادرًا ما يبدو أنّ السيارات تنتقل من مكان إلى آخر. يكون موضع السيارة معروفًا في الخلفية معظم الوقت.
موفِّر الموقع الجغرافي للشبكة
لا تنفّذ معظم السيارات واجهات برمجة التطبيقات المطلوبة للاتصالات الهاتفية للحصول على المعلومات اللازمة عن رقم تعريف الخلية (وقوة الإشارة). نتيجةً لذلك، ولأنّنا نقلّل من استخدام البيانات، لا يتم توفير أي عملية تنفيذ وظيفية إضافية لـ NLP.
موفِّر الموقع المدمج
بالإضافة إلى استخدام موفِّري الشبكة ونظام GPS بذكاء حسب الحاجة، يدمج FLP على الأجهزة الجوّالة المعلومات من أجهزة الاستشعار الأخرى لزيادة تحسين جودة المواقع الجغرافية. من ناحية أخرى، يستفيد التنفيذ الحالي لـ 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" />
يضمن هذا النهج الحد الأقصى من التوافق مع الأجهزة في مختلف القطاعات، وبالتالي الحد الأقصى من توفّر التطبيق بدون أي اختلافات في الرموز البرمجية للحصول على المواضع عند الحاجة.