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

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

دلایل بوت

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

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

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

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

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

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

به همین دلیل، اندروید 9 مدت زمانی را که می‌توان دلیل راه‌اندازی را به‌طور رسمی دریافت کرد، تمدید می‌کند، و آن را از دقیق بودن فوری در بوت (با bootloader_boot_reason_prop ) به در دسترس بودن تنها پس از نصب داده‌های کاربر (با system_boot_reason_prop ) تغییر می‌دهد.

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

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

فرمت دلیل بوت متعارف برای bootloader_boot_reason_prop در اندروید 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 بازرسی کند تا دلایل فرعی را در canonical system_boot_reason_prop اصلاح کند.
• گزارش یک رشته ناسازگار در kBootReasonMap (مانند "panic") از بوت لودر، درست نیست ، زیرا در نهایت توانایی اصلاح reason از بین می برد.

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

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

بررسی انطباق دلیل بوت

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

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