أعاد الإصدار 7.0 من نظام التشغيل Android تصميم طبقة واجهة الراديو (RIL) باستخدام مجموعة من الميزات لتحسين وظائفها. يجب إجراء تغييرات على رمز الشريك لتنفيذ هذه الميزات، وهي اختيارية ولكن يُنصح باستخدامها. تتوافق التغييرات الناتجة عن إعادة تصميم الرمز البرمجي مع الأنظمة القديمة، لذا ستستمر عمليات التنفيذ السابقة للميزات التي تمت إعادة تصميمها في العمل.
يتضمّن إعادة تصميم RIL التحسينات التالية:
- رموز خطأ RIL تتيح هذه السمة رموز أخطاء معيّنة
بالإضافة إلى الرمز
GENERIC_FAILUREالحالي. يساعد ذلك في تحديد المشاكل وحلّها من خلال تقديم معلومات أكثر تحديدًا عن سبب حدوث الأخطاء. - تحديد إصدارات RIL توفير معلومات أكثر دقة وأسهل في الإعداد حول الإصدار
- اتصال RIL باستخدام أقفال التنشيط يحسّن أداء بطارية الجهاز.
يمكنك تنفيذ أيّ من التحسينات المذكورة أعلاه أو جميعها. لمزيد من التفاصيل، يُرجى الرجوع إلى تعليقات الرمز البرمجي حول إصدارات RIL في https://android.googlesource.com/platform/hardware/ril/+/android16-qpr2-release/include/telephony/ril.h.
تنفيذ رموز أخطاء محسّنة في RIL
يمكن أن تعرض جميع طلبات RIL تقريبًا رمز الخطأ GENERIC_FAILURE
كردّ على حدوث خطأ. تحدث هذه المشكلة مع جميع الردود المطلوبة التي ترسلها الشركات المصنّعة للأجهزة الأصلية، ما قد يصعّب تصحيح خطأ من تقرير الأخطاء إذا تم عرض رمز الخطأ GENERIC_FAILURE نفسه من خلال طلبات RIL لأسباب مختلفة. قد يستغرق البائعون وقتًا طويلاً لتحديد الجزء من الرمز الذي قد يكون أرجع الرمز GENERIC_FAILURE.
في الإصدار 7.x من نظام التشغيل Android والإصدارات الأحدث، يمكن لمصنّعي المعدات الأصلية عرض قيمة رمز خطأ مميّزة
مرتبطة بكل خطأ مختلف يتم تصنيفه حاليًا على أنّه
GENERIC_FAILURE. يمكن لمصنّعي المعدات الأصلية الذين لا يريدون الكشف علنًا عن رموز الخطأ المخصّصة لديهم عرض الأخطاء كمجموعة مميزة من الأعداد الصحيحة (مثل 1 إلى x) يتم ربطها على النحو التالي: OEM_ERROR_1 إلى OEM_ERROR_X. على المورّدين التأكّد من أنّ كل رمز خطأ محجوب يتم عرضه يرتبط بسبب خطأ فريد في الرمز. يمكن أن يؤدي استخدام رموز أخطاء معيّنة إلى تسريع عملية تصحيح أخطاء RIL عندما تعرض الشركة المصنّعة للجهاز أخطاء عامة، إذ قد يستغرق تحديد السبب الدقيق لرمز الخطأ GENERIC_FAILURE وقتًا طويلاً (وفي بعض الأحيان يكون من المستحيل معرفة السبب).
بالإضافة إلى ذلك، يضيف ril.h المزيد من رموز الخطأ إلى التعدادات RIL_LastCallFailCause وRIL_DataCallFailCause، ما يتيح لرمز المورّد تجنُّب عرض أخطاء عامة مثل CALL_FAIL_ERROR_UNSPECIFIED وPDP_FAIL_ERROR_UNSPECIFIED.
التحقّق من صحة رموز الخطأ المحسّنة في واجهة برمجة التطبيقات RIL
بعد إضافة رموز خطأ جديدة بدلاً من الرمز GENERIC_FAILURE، تأكَّد من أنّ طلب RIL يعرض رموز الخطأ الجديدة بدلاً من GENERIC_FAILURE.
تنفيذ ميزة "تحديد الإصدارات المحسّن من واجهة RIL"
كانت هناك مشاكل في إصدارات RIL في إصدارات Android القديمة، حيث كان الإصدار نفسه غير دقيق، ولم تكن آلية الإبلاغ عن إصدار RIL واضحة (ما أدّى إلى إبلاغ بعض المورّدين عن إصدار غير صحيح)، كما أنّ الحل البديل لتقدير الإصدار كان عرضة لعدم الدقة.
في الإصدار 7.x من نظام Android والإصدارات الأحدث، يوضّح المستند ril.h جميع قيم إصدار RIL، ويصف إصدار RIL المقابل، ويسرد جميع التغييرات التي تم إجراؤها على هذا الإصدار. عند إجراء تغييرات تتوافق مع إصدار RIL، على المورّدين تعديل الإصدار في الرمز البرمجي وعرض هذا الإصدار في RIL_REGISTER.
التحقّق من صحة إصدارات RIL المحسّنة
تأكَّد من عرض إصدار طبقة واجهة الراديو (RIL) المتوافق مع رمز طبقة واجهة الراديو (RIL) أثناء RIL_REGISTER (بدلاً من RIL_VERSION المحدّد في ril.h).
تنفيذ عملية التواصل مع RIL باستخدام أقفال التنشيط
يتم استخدام عمليات التنشيط المؤقتة في اتصالات RIL بطريقة غير دقيقة، ما يؤثر سلبًا في أداء البطارية. في الإصدار 7.x من نظام التشغيل Android والإصدارات الأحدث، يمكنك تحسين الأداء من خلال تصنيف طلبات RIL وتعديل الرمز البرمجي للتعامل مع عمليات التنشيط بشكل مختلف لأنواع الطلبات المختلفة.
تصنيف طلبات RIL
يمكن أن تكون طلبات RIL مطلوبة أو غير مطلوبة. على المورّدين تصنيف الطلبات التي تم الحصول عليها على أنّها أحد الأنواع التالية:
- متزامن الطلبات التي لا تستغرق وقتًا طويلاً للردّ. على سبيل المثال،
RIL_REQUEST_GET_SIM_STATUS. - غير متزامن الطلبات التي تستغرق وقتًا طويلاً للردّ عليها على سبيل المثال،
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS.
قد تستغرق طلبات RIL غير المتزامنة التي يتم إرسالها وقتًا طويلاً. بعد تلقّي إقرار من رمز المورّد، يحرّر RIL Java قفل التنشيط، ما قد يؤدي إلى انتقال معالج التطبيق من وضع الخمول إلى وضع التعليق. عندما تتوفّر الاستجابة من رمز المورّد، يعيد RIL Java (معالج التطبيق) الحصول على قفل التنشيط، ويعالج الاستجابة، ثم يعود إلى وضع الخمول. ويمكن أن يؤدي هذا الانتقال من وضع الخمول إلى وضع التعليق إلى وضع الخمول إلى استهلاك الكثير من الطاقة.
إذا لم يكن وقت الاستجابة طويلاً بما يكفي، قد يكون الاحتفاظ بقفل التنشيط والبقاء في وضع الخمول طوال الوقت الذي يستغرقه الرد أكثر كفاءة في استهلاك الطاقة من الانتقال إلى حالة التعليق عن طريق إلغاء قفل التنشيط والتنشيط عند وصول الرد. على المورّدين استخدام قياسات الطاقة الخاصة بالمنصة لتحديد قيمة الحد الأدنى للوقت T عندما تكون الطاقة المستهلكة من خلال البقاء في وضع الخمول طوال الوقت T أكبر من الطاقة المستهلكة من خلال الانتقال من وضع الخمول إلى وضع التعليق ثم إلى وضع الخمول في الوقت نفسه T. عندما يكون الوقت T معروفًا، يمكن تصنيف أوامر RIL التي تستغرق وقتًا أطول من T على أنّها غير متزامنة، وتصنيف الأوامر المتبقية على أنّها متزامنة.
سيناريوهات الاتصال عبر RIL
توضّح المخططات التالية سيناريوهات شائعة للتواصل مع طبقة RIL، وتقدّم حلولاً لتعديل الرمز البرمجي من أجل التعامل مع الطلبات التي يتم إرسالها إلى طبقة RIL وتلك التي لا يتم إرسالها.
ملاحظة: للحصول على تفاصيل التنفيذ بشأن الدوال المستخدَمة في المخططات التالية، يُرجى الرجوع إلى الطرق acquireWakeLock() وdecrementWakeLock() وclearWakeLock( في ril.cpp.
السيناريو: طلب RIL واستجابة غير متزامنة مطلوبة
في هذا السيناريو، إذا كان من المتوقّع أن يستغرق الردّ المطلوب من RIL وقتًا طويلاً (أي الردّ على RIL_REQUEST_GET_AVAILABLE_NETWORKS)، سيتم الاحتفاظ بقفل التنشيط لفترة طويلة على مستوى معالج التطبيق. قد تؤدي مشاكل جهاز المودم أيضًا إلى تأخير طويل.
الحلّ 1: يحتفظ المودم بقفل التنشيط لطلب RIL والاستجابة غير المتزامنة.
- يتم إرسال طلب RIL ويحصل المودم على قفل التنشيط لمعالجة هذا الطلب.
- يرسل المودم إقرارًا يتسبّب في أن يخفّض جانب Java عدّاد قفل التنشيط ويحرّره عندما تكون قيمة العداد 0.
ملاحظة: سيكون مدة المهلة الخاصة بتأمين الاستخدام بدون انقطاع لتسلسل طلب الإقرار أصغر من مدة المهلة المستخدَمة حاليًا لأنّه من المفترض أن يتم تلقّي الإقرار بسرعة.
- بعد معالجة الطلب، يرسل المودم إشارة مقاطعة إلى رمز المورّد الذي يحصل على wakelock ويرسل استجابة إلى ril.cpp، والذي يحصل بدوره على wakelock ويرسل استجابة إلى جانب Java.
- عندما يصل الردّ إلى رمز Java، يتم الحصول على wakelock ويتم عرض ردّ للمتصل.
- بعد أن تتم معالجة الردّ من خلال جميع الوحدات، يتم إرسال إقرار بالاستلام (عبر المقبس) إلى
ril.cpp، الذي يحرّر بعد ذلك قفل التنشيط الذي تم الحصول عليه في الخطوة 3.
الحلّ 2: لا يحتفظ المودم بقفل التنشيط، ويكون الردّ سريعًا (طلب واستجابة متزامنان لواجهة RIL). يتم ترميز السلوك المتزامن مقابل السلوك غير المتزامن بشكل ثابت لأمر RIL معيّن، ويتم تحديده على أساس كل مكالمة على حدة.
- يتم إرسال طلب RIL من خلال استدعاء
acquireWakeLock()على جانب Java. - لا يحتاج رمز المورّد إلى الحصول على wakelock ويمكنه معالجة الطلب والرد بسرعة.
- عندما يتلقّى رمز Java الرد، يتم استدعاء
decrementWakeLock()، ما يؤدي إلى خفض عدّاد wakelock وإيقاف wakelock إذا كانت قيمة العداد 0.
السيناريو: ردّ غير مرغوب فيه من RIL
في هذا السيناريو، تحتوي الردود غير المطلوبة من RIL على علامة نوع wakelock في تشير إلى ما إذا كان يجب الحصول على wakelock لردّ المورّد. إذا تم ضبط العلامة، يتم ضبط قفل تنبيه مؤقت ويتم إرسال الرد عبر مقبس إلى جهة Java. وعند انتهاء صلاحية الموقّت، يتم إيقاف قفل التنشيط. قد يكون قفل التنشيط المحدد بوقت طويلًا جدًا أو قصيرًا جدًا بالنسبة إلى الردود غير المطلوبة المختلفة من RIL.
الحل: يتم إرسال إقرار من رمز Java إلى
الجانب الأصلي (ril.cpp) بدلاً من الاحتفاظ بقفل تنشيط مؤقت على
الجانب الأصلي أثناء إرسال رد غير مطلوب.
التحقّق من صحة عمليات إعادة تصميم عمليات التنشيط
تأكَّد من تحديد مكالمات RIL على أنّها متزامنة أو غير متزامنة. نظرًا لأنّ استهلاك طاقة البطارية يمكن أن يعتمد على الأجهزة أو الأنظمة الأساسية، على المورّدين إجراء بعض الاختبارات الداخلية لمعرفة ما إذا كان استخدام دلالات قفل التنشيط الجديدة للمكالمات غير المتزامنة يؤدي إلى توفير طاقة البطارية.