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