يتضمّن Android 9 التغييرات التالية على مواصفات سبب تشغيل برنامج الإقلاع.
أسباب التشغيل
يستخدم برنامج الإقلاع موارد الأجهزة والذاكرة المتاحة بشكل فريد لتحديد سبب إعادة تشغيل الجهاز، ثم يبلِّغ عن هذا التحديد من خلال إضافة androidboot.bootreason=<reason> إلى سطر أوامر kernel في Android عند تشغيله. init بعد ذلك، يترجم سطر الأوامر هذا لنشره في خاصية Android bootloader_boot_reason_prop (ro.boot.bootreason). بالنسبة إلى الأجهزة التي يتم تشغيلها باستخدام Android 12 أو إصدار أحدث، باستخدام إصدار النواة 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.cppkBootReasonMap
- تقديم أسباب أساسية قابلة للتحليل والتمييز إلى
- إضافة مصدر خاضع للتحكّم وقابل لإعادة الكتابة في وقت التشغيل لـ
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 والأسباب القوية والأسباب المباشرة:
- مجموعة kernel:
- "
watchdog" "kernel_panic"
- "
- المجموعة القوية:
"recovery""bootloader"
- المجموعة المباشرة:
"cold". يشير هذا الخيار بشكل عام إلى إعادة ضبط كاملة لجميع الأجهزة، بما في ذلك الذاكرة."hard". يشير هذا الخيار بشكل عام إلى إعادة ضبط حالة الأجهزة ويجب أن تحتفظramoopsبالمحتوى الثابت."warm". يشير هذا الخيار بشكل عام إلى أنّ الذاكرة والأجهزة تحتفظ ببعض الحالة، وأنّramoops(راجِعpstoreبرنامج التشغيل في kernel) تحتوي على محتوى ثابت."shutdown""reboot". يعني هذا الخيار بشكل عام أنّ حالةramoopsغير معروفة وحالة الأجهزة غير معروفة. هذه القيمة هي قيمة شاملة لأنّ القيمcoldوhardوwarmتقدّم مؤشرات على مدى إعادة ضبط الجهاز.
يجب أن تقدّم برامج الإقلاع مجموعة kernel أو مجموعة مباشرة reason، و
ننصح بشدة بتقديم subreason إذا كان من الممكن
تحديدها. على سبيل المثال، سيتم تحديد سبب التشغيل
"reboot,longkey" للضغط مع الاستمرار على مفتاح التشغيل الذي قد يكون لديه أو ليس لديه
ramoops نسخة احتياطية.
لا يمكن أن يكون 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 مزيجًا من الأسباب المتوافقة والأسباب القديمة
غير المتوافقة. يجب أن يسجّل مطوّرو برنامج الإقلاع الأسباب الجديدة
المتوافقة فقط هنا (ويجب ألا يسجّلوا الأسباب غير المتوافقة ما لم
يتم شحن المنتج بالفعل ولا يمكن تغييره).
ننصح بشدة باستخدام الإدخالات الحالية المتوافقة في
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) واستخدام هذه الفرصة كمنتدى للمناقشات حول مشاكل سبب التشغيل.