سبب التمهيد الأساسي

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

يتضمّن نظام التشغيل Android 9 التغييرات التالية على مواصفات سبب تشغيل برنامج الإقلاع.

أسباب التشغيل

يستخدم مشغّل الإقلاع موارد الأجهزة والذاكرة المتاحة بشكل فريد لتحديد سبب إعادة تشغيل الجهاز، ثم ينقل هذا التحديد من خلال إضافة androidboot.bootreason=<reason> إلى سطر أوامر ملف ‎kernel لنظام التشغيل Android من أجل تشغيله. بعد ذلك، يترجم init سطر الأمر هذا ليتم نشره في سمة Android bootloader_boot_reason_prop (ro.boot.bootreason). بالنسبة إلى الأجهزة التي تعمل بالإصدار 12 من Android أو إصدار أحدث، باستخدام الإصدار 5.10 من kernel أو إصدار أحدث، تتم إضافة androidboot.bootreason=<reason> إلى bootconfig بدلاً من سطر أوامر kernel.

مواصفات سبب التشغيل

حدّدت الإصدارات السابقة من Android تنسيقًا لسبب التمهيد لا يستخدم المسافات، وكان مكتوبًا بأحرف أبجدية صغيرة فقط، ويتضمّن متطلبات قليلة (مثل الإبلاغ عن kernel_panic وwatchdog cold/warm/hard)، ويتيح استخدام أسباب فريدة أخرى. أدّت هذه المواصفات غير الدقيقة إلى انتشار مئات سلاسل رسائل سبب التمهيد المخصّصة (وغير ذات المعنى في بعض الأحيان)، ما أدّى بدوره إلى حدوث حالة لا يمكن إدارتها. اعتبارًا من الإصدار الحالي من Android، أدّى الزخم الهائل للمحتوى الذي يكاد يكون غير قابل للتحليل أو غير ذي معنى الذي يُرسله برنامج الإقلاع إلى حدوث مشاكل في الامتثال لـ bootloader_boot_reason_prop.

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

• التفاعل مع مطوّري برامج الإقلاع لتشجيعهم على:
  • قدِّم أسبابًا أساسية وقابلة للتحليل والتعرّف عليها لتحديد bootloader_boot_reason_prop.
  • المشاركة في قائمة system/core/bootstat/bootstat.cpp kBootReasonMap
• إضافة مصدر قابل للتحكّم فيه وقابل لإعادة الكتابة أثناء التشغيل لملف تعريف system_boot_reason_prop (sys.boot.reason). يمكن لمجموعة محدودة من تطبيقات النظام (مثل bootstat و init) إعادة كتابة هذا الملف، ولكن يمكن منح كل التطبيقات أذونات سياسة الأمان لقراءته.
• إبلاغ المستخدمين بسبب التمهيد للانتظار إلى أن يتم تثبيت userdata قبل الوثوق بالمحتوى في خاصية سبب التمهيد للنظام system_boot_reason_prop

Why so late? على الرغم من أنّ bootloader_boot_reason_prop متاح في مرحلة مبكرة من عملية التمهيد، إلا أنّه يتم حظره بموجب سياسة أمان Android حسب الحاجة لأنّه يعرض معلومات غير دقيقة وغير قابلة للتحليل وغير متوافقة مع قواعد اللغة. في معظم الحالات، لن يحتاج سوى المطوّرين الذين لديهم معرفة عميقة بنظام التشغيل إلى الوصول إلى هذه المعلومات. لا يمكن بعد تركيب userdata إلا رصد واجهة برمجة تطبيقات محسّنة وقابلة للتحليل وموحّدة لسبب التمهيد باستخدام system_boot_reason_prop بشكل موثوق ودقيق. وعلى وجه التحديد:

• قبل تركيب userdata، سيحتوي system_boot_reason_prop على القيمة من bootloader_boot_reason_prop.
• بعد تركيب userdata، system_boot_reason_prop قد يتم تعديله للامتثال أو للإبلاغ عن معلومات أكثر دقة.

