標準啟動原因

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_panicwatchdogcold/warm/hard),以及 其他特殊原因這種寬鬆的規格導致 數百種自訂 (有時或毫無意義) 啟動原因的擴散 因而導致難以管理的情況截至目前 隨著 Android 版本推出,使用者將看到近乎難以解析或無意義的內容 系統啟動載入程式針對以下項目建立法規遵循問題: bootloader_boot_reason_prop

隨著 Android 9 版本推出,Android 團隊 舊版 bootloader_boot_reason_prop 而且在執行階段無法重寫任何改善 因此,開機原因規格必須來自於 系統啟動載入程式開發人員並微調現有系統。為達成這個目標 Android 團隊是:

  • 請與系統啟動載入程式開發人員聯絡,鼓勵他們執行下列操作:
    • 提供標準、可剖析及可辨識的理由 bootloader_boot_reason_prop
    • 參加 system/core/bootstat/bootstat.cpp kBootReasonMap 清單。
  • 新增 system_boot_reason_prop (sys.boot.reason)。A 罩杯 一組特定的系統應用程式 (例如 bootstatinit) 可以重寫這個屬性,但所有應用程式皆可 並授予這項政策讀取權限
  • 告知使用者啟動原因,等到使用者資料掛接完成後再執行 然後再信任系統啟動原因屬性中的內容 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>…

格式設定規則:

  • 小寫
  • 無空白 (使用底線)
  • 所有可列印字元
  • 以半形逗號分隔的 reasonsubreason 和 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 狀態是 且硬體狀態不明這個值是通用的,因為 提供 coldhardwarm 值 代表裝置重設深度。

系統啟動載入程式必須提供核心組合或 Blunt 組合 reason,以及 如果可以,強烈建議提供 subreason 下定決心。舉例來說,長按電源鍵不一定會觸發 ramoops 備份具有啟動原因 "reboot,longkey"

第一個時距 reason 不能屬於任何 subreasondetail。不過,由於核心集原因無法 使用者空間 ("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"

詳情請參閱以下中的 kBootReasonMapsystem/core/bootstat/bootstat.cpp 和相關聯的 Git Android 原始碼存放區中的變更記錄

回報啟動原因

所有啟動原因,可能來自系統啟動載入程式或記錄在標準開機程序 ,因此必須記錄在kBootReasonMap system/core/bootstat/bootstat.cppkBootReasonMap 名單混合了符合規定和舊版 不符合規定的原因系統啟動載入程式開發人員只能註冊新的 此處 (除非是 Google 政策,否則不應登錄不符規定的原因, 產品已出貨,無法變更)。

我們強烈建議您在以下位置使用符合規定的現有項目: system/core/bootstat/bootstat.cpp之前正在進行運動提醒 使用不符合規定的字串。原則上:

  • 確定從以下位置檢舉"kernel_panic": 系統啟動載入程式,因為 bootstat 或許可以檢查 kernel_panic signaturesramoops,以修正 子情況轉換為標準 system_boot_reason_prop
  • 不允許回報 kBootReasonMap (例如 "panic") ,因為這樣最終就無法修正 reason

舉例來說,如果 kBootReasonMap 包含 "wdog_bark", 系統啟動載入程式開發人員應:

  • 變更為「"watchdog,bark"」並新增至以下清單: kBootReasonMap
  • 請思考 "bark" 對不熟悉 判斷出更有意義的subreason 廣告。

確認啟動原因符合規範

Android 目前並未提供可準確執行的 CTS 測試 觸發或檢查系統啟動載入程式可能提供的所有系統啟動原因; 合作夥伴仍可嘗試執行被動測試來判斷相容性。

因此,系統啟動載入程式開發人員必須符合以下條件,才能遵循系統啟動載入程式的相關規定: 主動遵守上述規則和規範的精神。 我們強烈建議這類開發人員對 Android 開放原始碼計畫做出貢獻 (特別是 system/core/bootstat/bootstat.cpp),並將這個商機做為 討論啟動原因問題的相關討論。