إعادة هيكلة RIL

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

يتضمّن إعادة تصميم RIL التحسينات التالية:

  • رموز خطأ RIL تتيح هذه السمة رموز أخطاء معيّنة بالإضافة إلى الرمز GENERIC_FAILURE الحالي. يساعد ذلك في تحديد المشاكل وحلّها من خلال تقديم معلومات أكثر تحديدًا عن سبب حدوث الأخطاء.
  • تحديد إصدارات RIL توفير معلومات أكثر دقة وأسهل في الإعداد حول الإصدار
  • اتصال RIL باستخدام أقفال التنشيط يحسّن أداء بطارية الجهاز.

يمكنك تنفيذ أيّ من التحسينات المذكورة أعلاه أو جميعها. لمزيد من التفاصيل، يُرجى الرجوع إلى تعليقات الرمز البرمجي حول إصدارات RIL في https://android.googlesource.com/platform/hardware/ril/+/android16-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 solicited asynchronous response.

الحلّ 1: يحتفظ المودم بقفل التنشيط لطلب RIL والاستجابة غير المتزامنة.

الشكل 2. قفل نشط يحتفظ به المودم
  1. يتم إرسال طلب RIL ويحصل المودم على wakelock لمعالجة هذا الطلب.
  2. يرسل المودم إقرارًا يتسبّب في أن يخفّض جانب Java عدّاد قفل التنشيط ويحرّره عندما تكون قيمة العداد 0.

    ملاحظة: سيكون مدة المهلة الخاصة بتأمين الاستخدام بدون انقطاع لتسلسل طلب الإقرار أصغر من مدة المهلة المستخدَمة حاليًا لأنّه من المفترض أن يتم تلقّي الإقرار بسرعة.

  3. بعد معالجة الطلب، يرسل المودم إشارة مقاطعة إلى رمز المورّد الذي يحصل على قفل التنشيط ويرسل استجابة إلى ril.cpp، والذي يحصل بدوره على قفل التنشيط ويرسل استجابة إلى جانب Java.
  4. عندما يصل الردّ إلى جانب Java، يتم الحصول على wakelock ويتم عرض ردّ للمتصل.
  5. بعد أن تتم معالجة الرد من خلال جميع الوحدات، يتم إرسال إقرار بالاستلام (عبر المقبس) إلى ril.cpp، الذي يحرر بعد ذلك قفل التنشيط الذي تم الحصول عليه في الخطوة 3.

الحلّ 2: لا يحتفظ المودم بقفل التنشيط، ويكون الرد سريعًا (طلب واستجابة متزامنان لواجهة RIL). يتم ترميز السلوك المتزامن مقابل السلوك غير المتزامن بشكل ثابت لأمر معيّن من RIL، ويتم تحديده على أساس كل مكالمة على حدة.

الشكل 3. لم يتم الاحتفاظ بقفل التنشيط بواسطة المودم.
  1. يتم إرسال طلب RIL من خلال استدعاء acquireWakeLock() على جهة Java.
  2. لا يحتاج رمز المورّد إلى الحصول على wakelock ويمكنه معالجة الطلب والرد بسرعة.
  3. عندما يتلقّى رمز Java الرد، يتم استدعاء decrementWakeLock()، ما يؤدي إلى خفض عدّاد wakelock وإيقاف wakelock إذا كانت قيمة العداد 0.

السيناريو: ردّ غير مرغوب فيه من RIL

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

الشكل 4. ردّ غير مطلوب من RIL.

الحل: يتم إرسال إقرار من رمز Java إلى الجانب الأصلي (ril.cpp) بدلاً من الاحتفاظ بقفل تنشيط مؤقت على الجانب الأصلي أثناء إرسال رد غير مطلوب.

الشكل 5. استخدام ack بدلاً من wakelock المحدّد بوقت

التحقّق من صحة عمليات إعادة تصميم عمليات التنشيط

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