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

يتضمّن نظام التشغيل 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) إعادة كتابة هذه السمة، ولكن يمكن منح جميع التطبيقات حقوق sepolicy لقراءتها.
• إبلاغ المستخدمين بسبب التمهيد للانتظار إلى أن يتم تثبيت userdata قبل الوثوق بالمحتوى في خاصية سبب التمهيد للنظام system_boot_reason_prop

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

• قبل تركيب userdata، سيحتوي system_boot_reason_prop على القيمة من bootloader_boot_reason_prop.
• بعد تثبيت بيانات المستخدم، قد يتم تعديل 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 (النطاق الأول، قبل علامة الإنهاء أو الفاصلة) من المجموعة التالية، وتنقسم إلى أسباب kernel وقوية وحادة:

• مجموعة النواة:
  • "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. وبما أنّه يتعذّر على مساحة المستخدم إنشاء أسباب مجموعة النواة، قد تتم إعادة استخدام "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) واستخدام هذه الفرصة كمنصة لمناقشة المشاكل المتعلّقة بأسباب عدم التمهيد.