دلیل متعارف راه‌اندازی مجدد

Android 9 شامل تغییرات زیر در مشخصات دلیل راه‌اندازی bootloader است.

دلایل راه‌اندازی

راه‌انداز از منابع سخت‌افزاری و حافظه منحصربه‌فرد دردسترس برای تعیین دلیل بازراه‌اندازی دستگاه استفاده می‌کند، سپس با افزودن androidboot.bootreason=<reason> به خط فرمان هسته Android برای راه‌اندازی، این تعیین را اعلام می‌کند. سپس init این خط فرمان را ترجمه می‌کند تا در دارایی Android منتشر شود bootloader_boot_reason_prop (ro.boot.bootreason). برای دستگاه‌هایی که با Android 12 یا بالاتر راه‌اندازی می‌شوند، بااستفاده از نسخه هسته ۵.۱۰ یا بالاتر، androidboot.bootreason=<reason> به‌جای خط فرمان هسته به bootconfig اضافه می‌شود.

مشخصات دلیل راه‌اندازی

نسخه‌های قبلی Android قالب دلیل راه‌اندازی را مشخص می‌کرد که از فاصله استفاده نمی‌کرد، کاملاً حروف کوچک بود، الزامات کمی داشت (مثلاً برای گزارش kernel_panic، watchdog، cold/warm/hard)، و برای دلایل منحصربه‌فرد دیگر مجوزهایی درنظر می‌گرفت. این مشخصات غیردقیق منجر به تکثیر صدها رشته دلیل راه‌اندازی سفارشی (و گاهی بی‌معنی) شد که به نوبه خود منجر به وضعیتی غیرقابل مدیریت شد. از زمان انتشار نسخه فعلی Android، حجم زیاد محتوای تقریباً تجزیه‌ناپذیر یا بی‌معنی ثبت‌شده توسط بارکننده، برای bootloader_boot_reason_prop مشکلاتی در زمینه رعایت استانداردها ایجاد کرده است.

با انتشار Android 9، تیم Android متوجه شد که bootloader_boot_reason_prop قدیمی شتاب قابل‌توجهی دارد و نمی‌تواند در زمان اجرا بازنویسی شود. بنابراین هرگونه بهبود در مشخصات دلیل راه‌اندازی باید از تعامل با توسعه‌دهندگان bootloader و تغییرات در سیستم موجود حاصل شود. به همین منظور، تیم 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 آن را درصورت نیاز مسدود می‌کند زیرا اطلاعات نادرست، غیرقابل تجزیه، و غیرمعتبر ارائه می‌دهد. در اکثر موارد، فقط توسعه‌دهندگانی که دانش عمیقی درباره سیستم راه‌اندازی دارند باید به این اطلاعات دسترسی داشته باشند. میانای برنامه‌سازی کاربردی (API) پالایش‌شده، تجزیه‌شدنی، و متعارفی برای دلیل راه‌اندازی با system_boot_reason_prop را می‌توان تنها پس‌از نصب داده‌های کاربر به‌طور قابل‌اعتماد و دقیق دریافت کرد. به‌طور دقیق:

• قبل‌از نصب داده‌های کاربر، system_boot_reason_prop حاوی مقدار bootloader_boot_reason_prop خواهد بود.
• پس‌از سوار شدن userdata، 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 در هسته مراجعه کنید) حاوی محتوای پایدار است.
  • "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 و سابقه گزارش تغییرات 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 متعارف پالایش کند.
• Not OK to report a noncompliant string in kBootReasonMap (such as "panic") from the bootloader, as this will ultimately break the ability to refine the reason.

برای مثال، اگر kBootReasonMap حاوی "wdog_bark" باشد، توسعه‌دهنده بارکننده باید:

• به "watchdog,bark" تغییر دهید و به فهرست در kBootReasonMap اضافه کنید.
• درنظر بگیرید که "bark" برای کسانی که با این فناوری آشنا نیستند چه معنایی دارد و ببینید آیا subreason معنادارتری دردسترس است یا نه.

درستی‌سنجی کردن مطابقت دلیل راه‌اندازی

درحال‌حاضر، Android آزمایش CTS فعالی ارائه نمی‌دهد که بتواند به‌طور دقیق همه دلایل احتمالی راه‌اندازی را که راه‌انداز سیستم می‌تواند ارائه دهد راه‌اندازی یا بازرسی کند؛ شرکا همچنان می‌توانند برای تعیین سازگاری، آزمایش غیرفعالی را اجرا کنند.

در نتیجه، رعایت الزامات راه‌انداز سیستم مستلزم این است که توسعه‌دهندگان راه‌انداز سیستم به‌صورت داوطلبانه از روح قوانین و دستورالعمل‌های شرح‌داده‌شده در بالا پیروی کنند. از این توسعه‌دهندگان می‌خواهیم در AOSP (به‌طور خاص در system/core/bootstat/bootstat.cpp) همیاری کنند و از این فرصت به‌عنوان تالاری برای بحث درباره مشکلات دلیل راه‌اندازی استفاده کنند.