إعادة هيكلة RIL

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

تتضمن إعادة هيكلة RIL التحسينات التالية:

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

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

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

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

في Android 7.x والإصدارات الأحدث، يمكن لمصنعي المعدات الأصلية إرجاع قيمة رمز خطأ مميزة مرتبطة بكل خطأ مختلف تم تصنيفه حاليًا على أنه GENERIC_FAILURE . يمكن لمصنعي المعدات الأصلية الذين لا يريدون الكشف علنًا عن رموز الأخطاء المخصصة الخاصة بهم إرجاع الأخطاء كمجموعة مميزة من الأعداد الصحيحة (مثل 1 إلى x) المعينة كـ OEM_ERROR_1 إلى OEM_ERROR_X . يجب على البائعين التأكد من أن كل رمز خطأ مقنع يعيد الخرائط إلى سبب خطأ فريد في الكود. يمكن أن يؤدي استخدام رموز خطأ محددة إلى تسريع عملية تصحيح أخطاء RIL عندما يتم إرجاع أخطاء عامة بواسطة OEM، حيث قد يستغرق تحديد السبب الدقيق لرمز خطأ 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 باستخدام Wakelocks

تُستخدم تقنية Wakelocks الموقوتة في اتصالات RIL بطريقة غير دقيقة، مما يؤثر سلبًا على أداء البطارية. في Android 7.x والإصدارات الأحدث، يمكنك تحسين الأداء من خلال تصنيف طلبات RIL وتحديث التعليمات البرمجية للتعامل مع Wakelocks بشكل مختلف لأنواع الطلبات المختلفة.

تصنيف طلبات RIL

يمكن أن تكون طلبات RIL إما مطلوبة أو غير مرغوب فيها. يجب على البائعين أيضًا تصنيف الطلبات المطلوبة كواحد مما يلي:

• متزامن . الطلبات التي لا تستغرق وقتًا طويلاً للرد عليها. على سبيل المثال، RIL_REQUEST_GET_SIM_STATUS .
• غير متزامن . الطلبات التي تستغرق وقتًا طويلاً للرد عليها. على سبيل المثال، RIL_REQUEST_QUERY_AVAILABLE_NETWORKS .

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

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

سيناريوهات الاتصال RIL

توضح الرسوم البيانية التالية سيناريوهات اتصال RIL الشائعة وتوفر حلولاً لتعديل التعليمات البرمجية للتعامل مع طلبات RIL المطلوبة وغير المرغوب فيها.

ملاحظة: للحصول على تفاصيل التنفيذ حول الوظائف المستخدمة في الرسوم البيانية التالية، راجع الأساليب acquireWakeLock() و decrementWakeLock() و clearWakeLock( ) في ril.cpp .

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

في هذا السيناريو، إذا كان من المتوقع أن تستغرق استجابة RIL المطلوبة وقتًا طويلاً (أي استجابة إلى RIL_REQUEST_GET_AVAILABLE_NETWORKS )، فسيتم تعليق Wakelock لفترة طويلة من جانب معالج التطبيق. يمكن أن تؤدي مشكلات المودم أيضًا إلى الانتظار لفترة طويلة.

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

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

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

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

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

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

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

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

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

التحقق من صحة Wakelocks المعاد تصميمها

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