Android 9 對系統啟動載入程式啟動原因規格做了以下變更。
啟動原因
系統啟動載入程式會使用獨家提供的硬體和記憶體資源，
然後判斷裝置重新啟動的原因，
將 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_boot_reason_prop。
隨著 Android 9 版本推出，Android 團隊
舊版 bootloader_boot_reason_prop
而且在執行階段無法重寫任何改善
因此，開機原因規格必須來自於
系統啟動載入程式開發人員並微調現有系統。為達成這個目標
Android 團隊是：
- 請與系統啟動載入程式開發人員聯絡，鼓勵他們執行下列操作：
- 提供標準、可剖析及可辨識的理由
bootloader_boot_reason_prop。 - 參加
system/core/bootstat/bootstat.cppkBootReasonMap清單。
- 提供標準、可剖析及可辨識的理由
- 新增
system_boot_reason_prop(sys.boot.reason)。A 罩杯 一組特定的系統應用程式 (例如bootstat和init) 可以重寫這個屬性，但所有應用程式皆可 並授予這項政策讀取權限 - 告知使用者啟動原因，等到使用者資料掛接完成後再執行
然後再信任系統啟動原因屬性中的內容
system_boot_reason_prop。
為何遲到？儘管 bootloader_boot_reason_prop 開放搶先體驗
開啟時，Android 安全性政策就會視需要封鎖。
因為內容提供的資訊不正確、無法剖析且非標準
大多數情況下，只有熟悉啟動系統的開發人員
需要存取這項資訊精簡且可剖析的標準網頁
使用 system_boot_reason_prop 進行啟動原因的 API 可確實可靠
並在使用者資料安裝好之後才準確擷取。
具體違規事項如下：
- 掛接使用者資料之前，
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 個)。
標準啟動原因格式
bootloader_boot_reason_prop 的標準啟動原因格式
Android 9 使用下列語法：
<reason>,<subreason>,<detail>…
格式設定規則：
- 小寫
- 無空白 (使用底線)
- 所有可列印字元
- 以半形逗號分隔的
reason、subreason和 1 或 更多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值 代表裝置重設深度。
系統啟動載入程式必須提供核心組合或 Blunt 組合 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 名單混合了符合規定和舊版
不符合規定的原因系統啟動載入程式開發人員只能註冊新的
此處 (除非是 Google 政策，否則不應登錄不符規定的原因，
產品已出貨，無法變更)。
我們強烈建議您在以下位置使用符合規定的現有項目：
system/core/bootstat/bootstat.cpp之前正在進行運動提醒
使用不符合規定的字串。原則上：
- 確定從以下位置檢舉
"kernel_panic"： 系統啟動載入程式，因為bootstat或許可以檢查kernel_panic signatures的ramoops，以修正 子情況轉換為標準system_boot_reason_prop。 - 不允許回報
kBootReasonMap(例如"panic")，因為這樣最終就無法修正reason。
舉例來說，如果 kBootReasonMap 包含 "wdog_bark"，
系統啟動載入程式開發人員應：
- 變更為「
"watchdog,bark"」並新增至以下清單：kBootReasonMap。 - 請思考
"bark"對不熟悉 判斷出更有意義的subreason廣告。
確認啟動原因符合規範
Android 目前並未提供可準確執行的 CTS 測試 觸發或檢查系統啟動載入程式可能提供的所有系統啟動原因； 合作夥伴仍可嘗試執行被動測試來判斷相容性。
因此，系統啟動載入程式開發人員必須符合以下條件，才能遵循系統啟動載入程式的相關規定：
主動遵守上述規則和規範的精神。
我們強烈建議這類開發人員對 Android 開放原始碼計畫做出貢獻 (特別是
system/core/bootstat/bootstat.cpp)，並將這個商機做為
討論啟動原因問題的相關討論。