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.cpp
kBootReasonMap
清單。
- 提供標準、可剖析及可辨識的理由
- 新增
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
),並將這個商機做為
討論啟動原因問題的相關討論。