Android 9 bao gồm các thay đổi sau đối với thông số lý do khởi động bộ nạp khởi động.
Lý do khởi động
Bộ tải khởi động sử dụng tài nguyên bộ nhớ và phần cứng có sẵn duy nhất để xác định lý do thiết bị khởi động lại, sau đó truyền đạt quyết định đó bằng cách thêm androidboot.bootreason=<reason>
vào dòng lệnh nhân Android để khởi chạy. init
sau đó dịch dòng lệnh này để truyền tới thuộc tính Android bootloader_boot_reason_prop
( ro.boot.bootreason
). Đối với các thiết bị chạy Android 12 trở lên, sử dụng kernel phiên bản 5.10 trở lên, androidboot.bootreason=<reason>
được thêm vào bootconfig thay vì dòng lệnh kernel.
Thông số lý do khởi động
Các bản phát hành trước của Android đã chỉ định định dạng lý do khởi động không sử dụng dấu cách, hoàn toàn là chữ thường, bao gồm một số yêu cầu (chẳng hạn như để báo cáo kernel_panic
, watchdog
, cold
/ warm
/ hard
) và cho phép các lý do riêng khác. Thông số kỹ thuật lỏng lẻo này dẫn đến sự gia tăng của hàng trăm chuỗi lý do khởi động tùy chỉnh (và đôi khi vô nghĩa), từ đó dẫn đến tình huống không thể quản lý được. Kể từ bản phát hành Android hiện tại, động lực tuyệt đối của nội dung gần như không thể phân tích được hoặc vô nghĩa do bộ nạp khởi động cung cấp đã tạo ra các vấn đề tuân thủ cho bootloader_boot_reason_prop
.
Với bản phát hành Android 9, nhóm Android nhận thấy rằng bootloader_boot_reason_prop
cũ có động lực đáng kể và không thể viết lại trong thời gian chạy. Do đó, bất kỳ cải tiến nào đối với đặc tả lý do khởi động đều phải đến từ sự tương tác với các nhà phát triển bộ nạp khởi động và các chỉnh sửa đối với hệ thống hiện có. Để đạt được mục tiêu đó, nhóm Android là:
- Tương tác với các nhà phát triển bootloader để khuyến khích họ:
- Cung cấp các lý do chính tắc, có thể phân tích cú pháp và có thể nhận biết được cho
bootloader_boot_reason_prop
. - Tham gia vào danh sách
system/core/bootstat/bootstat.cpp
kBootReasonMap
.
- Cung cấp các lý do chính tắc, có thể phân tích cú pháp và có thể nhận biết được cho
- Thêm nguồn được kiểm soát và có thể ghi lại trong thời gian chạy của
system_boot_reason_prop
(sys.boot.reason
). Một tập hợp giới hạn các ứng dụng hệ thống (chẳng hạn nhưbootstat
vàinit
) có thể viết lại thuộc tính này, nhưng tất cả các ứng dụng đều có thể được cấp quyền riêng biệt để đọc nó. - Thông báo cho người dùng về lý do khởi động để đợi cho đến khi dữ liệu người dùng được gắn kết trước khi tin cậy nội dung trong thuộc tính lý do khởi động hệ thống
system_boot_reason_prop
.
Sao trễ vậy? Mặc dù bootloader_boot_reason_prop
có sẵn ngay từ đầu khi khởi động nhưng nó bị chính sách bảo mật Android chặn trên cơ sở khi cần vì nó thể hiện thông tin không chính xác, không thể phân tích cú pháp và không chuẩn. Trong hầu hết các trường hợp, chỉ những nhà phát triển có kiến thức sâu về hệ thống khởi động mới cần truy cập thông tin này. API được tinh chỉnh, có thể phân tích cú pháp và chuẩn cho lý do khởi động thông qua system_boot_reason_prop
chỉ có thể được chọn một cách đáng tin cậy và chính xác sau khi dữ liệu người dùng đã được gắn kết. Đặc biệt:
- Trước khi dữ liệu người dùng được gắn kết,
system_boot_reason_prop
sẽ chứa giá trị từbootloader_boot_reason_prop
. - Sau khi dữ liệu người dùng được gắn kết,
system_boot_reason_prop
có thể được cập nhật để tuân thủ hoặc báo cáo thông tin chính xác hơn.
Vì lý do này, Android 9 kéo dài khoảng thời gian trước khi có thể chính thức lấy lý do khởi động, thay đổi từ chính xác ngay lập tức khi khởi động (với bootloader_boot_reason_prop
) thành chỉ khả dụng sau khi dữ liệu người dùng được gắn kết (với system_boot_reason_prop
).
Logic bootstat phụ thuộc vào bootloader_boot_reason_prop
có nhiều thông tin và tuân thủ hơn. Khi thuộc tính đó sử dụng định dạng có thể dự đoán được, nó sẽ cải thiện độ chính xác của tất cả các tình huống khởi động lại và tắt máy được kiểm soát, từ đó tinh chỉnh và mở rộng độ chính xác cũng như ý nghĩa của system_boot_reason_prop
.
Định dạng lý do khởi động chuẩn
Định dạng lý do khởi động chuẩn cho bootloader_boot_reason_prop
trong Android 9 sử dụng cú pháp sau:
<reason>,<subreason>,<detail>…
Quy tắc định dạng:
- Chữ thường
- Không có khoảng trống (dùng gạch dưới)
- Tất cả các ký tự có thể in được
-
reason
được phân tách bằng dấu phẩy ,subreason
và một hoặc nhiềudetail
.-
reason
bắt buộc thể hiện lý do có mức ưu tiên cao nhất khiến thiết bị phải khởi động lại hoặc tắt máy. - Một lý do phụ tùy chọn thể hiện
subreason
tóm tắt ngắn gọn về lý do thiết bị phải khởi động lại hoặc tắt máy (hoặc ai đã khởi động lại hoặc tắt thiết bị). - Một hoặc nhiều giá trị
detail
tùy chọn. Mộtdetail
có thể trỏ tới một hệ thống con để hỗ trợ việc xác định hệ thống cụ thể nào dẫn đếnsubreason
. Bạn có thể chỉ định nhiều giá trịdetail
, thường tuân theo thứ bậc quan trọng. Tuy nhiên, cũng có thể chấp nhận báo cáo nhiều giá trịdetail
có tầm quan trọng như nhau.
-
Giá trị trống cho bootloader_boot_reason_prop
được coi là bất hợp pháp (vì điều này cho phép các tác nhân khác đưa ra lý do khởi động sau khi thực tế).
Yêu cầu về lý do
Giá trị được cung cấp cho reason
(khoảng đầu tiên, trước khi kết thúc hoặc dấu phẩy) phải thuộc tập hợp sau được chia thành các lý do cốt lõi, mạnh mẽ và thẳng thừng:
- bộ hạt nhân:
- "
watchdog"
-
"kernel_panic"
- "
- bộ mạnh:
-
"recovery"
-
"bootloader"
-
- bộ cùn:
-
"cold"
. Thường biểu thị việc thiết lập lại toàn bộ tất cả các thiết bị, bao gồm cả bộ nhớ. -
"hard"
. Nói chung cho biết phần cứng đã được thiết lập lại trạng thái vàramoops
sẽ giữ lại nội dung liên tục. -
"warm"
. Nói chung cho biết bộ nhớ và các thiết bị giữ lại một số trạng thái và kho lưu trữ hỗ trợramoops
(xem trình điều khiểnpstore
trong kernel) chứa nội dung liên tục. -
"shutdown"
-
"reboot"
. Nói chung có nghĩa là trạng tháiramoops
không xác định và trạng thái phần cứng không xác định. Giá trị này rất đáng chú ý vì các giá trịcold
,hard
vàwarm
cung cấp manh mối về mức độ thiết lập lại cho thiết bị.
-
Bộ tải khởi động phải cung cấp một bộ kernel hoặc một reason
được đặt rõ ràng và được khuyến khích cung cấp một subreason
nếu có thể xác định được lý do đó. Ví dụ: nhấn lâu phím nguồn có thể có hoặc không có bản sao lưu ramoops
sẽ có lý do khởi động "reboot,longkey"
.
Không có reason
đầu tiên nào có thể là một phần của bất kỳ subreason
hoặc detail
. Tuy nhiên, do không gian người dùng không thể tạo ra các lý do về bộ kernel, "watchdog"
có thể được sử dụng lại sau một lý do được đặt rõ ràng, cùng với chi tiết về nguồn (ví dụ: "reboot,watchdog,service_manager_unresponsive"
hoặc "reboot,software,watchdog"
).
Lý do khởi động không yêu cầu kiến thức nội bộ của chuyên gia để giải mã và/hoặc con người có thể đọc được bằng báo cáo trực quan. Ví dụ: "shutdown,vbxd"
(xấu), "shutdown,uv"
(tốt hơn), "shutdown,undervoltage"
(ưu tiên).
Sự kết hợp lý do-lý do phụ
Android bảo lưu một tập hợp reason
- các kết hợp subreason
không được quá tải trong cách sử dụng thông thường nhưng có thể được sử dụng trong từng trường hợp nếu sự kết hợp đó phản ánh chính xác điều kiện liên quan. Ví dụ về các kết hợp dành riêng bao gồm:
-
"reboot,userrequested"
-
"shutdown,userrequested"
-
"shutdown,thermal"
(từthermald
) -
"shutdown,battery"
-
"shutdown,battery,thermal"
(từBatteryStatsService
) -
"reboot,adb"
-
"reboot,shell"
-
"reboot,bootloader"
-
"reboot,recovery"
Để biết thêm chi tiết, hãy tham khảo kBootReasonMap
trong system/core/bootstat/bootstat.cpp
và lịch sử nhật ký thay đổi git liên quan trong kho lưu trữ nguồn Android.
Báo cáo lý do khởi động
Tất cả lý do khởi động, từ bộ nạp khởi động hoặc được ghi trong lý do khởi động chuẩn, phải được ghi lại trong phần kBootReasonMap
của system/core/bootstat/bootstat.cpp
. Danh sách kBootReasonMap
là sự kết hợp của các lý do tuân thủ và không tuân thủ cũ. Các nhà phát triển Bootloader chỉ nên đăng ký những lý do tuân thủ mới tại đây (và không nên đăng ký những lý do không tuân thủ trừ khi sản phẩm đã được xuất xưởng và không thể thay đổi).
Chúng tôi thực sự khuyên bạn nên sử dụng các mục nhập tuân thủ hiện có trong system/core/bootstat/bootstat.cpp
và thực hiện hạn chế trước khi sử dụng chuỗi không tuân thủ. Như một hướng dẫn, đó là:
- Được phép báo cáo
"kernel_panic"
từ bộ nạp khởi động, vìbootstat
có thể kiểm traramoops
đểkernel_panic signatures
để tinh chỉnh các lý do phụ thành chuẩnsystem_boot_reason_prop
. - Không được phép báo cáo chuỗi không tuân thủ trong
kBootReasonMap
(chẳng hạn như"panic")
từ bộ nạp khởi động, vì điều này cuối cùng sẽ phá vỡ khả năng tinh chỉnhreason
.
Ví dụ: nếu kBootReasonMap
chứa "wdog_bark"
thì nhà phát triển bộ nạp khởi động nên:
- Thay đổi thành
"watchdog,bark"
và thêm vào danh sách trongkBootReasonMap
. - Hãy xem xét ý nghĩa của
"bark"
đối với những người không quen thuộc với công nghệ này và xác định xem cósubreason
nào có ý nghĩa hơn không.
Xác minh việc tuân thủ lý do khởi động
Tại thời điểm này, Android không cung cấp thử nghiệm CTS đang hoạt động có thể kích hoạt hoặc kiểm tra chính xác tất cả lý do khởi động có thể có mà bộ tải khởi động có thể cung cấp; các đối tác vẫn có thể thử chạy thử nghiệm thụ động để xác định khả năng tương thích.
Do đó, việc tuân thủ bootloader yêu cầu các nhà phát triển bootloader phải tự nguyện tuân thủ tinh thần của các quy tắc và nguyên tắc được mô tả ở trên. Chúng tôi kêu gọi các nhà phát triển như vậy đóng góp cho AOSP (cụ thể là system/core/bootstat/bootstat.cpp
) và sử dụng cơ hội này làm diễn đàn để thảo luận về các vấn đề lý do khởi động.