เหตุผลที่เปิดเครื่องได้

Android 9 มีการเปลี่ยนแปลงต่อไปนี้ในข้อกำหนดเกี่ยวกับเหตุผลการเปิดเครื่อง Bootloader

เหตุผลที่เปิดเครื่อง

Bootloader ใช้ฮาร์ดแวร์และทรัพยากรหน่วยความจำที่มีไม่ซ้ำกันเพื่อ ระบุเหตุผลที่อุปกรณ์รีบูต จากนั้นจะแจ้งการตัดสินใจดังกล่าวโดย กำลังเพิ่ม androidboot.bootreason=<reason> ลงใน Android บรรทัดคำสั่งเคอร์เนลสำหรับการเปิดตัว init แปลว่าคำนี้ บรรทัดคำสั่งเพื่อเผยแพร่ไปยังพร็อพเพอร์ตี้ Android bootloader_boot_reason_prop (ro.boot.bootreason) สำหรับอุปกรณ์ที่ใช้ Android 12 ขึ้นไป ที่ใช้เคอร์เนลเวอร์ชัน 5.10 ขึ้นไป androidboot.bootreason=<reason> จะถูกเพิ่มลงใน Bootconfig แทนบรรทัดคำสั่งของเคอร์เนล

ข้อกำหนดเฉพาะของเหตุผลในการเปิดเครื่อง

Android รุ่นก่อนหน้าระบุรูปแบบเหตุผลที่เปิดเครื่องซึ่งใช้ "ไม่" การเว้นวรรค เป็นตัวพิมพ์เล็กทั้งหมด รวมถึงข้อกำหนดเพียงเล็กน้อย (เช่น สำหรับการรายงาน kernel_panic watchdog cold/warm/hard) ซึ่งทำให้ ค่าเผื่อไว้ด้วยเหตุผลเฉพาะอื่นๆ ข้อกำหนดอย่างคร่าวๆ นี้ส่งผลให้เกิด สาเหตุของการเปิดเครื่องที่กำหนดเองที่เพิ่มขึ้นหลายร้อยรายการ (และบางครั้งก็ไม่มีความหมาย) และทำให้เกิดสถานการณ์ที่ไม่สามารถจัดการได้ ณ ปัจจุบัน การเปิดตัว Android ซึ่งเป็นแรงผลักดันที่มากกว่าของเนื้อหาที่แทบไม่สามารถแยกวิเคราะห์ได้หรือไร้ความหมาย ที่ Bootloader ส่งได้ได้สร้างปัญหาการปฏิบัติตามข้อกำหนดสำหรับ bootloader_boot_reason_prop

สำหรับ Android 9 ทีม Android ทราบว่า bootloader_boot_reason_prop เดิมได้ กระแสความนิยมมากและไม่สามารถเขียนใหม่ในช่วงรันไทม์ได้ การปรับปรุงใดๆ ที่มีต่อ ดังนั้น ข้อกำหนดเฉพาะของเหตุผลในการเปิดเครื่องต้องมาจากการโต้ตอบกับ นักพัฒนาซอฟต์แวร์ Bootloader และปรับเปลี่ยนระบบที่มีอยู่ ด้วยเหตุนี้ ทีม Android

• การมีส่วนร่วมกับนักพัฒนาซอฟต์แวร์ Bootloader เพื่อส่งเสริมให้:
  • ระบุเหตุผลตามรูปแบบบัญญัติ แยกวิเคราะห์ได้ และเข้าใจได้เพื่อวัตถุประสงค์ต่อไปนี้ 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 ตามความจำเป็น เนื่องจากแสดงข้อมูลที่ไม่ถูกต้อง แยกวิเคราะห์ไม่ได้ และไม่ใช่ตามรูปแบบบัญญัติ ในสถานการณ์ส่วนใหญ่ เฉพาะนักพัฒนาซอฟต์แวร์ที่มีความรู้เชิงลึกเกี่ยวกับระบบการเปิดเครื่องเท่านั้น จำเป็นต้องเข้าถึงข้อมูลนี้ รูปแบบที่กำหนดเอง แยกวิเคราะห์ได้ และเป็น Canonical API สำหรับเหตุผลในการเปิดเครื่องด้วย 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

รูปแบบเหตุผลที่เปิดเครื่องได้

รูปแบบเหตุผลการเปิดเครื่อง Canonical ของ bootloader_boot_reason_prop ใน Android 9 ใช้ไวยากรณ์ต่อไปนี้

<reason>,<subreason>,<detail>…

กฎการจัดรูปแบบ

