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

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

أسباب إعادة التشغيل

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

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

حدّدت الإصدارات السابقة من 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 لقراءتها.
• إبلاغ المستخدمين بسبب إعادة التشغيل لانتظار تحميل بيانات المستخدم قبل الوثوق بالمحتوى في خاصية سبب إعادة تشغيل النظام system_boot_reason_prop

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

• قبل تحميل بيانات المستخدم، سيحتوي system_boot_reason_prop على القيمة من bootloader_boot_reason_prop.
• بعد تحميل بيانات المستخدم، يمكن تعديل system_boot_reason_prop ليكون متوافقًا أو لتقديم معلومات أكثر دقة.

لهذا السبب، يمدّد نظام التشغيل Android 9 الفترة الزمنية التي يمكن خلالها الحصول على سبب إعادة التشغيل بشكل رسمي، ويغيّرها من أن تكون دقيقة على الفور عند إعادة التشغيل (باستخدام bootloader_boot_reason_prop) إلى أن تكون متاحة فقط بعد تحميل بيانات المستخدم (باستخدام 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 set:
  • "watchdog"
  • "kernel_panic"
• مجموعة كلمات قوية:
  • "recovery"
  • "bootloader"
• blunt set:
  • "cold". يشير هذا الرمز بشكل عام إلى إعادة ضبط جميع الأجهزة بالكامل، بما في ذلك الذاكرة.
  • "hard". يشير هذا الرمز عادةً إلى أنّه تمت إعادة ضبط حالة الجهاز، ويجب أن يحتفظ ramoops بالمحتوى الثابت.
  • "warm". يشير هذا الرمز بشكل عام إلى أنّ الذاكرة والأجهزة تحتفظ ببعض الحالة، وأنّ مخزن النسخ الاحتياطية ramoops (راجِع برنامج التشغيل pstore في النواة) يحتوي على محتوى ثابت.
  • "shutdown"
  • ‫"reboot": يعني ذلك بشكل عام أنّ حالة ramoops غير معروفة وحالة الجهاز غير معروفة. هذه القيمة هي قيمة شاملة لأنّ القيم cold وhard وwarm تقدّم إشارات إلى مدى عمق عملية إعادة الضبط للجهاز.

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

لا يمكن أن يكون أي 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 وسجلّ التغييرات المرتبط به في مستودع مصدر Android.

تسجيل أسباب إعادة التشغيل

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

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

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

على سبيل المثال، إذا كان kBootReasonMap يتضمّن "wdog_bark"، على مطوّر برنامج التشغيل الأوّلي إجراء ما يلي:

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

التحقّق من امتثال سبب إعادة التشغيل

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

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