سبب التمهيد الكنسي

يتضمن Android 9 التغييرات التالية على مواصفات سبب تشغيل أداة تحميل التشغيل.

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

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

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

يجب أن توفر أدوات تحميل التشغيل مجموعة kernel أو 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 عبارة عن مزيج من الأسباب المتوافقة والأسباب القديمة غير المتوافقة. يجب على مطوري Bootloader تسجيل الأسباب المتوافقة الجديدة فقط هنا (ويجب عدم تسجيل الأسباب غير المتوافقة إلا إذا تم شحن المنتج بالفعل ولا يمكن تغييره).

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