دلیل بوت متعارف

اندروید ۹ شامل تغییرات زیر در مشخصات دلیل بوت شدن بوت لودر است.

دلایل بوت شدن

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

مشخصات دلیل بوت

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

با انتشار اندروید ۹، تیم اندروید تشخیص داده است که bootloader_boot_reason_prop قدیمی، شتاب قابل توجهی دارد و نمی‌توان آن را در زمان اجرا دوباره نوشت. بنابراین، هرگونه بهبود در مشخصات دلیل بوت باید از طریق تعامل با توسعه‌دهندگان بوت‌لودر و اعمال تغییرات در سیستم موجود حاصل شود. برای این منظور، تیم اندروید:

• تعامل با توسعه‌دهندگان بوت‌لودر برای تشویق آنها به:
  • دلایل متعارف، قابل تجزیه و قابل تشخیص برای bootloader_boot_reason_prop ارائه دهید.
  • در لیست kBootReasonMap در system/core/bootstat/bootstat.cpp شرکت کنید.
• اضافه کردن یک منبع کنترل‌شده و قابل بازنویسی در زمان اجرا از system_boot_reason_prop ( sys.boot.reason ). مجموعه محدودی از برنامه‌های سیستمی (مانند bootstat و init ) می‌توانند این ویژگی را بازنویسی کنند، اما می‌توان به همه برنامه‌ها حقوق جداگانه‌ای برای خواندن آن اعطا کرد.
• اطلاع‌رسانی به کاربران در مورد دلیل بوت برای صبر کردن تا پس از نصب userdata قبل از اعتماد به محتوای موجود در ویژگی system_boot_reason_prop .

چرا اینقدر دیر؟ در حالی که bootloader_boot_reason_prop در اوایل بوت در دسترس است، توسط سیاست امنیتی اندروید بر اساس نیاز مسدود می‌شود زیرا نشان‌دهنده اطلاعات نادرست، غیرقابل تجزیه و غیر متعارف است. در بیشتر مواقع، فقط توسعه‌دهندگانی که دانش عمیقی از سیستم بوت دارند باید به این اطلاعات دسترسی داشته باشند. یک API اصلاح‌شده، قابل تجزیه و متعارف برای دلیل بوت با system_boot_reason_prop می‌تواند تنها پس از نصب userdata به طور قابل اعتماد و دقیق دریافت شود. به طور خاص:

• قبل از اینکه userdata نصب شود، system_boot_reason_prop مقدار bootloader_boot_reason_prop را در خود جای خواهد داد.
• پس از اینکه userdata نصب شد، system_boot_reason_prop ممکن است به‌روزرسانی شود تا با سیستم سازگار شود یا اطلاعات دقیق‌تری را گزارش دهد.

به همین دلیل، اندروید ۹ مدت زمان قبل از دریافت رسمی دلیل بوت را افزایش می‌دهد و آن را از حالت «دقیق بودن بلافاصله در هنگام بوت» (با bootloader_boot_reason_prop ) به حالتی تغییر می‌دهد که فقط پس از نصب شدن userdata (با system_boot_reason_prop ) در دسترس باشد.

منطق Bootstat به یک bootloader_boot_reason_prop که اطلاعات بیشتری ارائه می‌دهد و سازگارتر است، بستگی دارد. وقتی این ویژگی از یک قالب قابل پیش‌بینی استفاده می‌کند، دقت تمام سناریوهای راه‌اندازی مجدد و خاموش کردن کنترل‌شده را بهبود می‌بخشد، که به نوبه خود دقت و معنای system_boot_reason_prop را اصلاح و گسترش می‌دهد.

قالب دلیل بوت متعارف

فرمت استاندارد دلیل بوت برای bootloader_boot_reason_prop در اندروید ۹ از سینتکس زیر استفاده می‌کند:

<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" (ترجیحاً).

ترکیب‌های دلیل-زیردلیل

اندروید مجموعه‌ای از ترکیبات 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 مرتبط در مخزن منبع اندروید مراجعه کنید.

گزارش دلایل بوت

تمام دلایل بوت، چه از طریق بوت‌لودر و چه ثبت‌شده در دلیل بوت متعارف، باید در بخش 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 معنادارتری وجود دارد یا خیر.

تأیید انطباق دلیل بوت

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

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