• ตัวพิมพ์เล็ก
• ไม่เว้นวรรค (ใช้ขีดเส้นใต้)
• อักขระที่สามารถพิมพ์ได้ทั้งหมด
• reason, subreason และอีก 1 รายการที่คั่นด้วยเครื่องหมายจุลภาค หรือ detail อินสแตนซ์เพิ่มเติม
  • reason ที่จำเป็นซึ่งแสดงถึงลำดับความสำคัญสูงสุด เหตุผลที่อุปกรณ์ต้องรีบูตหรือปิดเครื่อง
  • subreason ที่ไม่บังคับซึ่งแสดงถึงสรุปสั้นๆ ของ เหตุผลที่อุปกรณ์ต้องรีบูตหรือปิดเครื่อง (หรือผู้ที่รีบูตหรือปิดระบบ อุปกรณ์)
  • ค่า detail (ไม่บังคับ) อย่างน้อย 1 ค่า 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 ระบุ ข้อมูลนี้จะบ่งบอกถึงความลึกของการรีเซ็ตอุปกรณ์

Bootloaders ต้องมีชุดเคอร์เนลหรือชุด 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 ที่เกี่ยวข้อง ประวัติ Changelog ในที่เก็บต้นทางของ Android

รายงานเหตุผลที่เปิดเครื่อง

สาเหตุในการเปิดเครื่องทั้งหมด ทั้งจาก Bootloader หรือที่บันทึกไว้ในการเปิดเครื่อง Canonical ต้องบันทึกในส่วน kBootReasonMap ของ system/core/bootstat/bootstat.cpp รายการ kBootReasonMap มีทั้งการปฏิบัติตามข้อกำหนดและแบบเดิม เหตุผลที่ไม่เป็นไปตามข้อกำหนด นักพัฒนาซอฟต์แวร์ Bootloader ควรลงทะเบียนเฉพาะ เหตุผลที่ปฏิบัติตามข้อกำหนดได้ที่นี่ (และไม่ควรลงทะเบียนเหตุผลที่ไม่เป็นไปตามข้อกำหนด เว้นแต่ จัดส่งผลิตภัณฑ์ไปแล้วและจะเปลี่ยนแปลงไม่ได้)

เราขอแนะนำให้ใช้รายการที่มีอยู่ซึ่งเป็นไปตามข้อกำหนดใน system/core/bootstat/bootstat.cppและออกกำลังกายแบบยับยั้งชั่งใจก่อน ใช้สตริงที่ไม่เป็นไปตามข้อกำหนด หลักเกณฑ์ก็คือ

• ตกลง ในการรายงาน "kernel_panic" จาก Bootloader เนื่องจาก bootstat อาจตรวจสอบได้ ramoops สำหรับ kernel_panic signatures เพื่อปรับแต่ง เหตุผลย่อยไว้ใน system_boot_reason_prop ตามรูปแบบบัญญัติ
• ไม่ยอมรับในการรายงานสตริงที่ไม่เป็นไปตามนโยบายใน kBootReasonMap (เช่น "panic") จาก Bootloader เพราะสุดท้ายแล้วจะเป็นการทำลายความสามารถในการปรับแต่ง reason

ตัวอย่างเช่น หาก kBootReasonMap มี "wdog_bark" นักพัฒนาซอฟต์แวร์ Bootloader ควรทำดังนี้

• เปลี่ยนเป็น "watchdog,bark" และเพิ่มลงในรายการใน kBootReasonMap
• ลองพิจารณาว่า "bark" มีความหมายอย่างไรสำหรับผู้ที่ไม่คุ้นเคยกับ เทคโนโลยีและพิจารณาว่า subreason ที่มีความหมายมากกว่า พร้อมใช้งาน

ยืนยันการปฏิบัติตามข้อกำหนดเหตุผลในการเปิดเครื่อง

ขณะนี้ Android ไม่มีการทดสอบ CTS ที่ใช้งานอยู่ซึ่งมีความแม่นยำ ทริกเกอร์หรือตรวจสอบสาเหตุที่เป็นไปได้ทั้งหมดที่เปิดเครื่องซึ่ง Bootloader มีให้ พาร์ทเนอร์จะยังคงพยายามเรียกใช้การทดสอบแบบแพสซีฟเพื่อระบุความเข้ากันได้ได้

ด้วยเหตุนี้ การปฏิบัติตามข้อกำหนดของ Bootloader จึงต้องให้นักพัฒนาซอฟต์แวร์ Bootloader ดำเนินการ ปฏิบัติตามเจตนารมณ์ของกฎและหลักเกณฑ์ที่อธิบายไว้ข้างต้นโดยสมัครใจ เราขอแนะนำให้นักพัฒนาซอฟต์แวร์ดังกล่าวมีส่วนร่วมใน AOSP (โดยเฉพาะ system/core/bootstat/bootstat.cpp) และใช้โอกาสนี้เป็น ฟอรัมสำหรับการสนทนาเกี่ยวกับปัญหาสาเหตุเปิดเครื่อง