إعادة هيكلة RIL

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

تشمل إعادة صياغة واجهة برمجة التطبيقات لنظام التشغيل RIL التحسينات التالية:

• رموز خطأ واجهة برمجة التطبيقات للشبكة الجوّالة (RIL) تفعّل رموز أخطاء محدّدة بالإضافة إلى رمز GENERIC_FAILURE الحالي. يساعد ذلك في تحديد الأخطاء وحلّها من خلال تقديم معلومات أكثر تحديدًا عن سبب الأخطاء.
• إصدار واجهة برمجة التطبيقات لوحدة المعالجة الداخلية (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_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() على جانب IDE.
2. لا يحتاج رمز المورّد إلى الحصول على قفل الاستيقاظ ويمكنه معالجة الطلب والردّ عليه بسرعة.
3. عند تلقّي الاستجابة من جانب Java، يتم استدعاء decrementWakeLock()، ما يؤدي إلى خفض عدد مرات تنشيط التعليق المُعلّق وإلغاء تنشيط التعليق المُعلّق إذا كانت قيمة المُعدّل 0.

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

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

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

التحقّق من صحة عمليات قفل الاستيقاظ المُعاد تصميمها

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