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

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

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

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

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

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

في الإصدار 9 من نظام التشغيل Android، يدرك فريق 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).

يعتمد منطق إحصاءات التمهيد على 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 وقوية وحادة:

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

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

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

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

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

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

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

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

التأكّد من الامتثال لسبب التشغيل

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

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