لهذا السبب، يمدِّد نظام التشغيل Android 9 مدّة الوقت قبل أن يتم الحصول رسميًا على سبب التشغيل، ما يؤدي إلى تغييره من أن يكون دقيقًا على الفور أثناء التشغيل (مع bootloader_boot_reason_prop) إلى أن يصبح متاحًا فقط بعد تركيب userdata (مع system_boot_reason_prop).

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

تنسيق سبب التمهيد الأساسي

يستخدم تنسيق سبب التمهيد الأساسي لـ bootloader_boot_reason_prop في Android 9 البنية التالية:

<reason>,<subreason>,<detail>…

قواعد التنسيق:

• الأحرف الصغيرة
• لا تترك مسافات فارغة (استخدِم تسطيرًا).
• جميع الأحرف القابلة للطباعة
• reason وsubreason ومثيل واحد أو أكثر من detail مفصولة بفواصل
  • reason مطلوبة تمثّل أعلى أولوية سبب إعادة تشغيل الجهاز أو إيقافه
  • subreason اختياري يمثّل ملخّصًا قصيرًا عن سبب إعادة تشغيل الجهاز أو إيقافه (أو المستخدم الذي أعاد تشغيل الجهاز أو أوقفه التشغيل).
  • قيمة واحدة أو أكثر من قيم detail الاختيارية قد يشير detail إلى نظام فرعي للمساعدة في تحديد النظام المحدد الذي أدّى إلى حدوث subreason. يمكنك تحديد قيم detail متعددة، والتي يجب أن تتّبع بشكل عام تسلسلاً هرميًا ل الأهمية. ومع ذلك، يُسمح أيضًا بالإبلاغ عن قيم detail متعدّدة ذات أهمية متساوية.

تُعدّ القيمة الفارغة لسمة bootloader_boot_reason_prop غير قانونية (لأنّ ذلك يسمح لموظّفي الدعم الآخرين بإدخال سبب التشغيل بعد حدوثه).

متطلبات السبب

يجب أن تكون القيمة المقدَّمة لـ reason (النطاق الأول، قبل الانتهاء أو الفاصلة) من المجموعة التالية مقسّمة إلى أسباب أساسية وقوية ومباشرة:

• مجموعة النواة:
  • "watchdog"
  • "kernel_panic"
• مجموعة قوية:
  • "recovery"
  • "bootloader"
• مجموعة حادة:
  • "cold": يشير بشكل عام إلى إعادة ضبط جميع الأجهزة بالكامل، بما في ذلك الذاكرة.
  • "hard": يشير بشكل عام إلى أنّه تم إعادة ضبط حالة الجهاز ، ومن المفترض أن يحتفظ ramoops بالمحتوى الدائم.
  • "warm": يشير بشكل عام إلى أنّ الذاكرة والأجهزة تحتفظان ببعض الحالات، وأنّ مساحة التخزين الاحتياطية ramoops (راجِع pstore برنامج تشغيل kernel) تحتوي على محتوى دائم.
  • "shutdown"
  • ‫"reboot": يعني ذلك بشكل عام أنّ حالة ramoops غير معروفة وأنّ حالة الجهاز غير معروفة. هذه القيمة هي قيمة شاملة لأنّ قيم cold وhard وwarm تقدّم بدورها أدلة حول مدى إعادة ضبط الجهاز.

يجب أن يوفّر مشغّلو الإقلاع مجموعة نواة أو مجموعة reason، ويُنصح بشدة بتقديم subreason إذا كان يمكن تحديده. على سبيل المثال، الضغط مع الاستمرار على مفتاح التشغيل الذي قد يكون لديه ramoops احتياطي أو لا يكون لديه احتياطي سيؤدي إلى تحديد سبب التشغيل "reboot,longkey".

