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

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

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

يستخدم برنامج الإقلاع موارد الأجهزة والذاكرة المتاحة بشكل فريد من أجل وتحديد سبب إعادة تشغيل الجهاز، ثم الإعلان عن هذا القرار من خلال جارٍ إضافة androidboot.bootreason=<reason> إلى Android سطر أوامر kernel لتشغيله. ثم يترجم init هذا سطر الأوامر لنشره على سمة Android bootloader_boot_reason_prop (ro.boot.bootreason). بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 12 أو الإصدارات الأحدث، يجب اتّباع الخطوات التالية: باستخدام الإصدار 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 على أساس الحاجة لأنّها تمثّل معلومات غير دقيقة وغير قابلة للتحليل وغير أساسية. في معظم الحالات، لا يحتاج سوى المطوّرين الذين لديهم معرفة عميقة بنظام التشغيل الوصول إلى هذه المعلومات. عنوان URL منقح وقابل للتحليل وأساسي يمكن أن تكون واجهة برمجة التطبيقات لسبب التشغيل مع 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 و strong و حاد الأسباب:

• مجموعة النواة:
  • "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 والبيانات المرتبطة سجل التغييرات في مستودع مصادر Android.

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

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

ملاحظة: بينما system/core/bootstat/bootstat.cpp يحتوي على قسم kBootReasonMap الذي يسرد عدد الأسباب القديمة، فإن وجود هذه الأسباب لا يعني تمت الموافقة على استخدام سلسلة reason. مجموعة فرعية من القائمة تمثل أسبابًا متوافقة مع السياسات نتوقع أن تتزايد هذه المجموعة الفرعية كبرنامج إقلاع المؤلفين التسجيل وشرح الأسباب الإضافية المتوافقة.

نوصي بشدة باستخدام الإدخالات الحالية والمتوافقة مع 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) والاستفادة من هذه الفرصة للمناقشات حول مشكلات سبب التمهيد.