إعادة هيكلة RIL

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

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

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

يمكنك تنفيذ أي من التحسينات أعلاه أو جميعها. لمزيد من التفاصيل، يُرجى الرجوع إلى تعليقات الرمز البرمجي حول تحديد إصدارات RIL في https://android.googlesource.com/platform/hardware/ril/+/android17-release/include/telephony/ril.h.

تنفيذ رموز خطأ RIL المحسّنة

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

في Android 7.x والإصدارات الأحدث، يمكن لمصنّعي المعدات الأصلية عرض قيمة رمز خطأ مميّزة مرتبطة بكل خطأ مختلف يتم تصنيفه حاليًا على أنّه 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 غير واضحة (ما أدّى إلى إبلاغ بعض المورّدين عن إصدار غير صحيح)، وكان الحلّ البديل لتقدير الإصدار عرضةً لعدم الدقة.

في Android 7.x والإصدارات الأحدث، يوثّق الملف ril.h جميع قيم إصدارات RIL ويصف إصدار RIL المقابل ويسرد جميع التغييرات لهذا الإصدار. عند إجراء تغييرات تتوافق مع إصدار RIL، على المورّدين تعديل الإصدار في الرمز وعرض هذا الإصدار في RIL_REGISTER.

التحقّق من تحديد إصدارات RIL المحسّن

تأكَّد من أنّ إصدار RIL المقابل لرمز RIL يتم عرضه أثناء RIL_REGISTER (بدلاً من RIL_VERSION المحدّد في ril.h).

تنفيذ اتصال RIL باستخدام أقفال التنشيط

يتم استخدام عمليات التنشيط المؤقتة في الاتصال عبر RIL بطريقة غير دقيقة، ما يؤثر سلبًا في أداء البطارية. في Android 7.x والإصدارات الأحدث، يمكنك تحسين الأداء من خلال تصنيف طلبات 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 والاستجابة غير المتزامنة.

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

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

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

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

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

السيناريو: استجابة غير مطلوبة في RIL

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

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

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

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