لا يمكن أن يكون أيّ reason من النطاقات الأولى جزءًا من أيّ subreason أو detail. ومع ذلك، بما أنّه لا يمكن إنشاء أسباب ضبط kernel من مساحة المستخدم، يمكن إعادة استخدام "watchdog" بعد سبب ضبط صريح، مع تفاصيل المصدر (على سبيل المثال، "reboot,watchdog,service_manager_unresponsive" أو "reboot,software,watchdog").

يجب ألا تتطلّب أسباب بدء التشغيل معرفة داخلية من الخبراء لفك ترميزها و/أو يجب أن تكون قابلة للقراءة من قِبل المستخدمين من خلال تقرير بسيط. أمثلة: "shutdown,vbxd" (سيّئ)، "shutdown,uv" (أفضل)، "shutdown,undervoltage" (مفضّل).

مجموعات السبب والسبب الفرعي

يحتفظ Android بمجموعة من مجموعات reason-subreason التي يجب عدم تحميلها بشكل زائد في الاستخدام العادي، ولكن يمكن استخدامها على أساس كل حالة على حدة إذا كانت التركيبة تعكس بدقة الحالة المرتبطة بها. تشمل أمثلة التركيبات المحجوزة ما يلي:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (من thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (من BatteryStatsService)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

لمزيد من التفاصيل، يُرجى الرجوع إلى kBootReasonMap في system/core/bootstat/bootstat.cpp وسجلّ التغييرات المرتبط بـ git في مستودع مصدر Android.

الإبلاغ عن أسباب التشغيل

يجب تسجيل جميع أسباب التشغيل، سواء من أداة تحميل التشغيل أو المسجّلة في سبب التشغيل الأساسي، في قسم kBootReasonMap من system/core/bootstat/bootstat.cpp. تتضمّن قائمة kBootReasonMap مزيجًا من الأسباب المتوافقة والقديمة غير المتوافقة. على مطوّري أداة تحميل التشغيل تسجيل الأسباب الجديدة المتوافقة فقط هنا (ويجب عدم تسجيل الأسباب غير المتوافقة ما لم يكن المنتج قد تم شحنه ولا يمكن تغييره).

ننصحك بشدة باستخدام الإدخالات الحالية المتوافقة في system/core/bootstat/bootstat.cpp والتحكّم في استخدامك لسلاسل غير متوافقة. في ما يلي إرشادات عامة:

• انقر على حسنًا للإبلاغ عن "kernel_panic" من bootloader، لأنّ bootstat قد يتمكّن من فحص ramoops من أجل kernel_panic signatures لتحسين الأسباب الفرعية في system_boot_reason_prop الأساسي.
• غير مقبول الإبلاغ عن سلسلة غير متوافقة في kBootReasonMap (مثل "panic") من bootloader ، لأنّ ذلك سيؤدي في النهاية إلى إيقاف إمكانية تحسين reason.

على سبيل المثال، إذا كان kBootReasonMap يحتوي على "wdog_bark"، على مطوّر أداة التمهيد تنفيذ ما يلي:

• غيِّر القيمة إلى "watchdog,bark" وأضِفها إلى القائمة في kBootReasonMap.
• ضع في اعتبارك ما يعنيه الرمز "bark" للمستخدمين غير المألوفين بالتكنولوجيا، وحدِّد ما إذا كان هناك رمز subreason أكثر ملاءمةً.

التحقّق من امتثال سبب التفعيل

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

نتيجةً لذلك، يتطلّب الامتثال لبرنامج التمهيد من مطوّري برنامج التمهيد الالتزام الطوعي بمضمون القواعد والإرشادات الموضّحة أعلاه. ونحثّ هؤلاء المطوّرين على المساهمة في AOSP (وتحديدًا في system/core/bootstat/bootstat.cpp) واستخدام هذه الفرصة كمنصة لمناقشة المشاكل المتعلّقة بسبب عدم التمهيد.